I am such a contrarian that I cannot help myself checking out htmx now, because the react code that our expensive consultant wrote for us is a black box i don't understand. i did do some web pages back in the 90s so maybe this htmx is accessible to someone on the lower end of the web-scale like myself.
remember when everybody hated PHP because you had spaghetti code in it with all those mysql_execute calls and then somebody thought it was a better idea just to have javascript on the frontend and javascript on the backend to avoid mixing the two? Well.... then NextJS came in and became PHP but worse, worse performance, worse libraries, worse frameworks, worse environment.... let's just return to monke and use php with jquery, things were much simpler back then
Reminds me of php. The biggest issue I have with this is if you want to build a native app or expose an API later on you have to redo this work and break this out into api code and web ui code.
Thinking about this in the theoretical realm, there is nothing really different here than accessing an ORM in a standard server rendered templating language. PHP, Rails, C#, Java, etc already have conventions spanning back over a decade for being able to call an ORM or DB directly in a templating language so there isn't really anything new conceptually here. Stepping out of the theoretical realm into the real world, this is ging to get messy fast. Backend devs came to the MVC framework as a method of separating the concerts of different parts of applications for a reason, and there is also a reason this mindset has stuck around as long as it has. To suggest that whats happening here is some new or a profound way of breaking down barriers, and that these seperations don't have to exist is something every backend dev already knows. We do this for a lot of reasons, but in my experience its mostly to provide consistent interfaces for data access, sanitization, and error checking. I'm not suggesting that you couldn't do this here, and its definitely nice to see the JS world coming around to tempalting data access directly in rendered partials, but this to me reaks of, "They want to do this so badly, they didn't stop to think of whether or not they should be doing this". This will be great for small teams bootstraping projects quickly and breaking down barriers to getting work done. But I suspect this is also going to cause massive issues in query debugging, data sanitization, and overall maintainability. As everytime you "break down a barrier" to get something done faster, in my experience you always wind up learning why things are done the way they are.
12:17 "Ok lets switch to France then [via a vpn to test client side latency for somebody in France... while I'm in LA]" How is this dude respected? Clearly he doesn't even know the basics. A VPN does not move your browser to France FFS.
This is gold. Kubernetes has only ever slowed me down in the company I work for in terms of developer experience and their scale of operation doesn't even require it. They are planning for an eventuality that will never come to fruition.
I think a lot of the people hating on server components and server actions 1) haven't taken the time to learn how to use them, and 2) have difficulty understanding when to and when not to use the features they enable. Making certain things easier and opening up possibilities is a good thing, at least in this case. A little CRUD app probably doesn't need a separate dedicated backend, or an API, or microservices. If you're working at a large company with lots of separate teams, and need different types of system integrations, and have established technologies in place, maybe it's not smart to choose a full-stack framework like Next and implement everything through server actions. And for a greenfield web project, maybe it doesn't make sense to over-architect at the beginning, but instead use Next and server actions to get something simple and usable out fast. The different technologies themselves aren't GOOD or BAD, they're just more or less suited to different situations based on the needs of the project.
This is cool. Is it the future, the one true bandwagon to jump on? Probably in some circumstances. Like if the components are really supposed to be so tightly coupled to the server actions, and that's the end of the story, you could argue its not opposing separation of concerns, its all one concern. This is great then. If the concerns ought to be separated, then you better separate those concerns. Key thing here is recognizing when this is or isn't the case. And its not always obvious until things fall into place and come out of the wash. Given that, it can be better to err on the side of separation.
Very informative, Hey Theo do u really want to know why i follow your content? I'm 29y Fullstack dev (Node+React) since late 2018 Now days Sr. Software Engineer working remotely with American contracts I WANT TO KNOW IF MY BOOK VALUE (ALL THE SHIT I'VE LEARNED SO FAR) IS STILL HIGH IN THE GOD DAMNED MARKET! simply as that, nothing more, nothing less
I'd argue a better term is "transparent". This is already commonly used in audio compression to mean humans can't detect that any information was discarded. A similar principle can be applied to the Neuralink system. If the desired signal can be reconstructed, then keeping the noise is not only useless, but counterproductive, since the receiver will still have to filter it out. The keyword there is "desired signal", which is part of defining assumptions/constraints/requirements for the system.
Common Theo L take. Unnecessarily and overly emotional. Also polling twitch will do what exactly, you really think real devs can afford to watch live streams.
The DAL (we call this DAO in Java on the server side) is exactly how code is structured at $work. We do this so that we can have a services (microservices) with defined contracts that multiple front end applications can use. As long as we maintain the contract, no one cares how we provide the information. If a new application needs something similar but different, we can make a v2 of the service. Then other v1 service consumers can migrate when ready (or not). I can definitely see an advantage of making a component-based structure for API / service accesses that are unique to a particular application. Going through extra hoops "just because" engenders lots of extra code to maintain. However, if not done correctly, clarity and maintenance become challenges. This is where a well-designed DAL (like you are doing when I paused the video) is key. This enables developers new to the code base to find, fix, and extend an application with less chance of breakage. And as we all know, the cost of an application is not in its creation, but in its maintenance. And developer burnout is increased by being shackled to a code base that only that particular developer understands.
i love when someone tries to shit on someone or something then gets shitted on lol....and the creator being unhinged? good so many of us are sick of the stuck up politically correct pro noun using bs (this might not apply to him specifically but so sick of "professionals" in general)
one "issue" i see is that you might end up writing a client function which calls multiple server functions, maybe even in a loop, and it might not necessarily be obvious that you are calling a server function, resulting in an excessive amount of requests being sent to the backend
although that is probably something that can be easily cought by a linter (calling multiple server actions from a client function => fix: turn this into a server action instead)
But whether it's a function or whether it's an api call, you still are running the risk of sending many requests? so to me it doesnt seem any different - other than the fact you dont have to wire up a network call anymore, so long REST/gql :D
these things are so simple, obvious and common sense, that i find it scary that people in chat are still having trouble understanding server actions, api minimization and DAL. Like, architecturally literally nothing has changed, just the underlying transport mechanism is different. Its not that big of a deal What might help ease the confusion is if Theo started naming his files in standard well known pattern names. The point is that you still need a controller, and a facade, validation and sanitization and api minimization and a DTO and a service and a repository. And that is percisely what Theo made here. Sure they can be in a single file, like they are in t3 trpc, but the parts are still there.
2:20 - don't do this. This is isn't modern. This is as old school as PHP projects (or Java JSP/JSF) that mixed templates with code and SQL queries that everyone makes fun of nowadays and dreads projects like that. Modern web dev people reinventing the wheel again and repeating old mistakes.
The C++ reference is just plain wrong. But then again, so was the main point. There is no fail safe way to make programs and if you are trying that then Javascript is not the language for you. Try instead to find ways that make code smells obvious and make things break in a noisy way instead of just silently failing.
