Deja vu with this blog. Another overengineered abstraction recreating things that already exist.
Misunderstanding REST only to reinvent it in a more complex way. If your API speaks JSON, it's not REST unless/until you jump through all of these hoops to build a hypermedia client on top of it to translate the bespoke JSON into something meaningful.
Everyone ignores the "hypermedia constraint" part of REST and then has to work crazy magic to make up for it.
Instead, have your backend respond with HTML and you get everything else out of the box for free with a real REST interface.
>Everyone ignores the "hypermedia constraint" part of REST and then has to work crazy magic to make up for it.
Right, that's why I've linked to https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... the moment we started talking about this. The post also clarifies multiple times that I'm talking about how REST is used in practice, not its "textbook" interpretation that nobody refers to except in these arguments.
>Strawmanning the alternative as CGI with shell scripts really makes the entire post that much weaker.
I wasn't trying to strawman it--I was genuinely trying to show the historical progression. The snark was intended for the likely HN commenter who'd say this without reading, but the rest of the exploration is sincere. I tried to do it justice but lmk if I missed the mark.
I think I've sufficiently motivated why that response isn't HTML originally; however, it can be turned into HTML which is also mentioned in the article.
I have yet to see these mythical HATEOAS compliant applications, they must be so amazing and simple, example anyone?
And if it turns out that there is no such thing, should I conclude that all these people talking about it really just base their opinion on some academic talking points and are actually full of shit?
> have your backend respond with HTML and you get everything else out of the box for free with a real REST interface.
speak like someone who's never made a real product. Please enlighten us on how you add interactivity to your client, which flavour of spaghetti js? How do you handle client states, conveniently everything's on the backend?
We already have a way one way to render things on the browser, everyone. Wrap it up, there's definitely no more to explore here.
And while we're at it, I'd like to know, why are people still building new and different game engines, programming languages, web browsers, operating systems, shells, etc, etc. Don't they know those things already exist?
/s
Joking aside, what's wrong with finding a new way of doing something? This is how we learn and discover things.
No, it's not normal. The output is almost always song lyrics annotated with markup like [Bridge], [Chorus] etc. I think they're using something from OpenAI with a system prompt and/or domain-specific training on top.
It's not a pure AI output - I generated a bunch of lyrics in text (which doesn't use credits), selected the best one (obviously), padded them out with some repetition, entered a style, generated the audio a few times, selected my favourite audio, and edited the audio (poorly) by repeating a few bars of the intro to make it longer. You don't see the times it generated lyrics about X.509 certificates (even though the prompt was for them to be a valid X.509 certificate) or the times the vocals were unintelligible.
I think generative AI does work as a toy. You can ask for all sorts of insane nonsense and laugh at what the program spits out to fulfil your request. I was a paying customer of AI Dungeon 2 (before the incident where OpenAI and/or the Mormons broke it in a poor attempt to impose safety rules).
And while I'm looking at my Suno outputs list, the reason I ever bothered to use it was to see if it could render these lyrics as a ripoff of "Pure Imagination" from Willy Wonka (it cannot because it only makes actual music): https://suno.com/song/19d1a90d-9ed6-4087-94e5-89e41363726e?s...
(I'm assuming that you can open these pages just by having the links. Some of them are set to public visibility.)
The need to wax philosophical really shows how complex and overengineered RSC is compared to solutions from other ecosystems that are just as effective but far simpler to work with and understand.
I'll add I think you're mistaking the cause and the effect. I'm not trying to sell you on something; I don't give a damn what you use. Like literally, I don't. I'm not personally invested in that. I'm not being paid to work on this or promote it or whatever. But I've been thinking about this stuff for a while and I wanted to write it down on the page. And my thoughts tend to be longwinded because I prefer that style. I think someone will salvage something valuable from my writing if they find it there.
My point is that the entire approach is architecturally far more complex than is suitable for the vast majority of projects. You have influence and people will make real world decisions to choose unnecessary complexity because of this article.
Why do 150 lines when 10 lines of PHP is functionally equivalent to the user? The user doesn't care about your execution model. They just want some information or to submit a form. Adopting an RSC-like technology makes development more complicated and take longer.
If you're building Figma or something then sure, go nuts with the complicated things. The tradeoff probably makes sense.
For the other 99% of us, this model just gets in the way.
The execution model enables more powerful composition (reusable components whose functionality spans both client and server) which hopefully helps people make things people want faster (the story of our industry). Sam gave this argument a wonderful treatment in https://www.youtube.com/watch?v=9CN9RCzznZc, I don’t think I can make as compelling a case in a comment. But he fully represents my viewpoint on why. If you’re genuinely interested then do check it out.
One of the biggest problems with mixing client and server code like this together is coupling which is one of the reasons that client-server architecture was created to avoid.
I watched the video, and it didn't feel compelling honestly, backend frameworks like symfony have ways to compose client and server side code for years.
There are many ways to mix and match client(js) and server (php) in a composable way without react. Components can be created on the server side as well (mixing html+js+php). Only thing lacking is DX and type checking.
Most other solutions are not composable to the same extent. It’s not enough to be able to mix client/server (although that’s a start). It’s more about it going all the way — for example, the state of the client parts is preserved on refreshes of the server parts around them, the same components can be reused on either side depending on whether you want them to be state-driven or data-driven, state changes are predictably instant, you can stay within the same paradigm while moving code between highly interactive and fully data-driven (no awkward moving stuff “between PHP and JS” when something needs to be “more dynamic” and back when it needs some server-only feature), ability to send closures over the server to the client and back (lets you essentially .bind server actions over the network), all of this is integrated end-to-end (a client button can know precisely how long to display an indicator while the server is data fetching next page and the next client code and CSS are loading), and of course all of this being fully composable (you can nest server stuff into client stuff into server stuff into client stuff and they all retain state and refresh as you would expect).
If you don’t see what’s new about this I encourage you to look deeper because this definitely isn’t what backend frameworks have been doing for years so you are missing something.
I feel like it's a great bellwether that react has jump shipped as a viable way to build applications if the mindshare of maintainers/core devs/influencers are pushing in this direction.
the guiding promise of AI was able to figure out unstructured data. Manually crafting prompts and description examples for tools is a step orthogonal to progress. Searching for docs, great now you have 1000 tools saying they do same thing exposed to model, now we need another search on top of that?
Many countries have this in various forms and it works out fine. Generally illegal to interfere with the press and a good way to lose the next election
Sounds like you're assuming all software is SaaS that requires the provider to keep it available?
Software used to all be lifetime purchases by providing you with the actual program. If you bought a copy of WordPerfect in the 90s it will still work fine today even though no one is offering it anymore.
Thanks for sharing. I was planning on building something like this in April after hitting too many issues with Jina and Tavily but it looks like you've already done the hard work!
At the end of the day, most consumer software boils down to simple CRUD apps with various skins. Sure people have been able to make those for years but it was still time consuming to wrangle the no code tools. Now people can do it in an hour or two with simple English instructions.
reply