Видео

The ENTIRE premise of this is TOTAL BUNK. Within the first 40 SECONDS you say "something super simple" then literally show us a fucking COMPONENT DEMO. OBVIOUSLY NOBODY NEEDS A FRAMEWORK FOR THAT. Do you SERIOUSLY believe that there are money making products on the web that frequently resolve to LITERALLY <100 LINES OF CODE? THAT ISNT A GOOD FAITH EXAMPLE OF A PROJECT. GOD DAMN.

PP is sheet

sending raw data instead of html and then formatting at client makes sense if raw data is a more efficient format, which it is with binary data, but json is literally the worst serialisation method to ever exist

I must remind you that react is not a framework but a library, just like this htmx thing you are using. I don't like react, but I like this jQuery project even less, in 2024! bullshit

Wtf do u know how easy Next set up is once u know React, and I thought that Lavarel doesn't use third parties libraries. I don't genuinely understand why anyone would substitute laravel instead of Next especially when u could just Express which shares the Node environment with Next. And I would rather learn the backend concepts instead of using a framework and its way easier to learn that in the Js ecosystem

Isn't openswoole written in C++? Would mean that you're comparing php with node and go and than come to the conclusion that C++ is faster than all of them. Great Job.

Definitely agree that complexity of web development has made it difficult for beginners. (2.6 gigabytes of deps for a todo app is a skill issue bro, stop using create react app, prune your deps, switch to parcel or vite, switch to SvelteKit, just go learn some more; I can easily get a standalone JS/TS todo app into a 6mb dmg/exe/pkg). But I think you are missing some of the key use cases for the current popular frameworks. Firstly, the "why send json to be parsed into html on the client side, why not send HTML" comment that you had: compute time costs money, especially at scale. Whatever we can offload to the client without ruining user experience or slowing down their computer, we should. In 2024, even the slowest computers on earth can handle doing some basic dict/array manipulation without any slowdown, so why relegate powerful edge devices to just being glorified HTML renderers? We want a mix of both client and server side compute, and frameworks afford this nicely. (Also internet connection is not always fast, or guaranteed, but someone already discussed this.) Secondly, the quick reusability of components + the ability to strongly type them with custom types is a massive selling point for larger projects with large teams. PHP + htmx requires quite a bit of extending to achieve the same level of type control that TS frameworks afford, if you even can at all. Lastly, there are many use cases for static HTML where you don't have access to a server, and having your UI ready to go for these use cases is ideal. Imagine your bosses realize that you need to build a Zoom app, Chrome extension, and Desktop app. With a solid component-driven development, you can reuse the exact same components from your web app in almost any dist format, which is incredibly valuable. TL;DR: modern web dev is "pretty complicated" to allow for scaling to large teams with complex use cases. htmx is missing some key requirements to fit the needs of larger organizations, and likely needs to be used in tandem with more robust frameworks to achieve the same functionality. Source: Former Head of Front End at AI startup. Scaled application from 2 engineers and 6 beta testers to 10 full time engineers and ~300k users.

0:51 I smell HTMX be now!

Yeah, but then you have to write PHP. And that alone is a good enough reason to use Node or Go.

Cool, but what if you need 2 separate teams for frontend and backend? I worked once with a legacy app that used this kind of thing. IT. WAS. FUCKING. HORRIBLE.

Instead of the setinterval here i use the pusher it's works great.

This is just bad for so many reasons. Some of them were mentioned already in the comments, but I'll mention some others. No one seems to mention the inherent security issues with using innerHTM, so I'll just leave it here. You most likely don't want a production app that's big enough ever blindly rendering code it gets from an API call. Then there's the fact that you're transferring lots of data for... No good reason at all. You can see you're downloading KBs of data each request when that could be much less in a structured format. And all for what? Not be willing to parse it on the client? Sure, that may work for a table with two dropdown filters running locally. Try serving more than 10 req/s and you'll find out how transfer costs quickly skyrocket. Then there's request caching etc. you're just wasting server resources all the time for something a client can handle hassle free nowadays. Then there's separation of concerns, API deduplication, etc. You want to do it for learning purposes? Sure, anything works. But you'd be teaching yourself better by learning to do stuff you can actually deploy and maintain later on, rather than doing this mess of a thing.

Didn't need to import defineProps

I may learn Go, but the reason I program PHP is because it's not JavaScript, not because it's fast...

Now compare to python which handles request synchronously and is slower than php

What about laravel? Can you benchmark it?

Cool thought experiment. I suppose this take would apply for most hobbiests in a very simplistic web only dashboard. Tho this take does sound pretty out of touch with modern frontend, where SSR is used a lot and cross platform projects are a norm Would be even far off when you consider webgl and web assembly.

bro really used the slowest nodejs http framework as a comparison

Front end developers used to just handle the UI but now they have to managae state, make API requests and basically also do the backend's job. The responsibility of the front end engineer becomes too much at some point. It's a bad experience for the developer and unnecessarily complicated design for many websites.

I like this take.

Nha, i just endup recreating my own framework

I'd like to trust you but you have those logitech headphones that I have and don't like and bought before becoming an audiophile and hate that I've wasted 100 euros on them. I've barely worn them in the last 3 years.

Isnt this just measuring how many users can start a connection, not how fast the page would load for each user?

Don't give a shit man comparing a hummer with bulldozer.

Can You build a BlaBlaCar clone?

we're so back !

A lot of htmx mentions in the comments but what about unpoly ? It's look nice too.

retarded tweet though. a more accurate way to put it would be "15% of websites could be done this way so the backend developer doesnt feel threatened" but that wouldnt be as catchy

So you are making a request for server every time you want to sort or filter out table? That looks good only for 0 users pet project. Do you need to reload entire page to switch to a dark mode? Do you need to store the entirety of user data either at server side (poluting the db), or at the url (meh). Idk why people are scared of react. I'm a big js hater myself, but react is essentially a plain wrapper around html. Whenever you need anything slighly more complex and interactive than these stages examples, you will end up with the same signals and states react already provides out of the box. And let's be honest, perfomance is not the issue. Browser on mobile now is more capable than computers were 15 years ago.

naa, I still prefer to use angular.

Too cool!

Its a brilliant video please create a video for big laraevl inertia and reactr project and also guide use how to use websockets, echo in inertia and react

use symfony

Sorry, i have to disagree with you. This would work for small applications, but not for big. Good luck customizing tables in the backend, invent grouping, let the user change table size without saving it to database, changing the color of the table and so on. What would you need to do for it? You need to send the client states to the backend, hold it in the session and so on. After a while there would be huge more complexity, if you do it on the backend. There is a reason to let the client do, what the client should do and the server do, what the server should do. I've worked on a project with this infrastructure and it was crappy after a short time. Also: good luck to debug this code. Furthermore, what if you want to code a mobile or desktop application, based on the existing api, without using a crappy language like js for this? This would work just for simple projects

This is completely absurd. You make the claim that backend returning HTML "is the best way to build 90% of applications", then spend 15 minutes justifying why this is the best approach not on 90% applications, but on something that's way less complex than literally 99,9% of existing applications. Yes, your approach may be the best for this app - but who cares. Technology choices literally do not matter on something this simple. Try using this approach to build a real app - where a single change in state may propagate to multiple different elements on the page, depending on the change made and other parts of state. What is your solution there? Do send whole application state onto backend with every request? Or does backend take care of your application state, including UI state, and including which elements are or are not loading, so it knows which ones to update? This video really is a terrible attempt at justifying your original claim of 90% of apps benefiting from this.

Performance wise PHP is fast enough. The key term is enough, because sub millisecond performance just isn't needed for most applications. When I really want quick and easy development, I use Laravel for my frontend because it's very maintainable, and I use ASP for my backend so I have nice lang features, together with some extra control over my memory. That 30.000 is nothing tho. Requests per second say nothing until you run it on an actual production server that is doing all sorts of grazy stuff. Parallelized PHP is absolute garbage at creating reactive views that are performant. So yes PHP is a slow beast. But it's fast enough at what it does.

virtual machines are slow and heavy, literally 2 sentences later. docker makes a virtual machine ;P

you're using the built-in php web server, take HTTP requests entirely out of it and then compare, or simply put an actual production-grade server like Swoole for it to be an actual comparison

bruh phps builtin server is designed to be single threaded, its not production ready by any means you shouldve benchmarked php using nginx+php-fpm for apples-to-apples comparison

Isnt this basically just calling C++ code from PHP? Doesnt really prove anything.

I still find for most things, a hybrid setup is great. I maintain that the bar for grabbing a frontend framework of some kind should be very, very low. But that doesn't mean grab the most complex, sexy thing out there. Often, it means making 90% of a site work off a template engine, and when a page would work better as an SPA, HTMX and Alpine can probably handle it just fine. My favorite thing for getting a project off the ground quickly is the ADHD stack. Alpine, Django, HTMX, and Daisy. If your project requires more complexity than that, it'll tell you.

Is the font used in the code editor Comic Sans Mono ?

Since you were already using Laravel, why not also mention livewire

Thanks Andrew!

so we need to modify the backend code if we want to add a pure styling class for a, for example, blue themed instead of green themed dropdown etc. seems perfectly fine for a tiny project for a tiny userbase. if you want to scale, it can get horribly bad.

the best tutorial you guys can found on the youtube

Code in html templates is a nightmare to maintain with large applications. This is totally true for small to medium apps though.

now we can be extremely productive w/ PHP and still speed up the server later if we need. Awesome

There’s something called Next.js