In server-side rendering, clients are sent HTML that they can see immediately
I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it.
It’s a neat trick but still second to useful content on the first page (that is the page you get to read, if it lets you).
I think a big part of the problem is how online education and bootcamps/college degrees for web-dev are structured. Often times people are so overwhelmed with the stack they are supposed to learn that quite obvious and important stuff gets lost. People just try things out until it works without understanding the underlying structure. If you come from a simpler MVC framework like Rails or Laravel, it enables you to focus on the really important stuff first, and explore from there. It is also much more rewarding to see some solid results early.
God help us. It's not his fault, to be clear, but God help us.
The problem is the dogmatism of it all. If you point to a simpler and a more obvious solution, your coworkers will ridicule you and turn you into an old man pariah.
For context, he's 40 years old and working in data science after a career switch from another data-heavy field. He's just learning web dev to build internal pages for displaying stuff, so no need to worry :D
It's not just about wage, it's about assigning appropriate work to peoples level and having them progress through the most efficient steps to mastery while also completing billable hours
Normally workers unionize to improve their poor conditions vs an abusive employer, and when they have little to no ability to find another job for similar/better terms. Is that the situation for software devs where you’re at?
That may be common circumstances where a union becomes the only viable option for the workers, but unions have additional benefits that something like it would greatly benefit the software industry.
In particular, it's the assignment of work to the union and then the union is responsible for pairing workers with the assignments which enables the union to create a training funnel where different requirements of the same job can be split among different workers of varying seniority such that apprentices are able to work on the easier items even when there are things beyond their skill involved in the overall work assigned to the union.
Typically a union does primarily exist to create CBAs for wages but this is another function of them which I think would be very helpful for SE and future protection.
So maybe not a traditional union is necessary, but I think there are some functions more or less exclusive to unions right now that would be beneficial to apply to SE. Hopefully that makes sense
The problem is that browsers started out as hypertext clients and unwittingly evolved into application platforms to implement, among other things, custom hypertext clients in it. Somehow “lets add more features to make hypertext more capable” turned into “you’re on your own now to implement a usable application with this big incoherent pile of impedance-mismatched features”.
Yep, and it's pretty nice. However, he talks about important things that weren't in Flash, like accessibility, and how to handle them cleanly.
It really seems like WASM will be the write once run everywhere runtime that was touted in the past. Java almost got us there but was too dependent on Java, whereas WASM is for any language. I've been using Flutter with their experimental web WASM support and it's very fast.
I think this makes sense for complex apps like games, CAD and design software, etc.
I hope it doesn't replace the lowest common denominator of HTML for generic apps, though, if only because it would dramatically raise the barrier to entry (not that your typical React app is particularly readable in the inspector...).
Yeah Figma is in WASM and it's great that it is. I don't see it coming for React apps, really. Or if it is, that the JS tooling itself will automatically convert it to WASM.
I personally use Flutter for a lot of my apps, as well as React/NextJS for SEO based apps, the combo works pretty well.
Yeah, Figma's tech is incredible! Especially when I use side by side with Microsoft Teams, lol. One's a complex layered drawing app with plug-ins and imports and the other is a glorified chat app... guess which one is 10x slower and crashes every half an hour?
I wonder if you could use it to call some existing C libraries. Maybe just add some wrapper functions to execute the compiled binaries, and return the result. As long as you keep the same order of arguments for the function call, this could be quite straightforward. /s
2nd law of Thermodynamics: Entropy increases over time.
Quoting[0]:
"The entropy of a system can in fact be shown to be a measure of its disorder and of the unavailability of energy to do work."
I rather like that - where "work" is the time spent solving first order business problems, and "disorder" is a measure of the energy spent not directly solving the business problem. AKA dealing with accidental complexity.
That's how we did it at my first gig with PHP and Drupal. I'm not going to say it was great or even particularly good, but given our work was split across different modules, you could easily have multiple people either uploading changes over FTP or doing some quick hacks over SSH. After all, you only needed to copy over your changes and not re-deploy the entire project. The server was a little Dell box sat under the desk of the 'CTO' in his office.
There were some cowboy-level engineering practices for sure, to the point that I'm not sure you could call it 'software engineering', but there was definitely some beauty in the simplicity of that setup compared to what we typically have to do these days. At least after you set up the box and the access to it, anyway.
By the way, we need to add another feature to our page, would you mind looking through that file so there are no class collisions? What do you mean its too long? 50k lines? Pfft.. But at least it 'gets transferred to the browser pretty fast'
Do these guys actually think you should only write a singular (or maybe even a low plural number of) html file(s)? That’s crazy haha, that’d be pretty rough to maintain!
Could they have been joking that, maybe, there’s a lot of folks who are a little too tunnel visioned on the newest most modern js metaframeworks that they have little or limited knowledge of the foundations of their ecosystem? Given that you know something about html files and basic web servers, was your position necessarily the original subject of the joke/point here? Surely it was! Gruff old school devs are so obstinate and short sighted haha.
You opened, intending to construct an argument on your genuine position, with a massive strawman, on a lighthearted commentary over a line from the article that was purposefully taken slightly out of context- not even remotely a tirade on “js hating.” You’re not having an argument in this comment thread with anyone, because no one was even discussing anything to begin with.
I think there’s things to laugh at here (like the original joke) that aren’t how genuinely stupid you think the commenter who is ironically replying to every of your comments in a vague and mystical tone.
My ducks are in the row and there is no pendulum swing. There is one only in people's heads. People who didn't learn the tools then (when JS era started) and are refusing to learn them now (when more and more focus is on SSR). These people's opinions are irrelevant as their only argument is that they didn't invest the time to understand the benefits.
I, too, hail from those lands overrun with the elemental curly brackets. Yet my understanding has matured and is now ready to receive new wisdom and insights.
I would be careful assuming too much about us, who are wise in the ways of the world and, dare I say, exceedingly goodlooking.
> These people's opinions are irrelevant as their only argument is that they didn't invest the time to understand the benefits.
Wouldn't the same be true of "JS era" developers who never learned the basics of a static website or a templated server-side app? If the issue is being too lazy to have more than one tool in your toolbox, then it applies to everyone.
Im14andthisisdeep :) Did I ever say otherwise? Tools are invented to make things more convenient and not learning them properly is not an excuse to whine.
You are wholesale calling people ignorant over a technology decision.
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Stop a second before you go into RSCs. Whatever you want to achieve ultimately is much easier/quicker/scalable done in real fullstack (or classic web-) frameworks!
Rails/Django/Laravel/… + Turbolinks/Htmx/… or even sprinkle some light clientside JS for fancyness.
Or go best-of-all-worlds if you happen to know Elixir/Phoenix.
But don’t continue the descent into RSCs, now matter how many people tweet about it. These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead!
Stay sane instead, ship actual products quickly, and earn that lambo!
Indeed, RSC reminds me of CORBA [1]. CORBA is a way to mix local components with remote components. CORBA is very mature and works in many languages. So why doesn't everyone use it? I would guess that most developers today have never even heard of it. Why is that? I would suggest that anyone who wants to invent another distributed component architecture should study CORBA and its descendants and why they have never really caught on. (Hint: hidden component boundaries mean hidden complexity!)
Meanwhile, the "server-rendered HTML" and "client-rendered HTML" camps are both doing quite well. I consider myself quite lucky to have both options at my disposal for every web project. I hope the work on RSC doesn't muddy React's support for pure client-rendered apps.
CORBA is one of the few technologies purposefully designed to violate both the entirety of the Fallacies of Distributed Computing and the CAP theorem. It's a case study in awful ideas, week long troubleshooting nightmares, and angry customers.
You don't hear about it for the same reason it's impolite to talk about your top 10 favorite snuff films with customers. There is no situation where it's appropriate and anyone flirting with the notion needs to be dismissed before they doom your company.
CORBA is pure evil and you should not speak its name so lightly.
Not to detract from your point, but nobody uses it because when network administrators everywhere started closing all the ports except for 80 (for "security!"), everybody moved to SOAP, that uses the port 80. And then, since the SOAP consortium doesn't have enough competency to create a full data transfer format, starting from XML and contained in a couple thousands pages of docs, in about a decade people said "enough!" and moved into what is commonly called REST.
The problem with component boundaries is there, but it's not really what CORBA did.
CORBA was a total piece of shit back in the day. Nobody in their right mind would chose it for anything today except as example of "don't do this when you're designing and implementing something."
It's an over engineered overly complicated design that leaves a lot of crucial stuff undefined, which made interoperability impossible. From a performance perspective it was crap. And debugging an implementation was almost impossible.
It's a great example of how architects can destroy a good idea by layering ridiculous amounts of abstraction into an incomprehensible pile of software.
And it shows that architecture without implementation experience should never happen.
> Or go best-of-all-worlds if you happen to know Elixir/Phoenix.
THIS... unless you're building something that absolutely requires a full blown progressive rich frontend app, (95% of you don't), liveview will do all the thins using serverside components with minimal jaavscript.
Not just that, you'll have a serverside thread dedicated to that user which allows you to actively push changes to the user's frontend without you having to write explicit javascript handlers.
>These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead!
So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is always there, but if that's your concern just build a traditional server templated site. The vast majority of SPAs have zero need for SSR and the complexity that it introduces.
So because a few forms need validations you turn your whole application into a JS hellhole?
That's the crux of the issue. It's not that JS isn't needed and small pieces of interactivity aren't nice. But we chose to turn everything into JS despite only really needing it for very small pieces of the app.
Back a few years I'd have small JS bundles included in specific pages that needed interactivity. Later people frowned upon that practice because it meant a ton of requests for the client, so we bundled everything.
Now, new JS frameworks send small JS bundles as you open each page, lol.
Why not have micro React (or whatever framework makes sense) pieces in pages that need it for the interaction?
Plus, server-side form validation is extremely easy to do and also removes duplication. Its been a solved problem for over a decade. I'd even argue back-then it was harder since browsers were much worse and basic elements were lacking. Today you add a `required` attribute in an input and it simply works.
I stand by it. Aside from a few exceptions, most apps have no business being SPAs. They go on to emulate a subpar version of a MPA, and people have to resort to absurdities like these server components to achieve the same experience we've had for 20+ years with server-side rendering.
You can absolutely render react components into non-root nodes to inject interactivity into static sites. It's a good approach if you're serving a bunch of static content and you want a calculator or interactive visualization, for example.
The point at which you should consider a SPA is when you are sharing data between most of the "pages" in your app, and there are multiple data sources surfaced in any given "page." In this case, you're going to have to jump through indexdb/localstorage hoops just to avoid losing that data on every page transition, dehydrating/rehydrating multiple types of records then passing them around via a context or somesuch. In that case you're on the hook for complexity either way, but the SPA version performs better at the cost of some SEO.
I didn't make any statement about what an application is, or isn't, or what percentage of the internet is in fact applications. That being said, things like Figma exist and wouldn't if the web was only static pages, so there's a compelling argument to be made for the existence of SPAs.
That's more an indictment of node's ecosystem and package management than anything else. Having helper libs for almost everything along with multiple versions of the same modules bundled is just a bit ridiculous. With functional deduplication across versions and a more robust standard library so people didn't need to add 50 NPM modules to do anything that would drop by an order of magnitude.
Beyond that, bundle splitting with lazy loading is very helpful, but it requires knowing that you can do it and some additional work on top of baseline bundling. Then you're nearly at parity with static sites in terms of individual page download requirements for the first view (assuming react/etc are cached CDN libs rather than bundled) but each subsequent view of that page is much smaller, faster and more responsive than static html.
There are definitely use cases where you want a render loop in web, pioneered by React, instead of traditional approaches for a web application. I think the pendulum swung too far and too many sites are being built as a SPA, but there are absolutely some "very good reasons" to build a SPA with React. As always, it depends on the use case.
> We moved away from server rendered UI for very, very good reasons.
In some cases, it's clear that it's a webapp and a SPA is warranted. In some cases, it should just have been a website, but yet there were organizational reasons to use react - producing technologically bad results in detriment of the users.
That is literally what RSCs are, so unlike most of this thread, I am glad to start using them instead of using some template language like in PHP or Python.
> Or go best-of-all-worlds if you happen to know Elixir/Phoenix.
Muxer here, and fun fact, Elixir is a core piece of our infrastructure and has been from the start! At the very beginning our dashboard interface was all rendered by Phoenix and occasionally a page would individually include React if it was a situation that truly needed advanced client-side interaction. Given that our first product was an analytics dashboard, that latter situation quickly became basically our entire dashboard and it simply made sense to move to a full SPA taking advantage of the API we were exposing to customers anyway. This was 2016, so LiveView didn't exist at the time, but I'm still not sure I'd make a different decision for that product today.
The blog post is talking about the application that powers our public marketing site, which has a pretty different set of needs, but figured I'd throw it out there that we use and love Elixir/Phoenix! :)
Yeah I've used Gleam but unfortunately using a language for production apps that is not well supported as Rust and even Elixir is is a dealbreaker for me. Gleam is fun to play around with though.
I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline.
And now its extended with serverside components.
I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running.
I retreat back to my simple 10kb component framework in which i need only f5 to rebuild.
They simplify the on-boarding of 6 months boot-camped front-end developers. They can start working and delivering right away despite not being able to tell the difference between front/back ends and having no understanding of servers.
I can’t edit comment now. Not sure why some readers perceived my tone as negative. This is a neutral view and am just explaining why React server side is getting adoption and how this is being driven by the business side of things.
To be fair, we tend appreciate these kind of features when we are on the other side, buying, say, IKEA furniture. I respect, but don't particularly want to support professional carpenters if given the alternative. E.g. you can have cheap shit now or wildly expensive "proper" products later where the "proper" means something I do not and can not appreciate - to put it simply I know wood is made from trees and there ends my appreciation of the craft.
Getting me "on-board" quickly with some basic furniture is quite helpful, although it requires IKEA-level infrastructure and investment to get these things in front of the buyers which is definitely not easy. Dare I sare ridiculously complex?
When I was younger, in a new space, my priority was FILLING IT so I could go about my life. I appreciated how easy it was to fill a space with Ikea.
Now that I'm older, in an old space, my priority is EMPTYING IT so I can go about my life. I now appreciate how permanent your space can be if you carefully deliberate each addition.
Exactly! These frameworks enable people with 6 months of "software developer" education to enter the industry and enshitificate our careers with their minimum wage level understanding of actual software engineering, dragging all of us down to their salary level.
If your career can be significantly affected by devs fresh from bootcamp
Well, there are certainly problems if that's the case. But it's not necessarily senior ICs that are the problem.
I've experienced a few companies where "boot camp yahoos" wound up essentially running the show to ruinous effect. Why? They had numbers, essentially, and management was too hands-off to prevent it.
To give a specific example: we had a product where our UX was basically: fill out this HTML form to apply for a financial product. Traditional dinosaur-style server side rendering was more than enough.
The front end boot camp yahoos somehow wound up forcibly moving us to React. They got that pushed through and approved before anybody knew about it because they gave a bunch of BS stats to management who didn't care and also didn't have the technical chops to spot the BS.
The end result was that simple changes to the UX (like adding a question to the form, or removing it) required 1,000+ lines of code across multiple repos. Hundreds of hours dealing with that mess for zero gain instead of actually doing things that made the company money or improved our process in meaningful ways.
Senior ICs had no real chance to oppose this plan, and many of them were happy simply to get "React" onto their resumes.
So yeah, problems aplenty, but it's possible to be an IC and have one's shit rocked by this kind of thing through no real fault of one's own.
(I'm not crapping on React specifically here. It is powerful and there are use cases where it excels. I am also not crapping on junior or boot camp engineers. They are doing their best. It's a management problem.)
You describe the scenario I am complaining about. These boot camp developers do not have the background for large scale engineering, yet get cast into it side by side with real seasoned engineers. However, that real seasoned engineer is a small fraction of the "dev team" and gets overwhelmed by the boot camp developer's group thinking - their opinion is just as good as the guy with the CS degree they figure, after all, their boot camp crowd seems to win the debates! And the employer's development quality goes to shit as the people actually trained on large scale project development are overwhelmed by fast food educated "developers".
However, that real seasoned engineer is a small
fraction of the "dev team" and gets overwhelmed
by the boot camp developer's group thinking -
their opinion is just as good as the guy with the
CS degree they figure, after all, their boot camp
crowd seems to win the debates!
Please don't do that; it's effectively turning "makes minimum wage" into an insult. There are plenty of people that earn minimum wage that are good people, doing their best, and (in many cases) doing a very good job. This is exactly the kind of wording that turned various minority terms into insults, as we shouldn't be doing it.
I see your point, but in my case above the term usage is correct. By stating "minimum wage level understanding" I am equating the work they do to be equal to what a untrained minimum wage employee is expected to be able to accomplish. These "boot camp developers" are not engineers, and are barely developers at all. They are logical pattern repeaters, with an extremely short list of logical patterns they know how to use. Presented with the open ended work actual software developers are commonly tasked, they reach for an ungodly large number of supports and produce these modern code crap piles that are growing oversized data centers, duplicating all over the landscape. They're fantastic for selling more servers, and that is about all these boot camp developers are good for - we end up cleaning up their crap piles anyway.
I don't really buy this argument. Raw CSS/HTML is easier to understand. At the end of the day, all frameworks really do is remove `getElementById` and a couple helpers like `element.style.display`. This does make code MUCH cleaner, but the argument is that raw code isn't easier to understand.
I have also had a couple of CSS wizards that wrote all the styles by hand - sounds great until someone has to fix it, even a senior designer. In short, a well-used framework that's understood is not necessarily easier, but it does lead to an agreed-on set of abstractions that make things easier to understand. Angular and React are very much there for a reason.
That’s not totally true though. React, used correctly, lets you use and share a mental model where you have clearly defined the minimum complete information required to display any state of the app, and separately you have a set of simple functions which reliably convert pieces of that data to correct html.
That’s insanely powerful and massively reduces complexity in highly interactive apps, because it means you no longer need to think about “user did this, update this here now, and here and here” chains, and can just do “user did this, update the state” and have that state update render potentially hundreds of changes across the app without needing to do additional implementation.
But if you aren’t disciplined with maintaining, or don’t understand the difference between pure functions and side effects, and fall back to hacks to try to “make things render” or “stop wasting render cycles” you’ll end up with even more complexity than necessary.
Using react as another version of `getElementById` leads to a horrible mess much worse than writing vanilla javascript, and most people who have that complaint are doing it to themselves by fighting react either unintentionally or on purpose to show how it can be bad when abused.
Raw HTML and CSS is much easier to understand, and mandatory to understand because at the end of the day creating HTML and CSS is the only goal, but higher level abstractions can be super useful to manage complex projects, and the mental models and abstractions are the actual benefit.
That's a good addition - I was being reductionist by saying it eliminates a couple of functions that identify and modify elements. With that said, I feel it's still pretty close to being "just that" - I understand the details of everything you listed, but at the end of the day it just keeps track of individual displayed items, if they are parts of objects and regardless of how they are passed in (params, state, context, etc).
To give some abstractions out of the box, mostly, so you don’t have to reinvent the wheel - the demands of a lot of websites and applications nowadays include interactivity on every level, very fast and smooth ui population, and pretty animations. Sometimes the tools are great for working in huge teams on the same codebase, sometimes it’s for giving a lot of features to a smaller team.
> the demands of a lot of websites and applications nowadays include interactivity on every level
The demands of the PM maybe, most users just want something the works and gets out of their way.
> very fast and smooth ui population
Neither of which your average JS/SPA/behemoth is actually good at.
> and pretty animations.
I’ll give you this though, JS web apps certainly do rep some pretty animations, often at the cost of thrashing my CPU and ram.
Crazy idea, but maybe, if instead of spending ages building “interactivity” we just built “applications that worked”, we might actually have less mess, and build better products.
Having seen systems be built up over time that do significant things (or run on many platforms, or have lots of abstractions) a lot of the time the tougher parts are.. well, complicated. Some of those tools are to make things better for a lot of programmers working on the same project. You have to have some amount of structure then. Sometimes it’s so business people can create content.
“Why doesn’t it work simply” is often a business decision.
Ironically, “Web Excel” doesn’t use any of them. And if you asked someone who can create Excel to implement it in a webpage, they wouldn’t probably even think about these frameworks seriously.
The real promise of these is web forms with a little interactivity. Anything more complex and you start to fight with it to drop back down to the level where it’s manageable.
React is a little bit painful and massive overkill for web forms actually (compared to other approaches).
It’s the fighting with it that’s the issue; my experience is that a lot of devs go in to “force this stupid framework to work” mode and blow up tasks that should be 10 lines of code with no edge cases into 50 or 100 which “mostly works, good enough.”
React is by far the most adopted framework for desktop-level or near-desktop-level web applications.
Not sure which web-based spreadsheet app you're talking about, because there are many that do use these frameworks. Here's a PS/AI clone built with a Svelte frontend: https://graphite.rs
What kills me is that many websites would be better in every way if they were just html and css. I have come to think of it as premature optimization for some fancy capability down the road. It's like telling people they have to hire engineers to take core samples and do seismic modeling before building a chicken coop.
As evidenced by the large numbers of production html and css apps that are outcompeting their competitors who use modern web technologies with greater product quality, and the swathes of customers who state their preference for these experiences.
But seriously I have no idea of a single remotely well-known application that satisfies the above. If the modern web is so bad where are the products that prove that it can be done better more simply? There’s billions to be made if that’s true in all industries, is nobody skilled capable of capitalizing on this gold mine of opportunity wherein the entire industry is self sabotaging?
I’m left to conclude that these HN commenters with their hot takes about how the modern web sucks just generally either don’t understand what makes products successful or never have truly experienced the issues these frameworks solve for.
While that is true the current state of reddit UX allows them to succeed by virtue of critical mass gained before they went nuts. If you created a new site with that UX you would get nowhere.
The simple truth is people are drawn to websites for what they get out of them.
I recall being turned off by Reddit's UI when I stopped using Digg. The content was so incredible that I learned how to love it. And now they've killed Apollo so my only interaction with it is via Google search results for my problem du jour.
It usually takes government to tie people up in these sorts of knots. These people have enthusiastically done it to themselves. Resume driven development is a hell of a drug.
This is precisely why you see this move from complexity. The younger devs are beginning to see it. Just like we dumped atrocities like SOAP and XML in favor of simpler and more ergonomic tech, this generation is learning - again - that complexity kills (and makes this job intolerable).
Who knows, maybe software development is going to be fun again, even if for a few years before the new batch starts turning it into a mess.
It’s the interest rate. When rates are low, devs are paid to build complexity, new frameworks, tools, languages. If the interest rate stays low other devs will get paid to play around with those new frameworks, build more complexity on top and so on.
SQL, html, C … get things done. When rates go up, these non-bs technologies are incentivized. Paying devs to create new frameworks/apps/products just so that those devs are happy and don’t go work for the competition is what results in complexity for complexity sake.
Those who hitch their success to the latest greatest shiney new bs tech are the same who used to sneer at those who didn’t cover their webpages in flash animation. They make the mistake of thinking the current way is the best way. It’s not old vs young, these two mindsets exist across different stages of the lifespan. Generally speaking, older people have more data and will therefore spot the patterns/cycles a bit easier.
After kicking and screaming about learning yet another React framework I took the time to build an app fresh in NextJS and it really was a breath of fresh air, felt more like a mature, simpler form of React.
Feels like bloated garbage to me. "Hold on, let me make an MVC React framework with a Node API, so you can call your APIs from another API!". Thanks Next.js. Really wanted this. Honestly, might as well go back to Angular at that point - no redundant "API" there, at least.
Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSideProps' function that will do magic and generate component props, but it has to live in the page, so the page gets extremely bloated, oooo."
I hate Next. And I realize "hate" is a strong word that takes some earning.
Have you tried SvelteKit yet? I can't say it lacks magic, but that magic is focused on eliminating boilerplate, not hiding where everything is coming from and going to.
It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left.
const { count, setCount } = useState(0);
becomes
let count = 0;
There is no more useMemo(…) or useEffect(…). They just don't exist. There's no need for them. State management "just works" by using a store variable like $store. No more explicit subscribe and then having to remember to set up an event callback to unsubscribe and avoid a resource leak.
Vanilla JS libraries typically work out if the box with it without some bespoke wrapper or adapter for your framework. ("bind:this" is really handy.)
Web development with 99% less BS. Lets you focus on your problem, not on your framework's abstraction leaks.
the only downside for me is that there aren't many mature UI libs for it yet. I was evaluating it for a Tauri-based project but I went with React instead because of this.
You guys can try https://bulma.io/ as a middle-ground. It provides some fundamentals styles that aren't married to JavaScript, so there are never any conflicts with any SPA version. It's not widely used, but it worked well for us before going to Material UI as the team grew and the designers wanted something everyone is familiar with.
Yep, the amount of UI component libraries for React is truly staggering.
I myself am more of a clean, standard HTML with PicoCSS kind of dev, but that model doesn't work for everyone. Some might be surprised how much plain old HTML and the ease of development for Svelte components narrows that gap, but I'll be the first to admit the gap absolutely exists.
Oh! I forgot one of the best parts! CSS is automatically scoped to your component. No manual shenanigans. No weird naming rules your dev team have to agree on. No giving up and just using inline styles. No hacks.
Just make a descriptive class name and write your CSS styles. That's it. You're done.
As long as a framework invents their own HTML-like DSL, I'm not using it. I've used enough Vue back in the day to know I wanted to move to React where I can use actual JS, as well as get excellent TypeScript support out of the box.
> As long as a framework invents their own HTML-like DSL, I'm not using it.
Okay, that's a choice.
> I wanted to move to React where I can use actual JS
You… uhh… know that JSX was literally invented as React's own HTML-like DSL, right? And that TypeScript is not "actual JS", right?
Just food for thought: HTML can exist and provide tremendous value on the frontend without JS. JS on the frontend without HTML is… not quite as useful. Be careful about which technology you want to be the central player.
I knew this comment was coming. JSX is not the same as the DSLs of Vue and Svelte. They often have poor support for TypeScript and cannot be mapped, folded over etc, because they are not "just Javascript with syntactic sugar," they are a much more rigid DSL. Trust me, I've made a lot of Vue sites, I know what it's like to use JSX vs that kind of DSL.
Never mind that TS is a superset of "actual JS," your point doesn't even touch my argument which is that I want type safety, such as when props are missing or invalid types, and so on. Even if TS is not "actual JS," that's a semantic argument and doesn't matter as long as type safety exists. I've even written sites in Rust via Yew, works great and outputs HTML at the end of the day.
> Just food for thought: HTML can exist and provide tremendous value on the frontend without JS. JS on the frontend without HTML is… not quite as useful. Be careful about which technology you want to be the central player.
Not sure what you're talking about with this point, I never said HTML isn't useful.
Why would I like HTMX if I already said I dislike HTML-like DSLs? I tried it, it has the same issues as Vue and Svelte DSLs. I don't want to turn HTML into its own programming language when I have a perfectly good one through JS/TS right there that I can use.
The API isn't redundant, it's convenient. You don't have to use it. Just delete the /api folder and make your requests either from the client side or fetch the data inside the handler that you're complaining about. With the new app router, you can fetch it from the server component itself without the handler.
Could you elaborate on the last point or link me please?
I disagree on the convenience point - it's bloat and not in the sense that people say "IDEs are bloat". It's regressive in going back to an MVC pattern in a framework that's meant to be an SPA and completely violates the "There should be one, and only one, way of doing things" principle in that it adds confusing options that people end up using in practice.
Next.js is pretty convenient, not sure why people find it so inconvenient. With the pages directory, each page is its own page, just like in the PHP days. Why do you think it's an MVC pattern? I don't use Next like that at all, it's just React.
See my comment above - it's greenfield projects too. Company I work for had a nice .NET Core / Gatsby React set up with reasonable Microservices on Azure. New leadership came in. Rewrote it "all" (3 years in so far) into a wait for it, MONOREPO! in Python (at least they used FastAPI), Next.js (just to have a useless API which calls other APIs, because apparently 'cookies are more secure than JWTs' (I guess they think not being able to fetch them in JS is somehow security), and AWS. So far it has half the functionality, 10x the libraries, 100x the confusion, but hey, at least we went from 5 devs to 100 just so everyone can be confused TOGETHER!
This kind of take really annoys me; your pipeline can be as complex or simple as you need it to be for your specific use-case. If you want to build an application using static file, or a little Makefile that uses a single esbuild command, or a hulking Webpack configuration with 30 plugins – you can easily do any of these in line with the demands and complexity of what you are trying to build.
Also, evaluating tooling based on how easy is is to create a "simple hello world" is only useful if your work involves creating "simple hello world" applications, which it doesn't.
One can choose to limit complexity. Nothing is stopping a personal from building things with html, css, and vanilla js.
Think of XHR -> Ajax -> Fetch API or others (Axios).
No one is stopping you from writing out a 20 line XHR request. You can also write a 2 line Axios (or some other XHR-wrapper library) request.
After I took the time study webpack (a day) or reactjs (a month) for example, I really appreciated the options webpack brought (code related plugins), and the structure reactjs brought to my project.
This blog post covered SSR better than most blog posts I've seen
Anytime SSR or any of its derivatives comes into the conversation I always ask myself if things are becoming unnecessarily more complex. React server rendered components sounds like it's taking things too far - it goes against the natural developer experience DX order
If your complexity on the app is doubled and it slows and confuses all the developers with increased coding footguns for only a measly gain in performance, is it worth it?
Good old php sites and rails app with no SPAs have worked fine over the years
This stuff appeals to a breed of management in the same way "full stack development" does, which is to say those in denial of the need or value of specialisation.
The other benefit of such developers is they don't need teamwork. You just throw a feature request out at each dev and they do it end-to-end with you oblivious to the mess that is being created in the process.
Hah, that breed of management predates the JS world of crap. My current manager sees no problem in the job postings ridiculously listing every single language/platform we have worked with, even 30 year old 8086 projects, even when any new hire will most likely be touching none of that and will be writing some mundane C for an ARM.
"It doesn't hurt to list everything!" - Him
"Why the fuck would someone want to apply to what looks like an absolute hell-hole?" - Me
"But they should apply anyway if they know some of it!" - Him
No shit the quality of applicants is sometimes not the greatest
I'm thinking of joining Kroger to help with the Albertsons merger. They are looking for Java developers, cool, some sanity. Learned they have decided to build all new stuff in Go. Like WTSF people? I can find no justification for building mundane business systems in Go. Ugh...managers.
You want to use substantially less RAM and therefore reduce the number of instances/containers you need to serve requests, thereby non-trivially reducing infrastructure costs?
Or you're on AWS moving toward a more event-driven or serverless architecture where Java doesn't really have the same flexibility (and you don't want to retool your builds for GraalVM)? Go lambdas are really fast and trivially easy to write.
You want substantially faster build times to reduce developer idle wait cycles?
There are plenty of reasons to move to Go.
(Note: I last coded a Java service last year in v17, and my first Java code was using v1.02. I'm no Java hater.)
I get what you are saying and I can agree with that. It would be nice if that level of performance was their main concern. However, we are talking about an org that never has full dev staffing and has a lot of turnover and needs to respond to business needs quickly. I would not want to be trying to hire Go devs in that situation.
They have banished AWS..."competitor." A company that can easily justify their own infrastructure (and save a ton of money) is plunging into the Microsoft Azure hot mess. I could go on and on about a lot of other issues brewing there. Very dysfunctional and panicy trying to look hip to investors in comparison to Wal-Mart and AWS. Basically dragged kicking and screaming into online ordering and pickup/delivery and trying to act like it was their idea (very much had/have a browse-in-store sell you more crap you don't need model).
I'm a life long customer of many of their stores and have been plugged into their tech issues via various contacts for about a decade.
Look at your computer. Are all its parts and pieces strictly necessary to display the text "Hello world" on your screen? No. Why don't you throw it away and buy something simpler, then?
React is a general purpose web framework, and is routinely used to do more than serving static documents. I would argue it was never even designed (originally) for that use case. And yet because it can, we have to have this tiring endless debate.
> When you're writing a specific program, e.g. it's never going to be anything more than "Hello, world!", why would you use the fattest framework when you can write it in plain HTML?
Sorry, I guess I disregarded it because I figured we were talking about serious programming, not literally "Hello world".
And if you're writing a single "Hello world", HTML is overkill. Make a free website on a random platform and literally just write "Hello world" in their WYSIWIG editor. Or hell, just serve plain text with "Hello world" inside, browsers will render it just fine.
As you get more experienced in programming you'll inevitably inherit projects that you didn't have any say over, when that time comes come back to this comment, I'd be interested to hear if you still feel the same way.
I have inherited such projects. But it seems like you're talking about code that is no more complex than hello world, as you've quoted, so it wouldn't be too complex to do in any language or framework. Now if you do inherit a larger project that you don't like, well, you either work on it or you switch jobs.
> Now if you do inherit a larger project that you don't like, well, you either work on it or you switch jobs.
Which you wouldn't have to contemplate if your predescessor had simply used the right tool for the right job, right? Such as not using an over-engineered framework for a problem that didn't need to use one. :)
I mean sure, but I wouldn't work at such places anyway. One cannot escape complexity, it's either in your code or in other people's code that you use. Don't overengineer, but not everything you'd think is overengineering is actually the case. Otherwise, just work in assembly.
It is also interesting that you haven't responded to the other comments that call out flaws in your argument, just mine, perhaps because you don't have an answer for them either, as your original comment is now dead.
I did not flag your comment, if that's what you're implying. I can't downvote comments I reply to and I'm pretty sure flagging has no effect either on such comments.
But yes, it's still interesting that you haven't responded to those other comments, as I've said.
Yikes! You can't post like this to HN and we ban accounts that do.
I don't want to ban you because your account has been around for a while—but when I look through your history I see so many comments breaking the site guidelines (and often quite badly) that I don't think we have much of a choice. However, we also haven't warned you before, so I suppose it would be fair to start with that.
If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules from now on, we'd be grateful. That means no more personal attacks, putdowns, name-calling, or flamebait—at a minimum. We want thoughtful, substantive, curious conversation. I did see at least one comment on the good side: https://news.ycombinator.com/item?id=37235139, which is a nice proof that you can do this. Please stick to this from now on!
I find it curious that we always see these opinions expressed about front end frameworks, but no one seems to have much problem with all of the complexity in back end frameworks like node, Python, Java, .Net... I have a sneaking suspicion that people are just more used to having complexity hidden from them behind a framework install, whereas front end puts everything front and center since it's all delivered to your project via npm.
The whole point is to have JS on front-end and beck-end, right? What is serving the JS? Isn't the server Node?
And large security surface means just one compromised package is required to get on the server side. If an npm update gives you security warnings after a few weeks of a vanilla project just sitting there, something is very wrong.
Sure, you could say the same about any language too though. I've used static site generators in Rust too, or Python, it's the same problem. People still use them because the benefits outweigh the minute risk of being compromised.
that's still better than CRA, to make the point a few weeks ago at work, I counted > 800 dependencies and 6 high security vulnerabilities warnings. If facebook can't get their shit together, who can?
Said no one ever. I can fully understand you not having Node installed (although having any kind of toolchain installed is a prerequisite for any programming so that's a weak argument against Node). But please don't tell me that somehow you will get an old version of Node after you just installed Node, because this is just reaching now.
> - npm start
> - get an error: Error: ENOENT: no such file or directory, open '/tmp/my-app/.next/BUILD_ID'
The README that gets generated with the project literally spells out the correct command you should use to run the project during development (which is not `npm start`), so this argument is also pretty weak.
What do you code in? For any language if you don't have the toolchain set up, obviously it'll seem laborious to install it, it's not a knock on the framework used on top of the toolchain.
Java/Kotlin. You define where to get the dependencies in a simple script, you define the version of the build tools, a wrapper script fetches the build tools (gradle) for you and that's it. Everything is neatly cached system-wide where possible and on a project-level otherwise. No conflicts, no shenanigans.
Which Python, 2 or 3? How will you handle local versus global dependencies? Will you use pip, conda, virtualenv or something else? How will you package up the code and/or executable?
echo - command not found (maybe you're on Windows)
browse - no browser installed
edit - no editor found
See, I can do the same thing. In any case you need a toolchain installed to actually program in the language you want to program, even if that toolchain is minimal. Complaining about a toolchain not being installed for the thing you want to do is not very useful.
For sure. Ever had to debug a bug deep inside of a webpage's code that relied on 5-10 preconditions to get it to appear? Without HMR, you're spending a lot of time F5ing and navigating to reproduce/fix it.
If only there was a way to programmatically reproduce the conditions under which the problem appears and then exercise the behaviour that triggers the bug. Then some code could verify whether the problem still appears. Once the problem is fixed this same “test” dark magic could help ensure the problem does not occur again.
You can add a test after debugging, no one's stopping you. But yes, it's annoying to debug some UI issue and having to set up an entire integration test for an issue you already know is there and can navigate much more easily via a mouse than via linking through HTML tag ids.
First, HMR doesn’t magically put you into a specific program state. Second, you can still HMR any website, as it is a feature of a bundler, not a web framework.
HMR is a feature of bundlers but your frontend code has to specifically interface with it if you want JS changes to live-apply to a running page without losing state instead of refreshing the page. With React, you have to use react-refresh in order to have HMR support. Frameworks like NextJS configure react-refresh and the bundler's HMR features together for you.
I had a tool that would automatically reload the page when files changed, it was great!
But I get what you mean; reloading a page is fine for simple pages, anything bookmarkable, but there's heavy weight pages on the one side, and state on the other. With hot reload, we're currently developing a React Native app, we can e.g. type stuff in a form field, update code, and the stuff will still be there while the behaviour around it changed. It's neat. While I miss native iOS development a bit, I don't miss the recompile/relaunch cycles.
I didn't like the idea of moving to frameworks but it does make things simple again. It is probably slightly simpler than the stuff before SPA (Django, RoR).
There is overhead with working out where something, should be rendered but, in my experience, a lot of the issues are raised at compile-time and are quite transparent (the articles overstates the issues you have here, there is mental overhead but it isn't bad). The SPA period of React was awful for complexity (this was also when React had lifecycle methods, wasn't well-integrated into webpack...awful).
I can comment on personal experience with this. I've been building a new application using next.js and its new `app` directory setup.
First, it is hard to reason about what is happening where (server or client). If you want to know then you have to investigate and most of the time when I'm cranking out code I don't pay too much attention. As he mentions, it is really easy to make a small change and then all of a sudden some large part of your page wants to move from server to client. I know I'll have to do a careful and time consuming page-by-page verification before I finally ship - and that sucks.
Second, many existing React libraries are assumed to run on client because they use hooks. This can drag code onto the client. The whole point of fighting with this new paradigm is that you get server-side rendering which means fast load times and SEO. That is totally wasted if a library you are pulling in refuses to play nice.
Third, there are bugs in the new next.js app directory paradigm. It is still new and it is very complex. Things like dynamic routes and parallel routes and their interactions can just completely break. I've personally filed an issue on next.js github that gained a bunch of "me too" comments. One approach I was taking that was broken was recently fixed by a vercel dev but I had already chosen a new approach to work around it.
The most annoying though, is that their dev setup does some lazy-loading and caching magic. I think they try to compute the differences on a page and send partial updates over a web socket or something like that. It can get completely broken and you end up on an unrecoverable state. Sometimes a re-compile will trigger some communication from the server to the client and when I tab back to Chrome the tab is completely hung and I have to use the Chrome task manager to kill the process.
It is all just very new and in the stage of many rough edges.
I might be loose with my terminology, but hooks as standard as `useState` or `useRef` will trigger errors like:
You're importing a component that needs useState. It only works in a Client Component but none of its parents are marked with "use client", so they're Server Components by default.
There are ways around this, some of which he mentions in the post. It can just get tricky when you are trying to do complex composition.
Another thing that hits me is when I have a server component that is marked as `async` and then for some reason it ends up on the client and I get the error that says something like "We don't support async components on the client yet ..." and I have to spend some time looking at my display hierarchy trying to figure out what is causing a client to import it.
It reminds me of the "colored functions" blog post about async/await. You end up with colored components in your app which otherwise look and act the same. But now you have to be careful how you compose them together.
Actually, it's worse than that. Next has started throwing errors if it statically detects you even _importing_ hooks inside of a React Server Component environment:
To the point that Lenz Weber( a maintainer of Apollo Client, and my co-maintainer on Redux Toolkit), is considering resorting to a package that wraps and re-exports all of React's public API just to avoid that static analysis:
What I love about this is how PHP and JavaScript had basically the same syntax (minus a $ symbol here or a var keyword there), and then NodeJS was like, but we want to run JS on the server! And now, 15 years later JavaScript has finally caught up and it’s basically the same as PHP, but with more acronyms and a steeper learning curve (to be fair, streaming data from server to client components using suspense is cool). I’ve been using NextJS 13 and I love how it makes SSR as easily achievable as it always was with PHP and always should have been. I’d recommend it highly.
In fairness, PHP prior to v7 was either a dumpster fire or a dirty bomb depending on how far back you go. When folks called it a fractal of bad design, it 100% deserved it, and folks rightly went looking elsewhere to solve their problems.
PHP is a phenomenally better language today, and folks really should take another look, but let's not pretend it was always anywhere near as good as it is today. Not by a long shot.
Also, don't judge NodeJS based on the React ecosystem. The sheer mass of APIs and wrappers needed to get a React-based system running is no one's fault but the React community. Stockholm Syndrome at its finest.
PHP has as much client-side rendering as React SSR does.
I think the sleight of hand that is happening right now, and that gets people a little confused, is that React is shaping up to be this thing that handles both front and the backend where other solutions can't do that. Sure – but it does that by overloading and complicating what React once was (neither of which per-se negative, I think it's just an apt description of what is going on)
Where other solutions might have abstracted the frontend part into a thing with a different name (or not bother doing it at all) React chooses in a rather unprecedented move to call it all just... React (well, there's Remix and such, but alas). Which is fine, as long as you understand that this new "React" will now probably lead to "React Frontend Dev" and "React Backend Dev", because the work and the complexities that these rolls entail did not just disappear by rolling it into the same name.
It's not entirely clear if architecturally there are going to be more benefits than footguns, but I think it's cool that they are trying.
React borrowed these concepts from Solid, SvelteKit, and Remix.
Not that there’s anything wrong with that. It’s pushing things forward. (And by forward, I mean, yes, also a little backward. We had server-side dominance with php, etc., then frontend-only with Vue/React… Now we finally get to serve our cake and consume it, too.)
I sometimes hear snarky comments about the proliferation of all these frameworks. But here is the tangible benefit of that “competition.” (Really more cooperation than competition)
More like React scrambled to add a feature to check a box in a comparison chart with the upstarts no matter how cumbersome or disruptive the API changes ended up relative to existing codebases.
The new frameworks were poised to eat React's lunch, they knew it, and they needed something quick to hold back the rising tide.
They may succeed, but only due to inertia, not a better/cleaner solution.
I had my own server side component system in PHP, 20 years ago.
And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially.
Technically it wasn't client side rendering but it wasn't far from it.
And for actual client side rendering I experimented with compiling my HTML templates into XSLT and sending XML with data instead of HTML to the browser and letting it render it to HTML using provided XSLT. Because it was blazing fast when compared to JS at the time.
So, yeah, I guess thank you industry for coming around to what some twentysomething years old made just to build some websites for his freelancing.
I'm sure that React is engineered way better than not only what I achieved, but also what I could ever hope to achieve. I'm not against React. I'm just saying that it's an implementation of really natural (good?) old ideas. Just in JS.
> And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially.
I did the exact same thing. I made a page with a table that was fully rendered server side. Any change in the display, such as pagination, sorting or filtering would trigger the same PHP code that returned a HTML fragment. The Javascript for that was easy. Just send an AJAX request to the server and replace the <tbody> element with the new content.
The PHP code itself was separated in components which made it easy to share the rendering logic for the initial page and the page used for the AJAX request.
React solves this in a more convenient way, but I am really surprised that we had to wait until 2023 before it happened.
I never liked NodeJS; on the one side it was innovative in that its concurrency model allowed for faster back-ends, but a lot of the features of existing back-end languages like Java and PHP were still missing, so a lot of patterns were re-invented, the language itself needed years to get to the 'safety' levels that Java already had and PHP was working towards, and proven and standardized technology like XML and the contractual guarantees it could give were discarded because it was heavy and JSON was better because it was human-read/writeable or something like that.
I feel like we lost a lot of time and effort by ditching XML. I mean documenting a REST/JSON API is still painful. While 20, 25 years ago you could already generate your data models and a parser for your XML payload. I still don't know what was wrong with XML. Yeah it was a bit heavier on the line than JSON, but that's a fixable problem - using compression, or use EXI (https://www.w3.org/TR/exi/) to turn it into a binary protocol. I don't know if EXI ever became a thing, but at the time I was quite exited about it knowing how much XML was passed around.
EDI never became a thing. One of the greatest selling points of HTML/XML/JSON is that they are human-readable. Even if gzip compressed, most tools will decompress automatically and show you the raw text.
So the tooling nor library support never came for EDI (i.e., Chrome, libxml, etc.)
Also, if you really wanna go full-throttle binary for speed, size, etc., you probably don't want something heavy like XML anyway.
I do think a lot of the original reasons why NodeJS was created has been lost, since at that time, non-blocking IO created some great performance gains. In many "modern" developer minds, it's now relegated to a dumb tool to spit out JSON or host a toolchain.
I guess you use what you are familiar with, but using react for doc site instead of using some off the shelf static site generator/cms with caching seems like wasted effort. More fun from dev point of view with react no doubt.
Great doc sites are dynamic in heaps of little ways. Stripe started the trend of showing you code snippets with api keys from your account to test with.
Frontend docs sites almost always include runnable examples, that you can play with inside the docs.
It's easier to integrate JS when the entire toolchain is all in JS. That's my main reason for using React Server Components over other static site generators. Also I like types via TypeScript.
You can use a static site generator like Gatsby or a variant of Nextjs (or even docosaurus), get MD(X) support and full features of react components when needed
I hear this all the time and I don't understand it. Bootstrapping a new project with <insert modern framework here> is so easy and fast, literally easier than bootstrapping a vanilla HTML project. What am I missing?
Edit: downvoters, I'm genuinely curious to hear your perspective.
It is statically generated. The reason to use React is so you have one language across the front-end rather than having some people using React on one site, and then people using Gatsby/Hugo for something else. Next.JS can do the same thing as Gatsby/Hugo but has more features and is in React.
But you don't even need to know what language your tool is written in if all you want is a static documentation site.
This is a problem a lot of people have; they think in technology instead of actual problem solving. Just look at how many projects have been posted on here with a title like "$solved_problem... in Rust!" as if Rust makes everything better forever.
It's marketing bullshit. It's self-gratification. It's using a technology for technology's sake, not for solving a problem. And it's costing the industry billions in sunk cost, dead ends, overcomplicated and unmaintainable software. Because one guy felt strongly about a language or technology.
> But you don't even need to know what language your tool is written in if all you want is a static documentation site.
Not if you want interactivity in certain parts of the doc site, such as what Stripe does with API keys. It's simply easier to add JS if the entire toolchain is JS.
Then what is an actually good example in your analogy? I don't see how using a static site generator is anything like smashing your fingers, seems like a common enough solution to me.
I'm old enough to remember when servers rendered everything and you used CSS and Javascript to enhance the pages after they were rendered. The web is in such a dark and overengineered place. It's almost unbelievable. It's why my approach to building apps is server-rendered first and then enhanced after the fact.
I agree for the most part. Collapsable dropdowns and jQuery drag-and-drop are nice-to-haves, but I also clearly remember the hellscape of state management in js/jQuery and I'm not to keen on going back to that.
To this day I don't understand people saying this. Can you describe a project or instance where it was tough? I never had any issues even in complicated projects with thousands of lines of JS.
Developers didn't understand event delegation, so entire codebases were filled with $.live, on and off events. If you componentized behaviors with jQuery it wasn't all that bad, although I'll admit it could get somewhat gnarly.
The problem, from what I saw was nested forms and trying to hold state on the client when the server should have been asked for the state. This lead to template duplication and trying to hold too much state on the client.
I jest; our first geocities page was just HTML with maybe a visitor counter, marquee and whatnot.
Our first PHP application / project in school actually didn't use JS yet, it used frames for a static menu and header and just straight form submission to get data to the back-end. Those were the days.
But when I did my first college level internship (1 year of internships is part of college education over here), it was Java back-end, JSX templates for the presentation part, and it was enriched with PrototypeJS for things like dialogs and an animated accordeon (back when animation was still "update the height of this element a couple times a second").
My first job involved using a lot of JS to still enhance a page; add to cart, image carousels, that kinda thing. jQuery era.
And my next job involved building a user interface for customer support staff to look into SAP or something like that, poorly built in BackboneJS.
The next assignment was once again using BackboneJS to rebuild the investment banking front-end for customers. That was - as with most applications I've built btw - a great use case for single-page applications (as they were called then). No SEO needed, fast enough to render purely front-end, API heavy (that was also the time when people realized you could build one API for both web and mobile), etc.
You guys used PHP? I started out with include directives with Apache, *.shtml files, and cgi-bin. SEO didn't even exist yet. You were either in the Yahoo! registry or you weren't. You just put your website URL at the bottom of the printed glossy brochures at the trade shows. "Mobile" wasn't a thing. Almost no one had any kind of cell phone. Pagers were still common. PalmPilots were brand spankin' new, a few hundred dollars (not including the 14.4kbps modem), and did not have web browsers.
(I'm not gonna claim things were better back then.)
As a different perspective, I'm also old enough to remember when CSS and Javascript were invented, and I've been making websites since that time.
IMO web dev has never seen better tooling than today, and user experience has improved tremendously over the years.
What we used to call AJAX has grown from a neat side toy to a basic part of everyday life in the form of client components and SPAs. The server is still as powerful as ever if you want it to be. But having such awesome client-side power is nice for interactive apps like dashboards, maps, games, forums, office apps, online IDEs, etc. It enabled the wholesale migration of everyday apps from bespoke desktop apps for each OS to a universal platform across all laptops and desktops.
All that power of course required more complexity. It's very different trying to write a blog or landing page in HTML/CSS vs trying to write a whole web app. Angular and React were invented to help develop apps that were several times more complex than their precesssors, at a time when JS runtimes (and the language itself) were still really primitive compared to the server side languages of the time.
Yeah, there was a really painful period there in the late 2010s where different JS frameworks each solved a tiny part of the problem. These days it's less of an issue. Next won, became the default, and deservedly so. It's really good, and has an appropriate level of abstraction for mid complexity apps, and allows a good mix of server-side rendering and client-side pages. Adding React Server Components makes that division a cleaner first class citizen.
That only makes sense at a certain complexity though. If you don't need it, don't use it. If you're making a largely static blog or documentation site, there are simpler architectures. You can still use HTML and sprinkle in a few lines of JS as needed. You can still use WordPress or Wix for most small business needs.
But if you're building more complex apps, god, React is an absolute dream compared to trying to round-trip every minor interaction to the server for recomputing the UI and sending over an entire HTML page every time, losing context and page position and half filled forms and whatever. It also encouraged the use of form data as state, and work was often lost on an accidental back button or the frequent server crashes before the advent of trivial cloud scaling.
IMO it's only overengineered when misapplied. Some of these tools are really useful, even essential, in the proper use cases. Maybe the sad part is that we overteach them and encourage their use even when they're not necessary (or perhaps counterproductive). Right tool for the job and all that.
Edit: not really pitching React over Vue or Svelte or HTMX or whatever, just that client-side complexity has its uses. Pros and cons, not strictly better or worse.
Well, React certainly has succeeded in increasing the client-side complexity, that's for sure. They seem to be making good inroads on increasing server-side complexity as well. Kudos to their contributions to excess CO2 emissions!
I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done.
> I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done.
Not my experience at all, and I've been working with React for years. I've seen companies successfully transition to functional components from class components, all while maintaining years-long functionality. Just because you dislike React doesn't mean it's not successful.
I never said it wasn't successful; I said it had successfully increased complexity.
I am glad you are an experienced React developer. React needs more of you, because the vast majority aren't.
That said, I have little doubt your and your team's experience could implement with most other frameworks as well—frameworks with a shallower learning curve, just as much power, greater performance before reaching for useMemo(…) equivalents, and far far less boilerplate code.
True, it does take more experience, but there are footguns in any language. Personally, having used Knockout, I see that signals are not the future, because I guarantee in 5 years, just as with Knockout and RxJS, there will be articles out on how signals create a spaghetti mess of code. So I'd rather take React verbosity if only because I know where the alternatives lead.
Now if there were a performant version of the core React philosophy like Preact is (or React with their upcoming Forget compiler) I'll gladly take it, but it seems that frontend libraries these days are trending in the wrong direction.
Well, I've yet to see any web project of that scale survive more than 2 years. What do you think would be a better stack with similar frontend interactivity?
I have Aurelia 1 apps that have been in production since 2015. They don't need to be really touched. But, when they do, they're really easy to modify. I am currently using Aurelia 2 and will have similar scalable apps that will be in production for years to come too.
I have seen Angular projects last pretty long avoiding code entropy. Angular is opinionated, rigid, and verbose, but goddamn if that structure and predictability don't pay off in the long term.
I'd love to investigate that, honestly. I loved Angular v1 (Angular.js now, I think?) and even that was way cleaner and more opinionated than React.
I haven't tried modern Angular in a while. But Next.js reminds me of a lot of the things I loved about early Angular and disliked about raw React (which always was more of a UI lib than a proper framework). Have you tried comparing them in particular?
My most recent use of Angular on a project is using v13 at the moment. I've been doing more infrastructure work lately, and Angular's build times—and bundle sizes—have been a persistent sore spot for me. I keep eyeing v16 jealously since it uses signals, builds A LOT faster, and removes some more boilerplate code in components, and the output assets are pleasantly smaller.
I haven't tried Next.js myself though a coworker was playing with it recently. The amount of components available for React, especially the for-pay libraries, can really decrease time to release. But it's still React. Builds a little slower than Angular 16 at this point, but it's fairly close. You still need to keep a firm hand on the codebase when working on a team to prevent code enmuddification, though less so than plain React. React's (what I consider) extreme amounts of boilerplate for doing anything of consequence is still there though. I also personally prefer Angular's service injection patterns over Reacts explicit imports everywhere.
I'd give them both up in a heartbeat for SvelteKit if I could make a business case for either rewrites or new projects. As it stands, Angular is really good enough and fights code entropy well enough that there isn't a business case there yet.
Why would server side rendering send the entire HTML page on every time? Or lose context or page position?
All those have been smoothly handled by pure server side frameworks such as wicket or tapestry for over a decade.
What do you mean? Maybe I'm misunderstanding something, but Wicket itself says it uses Ajax components for client updates.
As far as I know, it's not possible to do client-side rerendering without Javascript.
Many frameworks these days do a hybrid approach of server and client-side rendering, sometimes with rehydration, sometimes not. But my understanding is that they all require some level of Javascript to redraw UIs on the client.
If I'm misunderstanding (or just plain wrong?), could you please elaborate?
I get the impression that React is trying hard to catch up with the more modern, easier, faster and cheaper alternatives. But instead of fixing the root problems (rerendering and often required memoization, leaky abstractions) and make React easier, it becomes more complex.
If the end result was great, I would understand all the effort. But it isn't. React is even slower in real world than the benchmarks show. Next is even worth. I've seen recently many dog slow websites built with Next.
Really, I don't get. If the React team wants to improve React they should fix the core.
The ecosystem has too many dependencies that break at this point. Consider that Target.com, Walmart.com, Microsoft Teams, and untold masses of sites are React.
The huge component ecosystem.
Entire companies built around it.
The core concept is broken§, but fixing it means possibly breaking everything else. If you're going to break everything, might as well use something else.
All we can do is truck along at this point; stuck with React because of the mass of the dependencies.
§ React is the only library/framework that is opt-out of re-render while Vue, Solid, Preact, Svelte are all opt-in. This is one of the core reasons it's hard to do right and prone to a specific class of bugs that rarely -- if ever -- show up in other frameworks as you constantly have to be aware of opting out, even in what seems like normal JavaScript.
The `<Person />` component will redraw on each `increment`. Nothing changed. Why would it redraw? Because when the `App` component redraws, the `einstein` variable points to a new reference. React sees this as a change and redraws both `App` and `Person`. What looks like normal JavaScript here is not. To prevent this redraw, you have to opt out like this:
Or know to move the reference outside of the `App` like this:
const einstein = { firstName: "Albert", lastName: "Einstein" };
function App (props) {
...
}
Which is fine in this case because there are no dependencies on the component tree. This is the most common mistake I see in React that leads to bugs. It's not just objects, but also functions.
Why? Because on increment, the `logConsole` is a reference to a new function. So the `Logger` redraws as well. So here, you need to opt out once again by using `useCallback` or moving the function out of the component tree (fine in this case since there are no dependencies). The thing is that it looks like normal JavaScript but the React render cycle is the unseen; you have to be aware of moving things "out of the way" and "bringing them back" via a hook.
React's render cycle re-evaluates entire component sub-trees for changes and if your component doesn't explicitly opt-out by preserving referential equality (`useState`, `useCallback`, `useMemo`, etc.), you'll trigger a redraw downstream. These hooks effectively move the references out of the component tree and pull them back in when the tree re-renders and thus preserve referential equality.
So what teams might do is after experiencing this one time chasing down a bug is wrap every single declaration in a hook to reduce the mental burden. This then creates other issues like performance and memory.
Vue, for example, is the opposite because it has fine-grained reactivity. Nothing redraws until you opt in by using the Vue reactivity primitives.
After all this time, React's sheer tonnage of boilerplate still astonishes me. That abstraction leaks like useMemo(…) even need to exist in the first place…
Folks want to solve their own problems, but they keep getting saddled with React's as well.
Evan You (creator of Vue) had a great quote on this:
> The pain and suffering of hooks all roots from the mismatch between a dogmatic belief in the superiority of immutability and the harsh reality of the host language that is JavaScript (Feb 25, 2023)
This fundamental misalignment with React and JavaScript is the billion dollar mistake.
Nah, I still think React made the right choice. I used to use functional languages so coming to the JS world and seeing that no lessons from that world were learned was disheartening. React, where UI = f(state), is an amazing model compared to the imperative jQuery model of before.
Sure it does, it is good because it's functional. I could similarly write a convoluted yet highly short Perl expression, less code is not always better.
I tried Solid. Signals are not new, I've used Knockout before and it turns into a spaghetti mess after a few years. I guess people today simply aren't old enough or experienced enough to know what eventually happens with fine grained reactivity.
That page doesn't really answer why it can solve the issues of Knockout better. Eventually the same problems will arise, of spaghetti code among things reacting to other things reacting to yet more things.
Well yeah, it's the difference between understanding structural equality and referential equality. I always got the sense that people who can't figure out why things rerender when simply never took any classes in college on the difference (which is likely true since many bootcamp devs don't take such classes, and the vast majority of them learn the MERN stack).
The reason I moved away from Vue is precisely due to the spaghetti nature of fine-grained reactivity. It's like people learned nothing from the reactive stream days during Knockout JS. In a big enough app, the state simply becomes unwieldy and I am always grateful for the unidirectional dataflow and explicit setting of data in React.
UI = f(state), and that's how it should be. useState and other hooks seek to keep state around since at the end of the day we need to make components that perform functionality, and it really reminds me of monads in functional programming. Coming from such FP languages, React was and still is a great paradigm.
You bet. But if you grok that simple example, you can see why teams that switch to Svelte, Solid, Preact, or Vue feel "refreshed". This mental burden of trying to figure out what has to be put where just...goes away. The React model tries to bend JavaScript to conform to it's render cycle rather than designing to JavaScript's unique object-functional strengths.
Thanks. A while ago I sensed the churn dangerzone around React and I refused to get on any React projects. I feel lucky that I had that option. I did some Angular projects (i think it was version 8-9) and to me it seemed okay at the time. The project evolved nicely and structurally it organized itself quite well. But there is a ton of boiler plate there as well and I’d avoid Angular in the future.
Im doing mostly back-end work these days to keep my sanity.
I admire parts of Angular's vision and think there are patterns where it shines, but it's never quite felt like they actually hit 2.0 to me. I haven't worked with it in a few versions, but I think it's just a different set of complexities.
There's always some big or missing thing right around the corner... reworking Material components for years, reworking internationalization, improvements to reactive forms, zoneless Angular, single file components, etc. And, for as many bugs as they fight down, it's always felt like there were several obvious frustrations waiting to be fixed. It's all just left me with an impression that the team bit off more than they could chew in creating such a holistic solution and can't quite get to something solid, hence the need to shed things like Protractor.
Hopefully the cumulative effort to improve gets them somewhere and helps get Angular into a more complete and compelling place for folks.
If Angular wasnt based on RXJS, I would agree with you that the defined structure of Angular makes it nice and predictable. RXJS pipe hell is a hell I wouldnt want to send my worst enemies to.
Having a templating system in ‘that environment’ is worth its weight in gold IMO. I’ve been switching between Svelte and Django templates a lot lately, and Svelte just…knowing about the DOM, makes the experience so much nicer. I haven’t come across a non-JS template system that does this. And yes, I was there for PHP and jQuery and whatever.
A combination of the devil you know and Stockholm Syndrome.
It was better in many ways than the dominant techniques in 2013, sure, but that's not a terribly high bar, especially when observing the React model a decade later.
React served well enough for quick starts. It proved… challenging… for ongoing maintenance and quality control in long-lived projects.
Because it's nicer than most other templating systems, and when you want to add interactivity, it's nice to have everything in one language and paradigm. Plus, static typing support.
Wow... well, I'm not here to defend RSC or React as the best solution ever, but some of the objections here are half-baked. React/RSC is not technically equivalent in benefit to having a server return html/css with a smattering of javascript. It's still one app, with more intelligent handling of the client/server boundary (compared to SSR/hydration). I'm all for reading more informed objections about how React may have designed themselves into a corner and what the exit path is, but going back to php isn't it.
HN is not the best place for informed front-end opinions these days. React is not even that hard of a thing to learn (hence why even non-devs pick up the basics in a bootcamp in a few weeks?). JSX is objectively superior to the templating systems of Django, PHP, and Rails. I'm sure half the half-baked objections aren't even benchmarking their projects with things like Lighthouse...
I've tried Nextjs's app router, and server/client components, and there are more footguns and gotchas than you can shake a stick at. Maybe it'll get smoothed out over time, but right now it is downright HARD to keep the mental model of your app when server and client code is constantly being intermingled, imported, and exported back and forth to each other.
I'm advising a NextJS team now and acting as a liaison to a system they're integrating with. Even the devs in the NextJS code every day get confused about what's running on the server and what's running on the client and the consequences of both.
I can see the attractiveness to a setup like this. Back when I was much more involved in actually typing out code it was always a pain to switch mentally from backend side coding to front-end side coding. On the other hand, it made it easier to reason about security. Front-end was the wild west and on the backend you didn't trust anything coming in.
Another thing, i understand the supposed advantage of having one language for both backend and frontend but i don't recall that ever being a real issue with me or the teams i worked with. Everyone seemed able to shift from Javascript (and associated Javascript frameworks) to the backend language ( Java and C# in my case) without any issues.
People don't realize that many of the dev tools they use they are using more because of the large marketing reach of those dev tools than any objective decision to use the tool.
Entire companies have been built around the premise of good developer marketing, and if you're faang, you simply get to impose whatever developer trends you want to see in the market.
I'll never forget how wildly popular Stripe became overnight because of how easy their SDK's were - people were happy to give them a higher % of each transaction (all the stripe competitors at the time were cheaper -- this isn't true anymore, but was at the time). It always blew my mind that people were so willing to give up a % of each transaction to save an extra couple days of development.
Developers in general are notoriously susceptible to marketing trends and if you're building a dev tool that you want to gain traction you absolutely have to play that game.
I am not saying HTMX is terrible or anything. What you've built is cool and I've built something with it. The point I was making wasn't made very well. What I meant was good options are often left out of the conversation because of React, Vue and for a while there, Svelte. There are a lot of great libraries and frameworks that nobody talks about, HTMX included. I just feel like HTMX isn't being hyped because it's good, but because of the memes/marketing aspect. I think it's a disservice to your work, which deserves to be assessed on its merits. It's a sad indictment on front-end that building something good is no longer good enough to get recognition.
but the reality is that marketing is what gets people to that content. I tried for years to convince people on pure technical merit alone, and only made halting progress.
i also got very lucky that a few things all came together at once:
* the primeagen & fireship_dev both covered htmx
* we released our book
* the twitter algorithm changed to boost funny stuff/memes
A little over 10 years ago we were saying this about jQuery. React definitely solves problems that jQuery just couldn't solve well. I know that there are issues in react we still need to address, so I know it will be a matter of time before some new way is developed that will supplant react and we will talk of react then as we talk of jQuery today.
Embedded? I would have used the term "infectious".
Its complexity and ecosystem will be its Achilles Heel. There are no small number of examples of folks rewriting their React apps in weeks or even a weekend in something like Svelte. SolidJS is "close enough" in code patterns that folks will be very tempted to jump ship. Vue now has a JSX option.
But here's the kicker: frameworks like Svelte don't need wrappers around vanilla JS libraries like React has. It can use them, but it doesn't need them like React does due React's VDOM and execution model.
In 2012, jQuery and jQuery plug-ins were everywhere and necessary. YUI was dead/dying. Mootools and PrototypeJS were already quite dead. That inertia couldn't stop React despite the rewrites.
Because let's face it. We love rewriting front ends, and every rewrite erases the past. No one's gonna choose a rewrite in React if they have any notion of the alternatives.
On the frontend, Java was dropped fairly early on. Long before the iPhone effectively killed plugins. The backend has always been less prone to singular dominant monocultures, had far more stickiness, and greater diversity of implementation than frontend.
There are 1980s mainframes still running COBOL, especially in older, more conservative industries like banking. Those same banks have cycled their public web front ends literally dozens of times since the mid 1990s.
PHP still does A LOT of heavy lifting even if the front ends have bounced between scriptless HTML forms, PrototypeJS, Mootools, YUI, jQuery, Angular, React, etc.
It's not about programming language on the front end (unless that language is JavaScript, but that's a whole other conversation). It's the implementation of layers on top of JavaScript and the browser APIs, and those will remain rapidly shifting sand for quite some time.
Remember, jQuery had about a decade of prominence in the web dev community before the component-based frameworks were released and fairly abruptly drowned it out. That said, jQuery is still far and away the most popular JS library deployed today.
React isn't going away, but something else will always eventually take center stage and suck all the oxygen out of the room during new web dev planning.
Java is still widely used for Android, not to mention its usage in enterprise backends. I agree with you though, React will stick around for quite a while, just like jQuery.
Parts of this thread make me feel like I'm on crazy pills. We are currently doing SSR everywhere and it absolutely works in all the weird bleeding edge use cases that are traditionally parroted as reasons for outsourcing your ownership over technology. This isn't some historical, nostalgic experience for us. It is life today.
The propaganda being fed into this industry is impossible to navigate in 2023. The best I can do is to find other engineers who still see things my way and team up with them. I am so grateful to have a few of these on my team right now.
To be clear - Client-side rendering has its place. A perfect example of this is WebGL. But, this is extremely niche when you consider the total space of all business. PHP-style development is still untouchable for 99% of line-of-business web applications. String interpolation on the server was always the answer. Will continue to be the answer until some dystopian organization(s) decide to make it impossible to do things this way.
My thinking as well. Reflects poorly on the company. I'm not in the market for whatever they're doing but if I was my impression is they have a bunch of hipsters drinking coffee and reimplementing stuff no one asked for.
More like "hey we just spent 8 months of investor money on a rewrite and this works much worse than the previous solution. But hey, they're throwing this out and the new thing is ReactWebLogic, let's do a new rewrite!"
This might be fair if this was a rewrite in a vacuum (or took anywhere close to 8 months) but it wasn't. We were also undergoing a large design refresh for the site, which was going to require a ton of work on the existing site anyway. Using the opportunity to also update to the newest version of the technology we were using wasn't nothing, but I'd argue it was also probably a pretty small marginal increase.
It’s a fair question. I think it’s a question I was hoping to address in this article, especially with the incremental migration pattern. If you already have a Next.js site, it’s honestly not too bad. If you’re not on Next.js, well, that’s a big migration either way. But considering server components during that migration might not be unreasonable — you’re writing React components either way, albeit RSC is a more complex mental model.
More specifically though: The docs migration took me about a month-and-change of work. Some of that was moving all of our styling to Tailwind. Some of it was (optional) RSC code gymnastics that I mentioned in the advanced patterns section, to see how many kB we could leave on the server. And much of it was the information architecture changes I talked about in that earlier blog post.
Meanwhile, marketing took us three months, but that number is complicated too, since we were rebranding the site, touching every component and page anyways. Most paths had like, 2 minutes of direct RSC work. Moving the calls to the data layer from outside our components to inside.
IMO not bad. In both cases, we had to work on the whole site, anyways. Might as well creep the scope a bit and move to the new React thing, since it looks like that’s where the puck is going.
I am pretty sure 99% of the development time is no longer spent on solving problems and implementing features, but on creating unnecessary complex systems, deploying and maintaining them in an auto-scalable cloud, when a single $5 VPS would be performant enough, if all that complexity wasn't there. We should spend more time in writing efficient, simple code with fewer dependencies. We get so much natively nowadays that often choosing to add another framework/library adds more limitations than benefits.
I blame the devops industrial complex. When cloud providers came online and especially when "devops" became a thing then developers became the marketing target. Social media, the whole influencer concept, and all those manipulation tactics were turned loose on software developers. Look at the breadth and depth of services and tools on the market to produce a web application.
Another thing, this isn't the first instance of the pendulum swinging back. Providing what would normally be desktop apps through a browser reminds me of dumb terminals attached to an AS400.
The article makes a comparison with PHP. I recently worked on a Laravel Livewire project and learned that it could do everything I used to do in React, from PHP.
The argument is usually that you don't want a network round trip for interactivity. That's less true than it's usually presented, I think because most folks making that argument think the server is necessarily slow.
It is, but that's not the comparison. The question is how well you can react to a user action if you need a network round trip in the middle. The user's already got the 2MB of JS loaded in their browser.
My stance is usually that as long as you can get a response to the user (which can be a DOM fragment, a JS snippet, whatever, doesn't matter) within 200ms, you don't need client-side rendering. And if you haven't yet got under 200ms, you shouldn't be spending time complicating your application to be distributed between the client and the server until that's fixed.
> The question is how well you can react to a user action if you need a network round trip in the middle
I do think this is the question, but the solution is not an SPA, but instant interaction feedback and no content jumping around. If you solve that, a 1-2s response from the server will seem instant, whereas with a bad implementation, you can have everything on the client-side and make that 0ms interaction look more sluggish than the one that goes to the server.
Think of a chat application, if you send a message and press send, it doesn't matter the request takes two seconds, if:
* The message is immediately shown in the chatbox
* There is direct feedback on the status of the message (sent/received/read)
* You can continue interacting with the application while the message is being sent (non-blocking)
You don't have to send all the data/messages before (server-rendered), just some logic to what happens when an action is taken.
Great article for catching up on the next cool thing and what common hurdles to expect. However, the next question that needs answering is how the migration to RSC has affected the user experience and their ROI. Without any such data or analysis, how would I ever reasonably approach a product manager and ask them to please give our team weeks of work just to hop on this new technology?
I wonder about the code with the heading “A Server Component with data fetching”.
It shows a HTTP request made to the company’s publicly visible API endpoint. But this request is being made from their own server (the one that is generating the HTML + JS from these React components).
Is the idea really that your front-end generator calls client APIs rather than internal ones (e.g. just making a database request)? That seems kind of wasteful, and also potentially confusing from a API design standpoint.
What makes you think that server-side JS could not call a private API with authentication?
If it's a "front-end generator", we are talking about gerating static HTML, CSS, JS though. This means all "secrets" have to be embedded in client code, or the API calls have to be made at build time, with the static result embedded into the output.
So I don't see your point really.
If your point is talking to a database "directly", using only a database client and no remote intermediary, you can do this in Node as well.
And presumably also in RSCs, since it's already possible in SSR.
It's a limiting, but saner approach for any larger app/company.
It's the same logic why in OOP you have private members/methods. As owner/maintainer of some component you want keep stable public api and be able to iterate on the internals.
Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future.
> Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future.
Surely you'd just want to be calling the internal API that the other endpoint is using behind the HTTP endpoint? If you're in the same process (big if, but nothing to suggest they aren't), there's not a lot of sense serialising out to a socket and back again rather than making a function call.
Sure, calling internal API is sensible. I am not saying it needs to be public API. But you probably can't avoid some serialization (be it REST, GQL, GRPC), the service that owns the data can be different than the one serving the html.
I am not saying everybody needs to do microservices but my experience with monolith is bad. You want at least "some" services and the html-serving service shouldn't usually own the data. User data belongs to user service, report/analytics data to analytics service etc.
Just from the security point of view, the stuff facing internet should have minimum rights to read/write anything. Definitely not direct function-calling or db access.
There’s a world of difference between an internal API and directly fetching from a database.
What concerns me here is mixing up internal APIs with client APIs that are callable from the outside. It just feels weird not to have this distinction when generating pages on the server.
I see what you're saying and in a broader sense that's true.
More specifically though — in the world of web development — some ideas are actually [as good as] original. When CSR/SPA became well established as an approach in web development, there wasn't a time before it when that approach had been common.
The approach to web development described in the article however is essentially the same approach that web developers commonly used 10-15 years ago.
n.b. I'm aware the CSR/SPA approach is more like 20 years old, but I'm making a judgement call on how common common is. Furthermore, when the CSR/SPA approach was first explored in ~2002, what old idea was it a new take on? Flash? If so, what begets Flash? There was a time before the Internet, and it wasn't all that long ago.
This used to be true, but there are new libraries like PandaCSS that bring CSS-in-build-time-JS, thus bringing Tailwind-like performance and React Server Components compatibility. https://panda-css.com/
> Slow database call? No need to wait; we’ll just send that slow component to the client when it’s ready. Your users can enjoy the rest of the site in the meantime
Seems like he buried the leed, or presumed everyone already knows:
RSCs are ideal when you're pulling data from multiple APIs, some of which may be slower than others.
That said, if the slower one or two are at the top of the page - or at an anchor that might be directly linked to then the UX doesn't really improve, does it?
I'm confused how / why their docs would require React-iviness. Sure perhaps there's a video here or there but is that grounds for tearing down the docs just to use RSCs?
These tools are great, *when they are the right tool for the job*, else we just seem to be reliving an unhealthy infatuation with shiny new object for the sake of my shiny new object is shinier than yours.
Yet performance is abysmal. I clicked on “API reference” and nothing happened for a second. Then the submenu opened in the sidebar. Another second later the content view updated. There is no indication of anything loading, there are no network requests to await. Incredibly, it’s dog slow on an M1 Mac.
If the viewport is 800 px or narrower, click on the menu icon (horizontal bars, top right), then click on a sidebar link. Do that a few times, you’ll notice it’s incredibly slow to react. Same with resizing the viewport, very sluggish.
There's something to be said for optimistic routing, server or client side. It seems like they're using suspense to wait for the page to be rendered before swapping the route. It's a noticeable breach of the standard pattern of instant navigation, and then wait for content to appear.
I really wish it was possible for users browsers to opt-out of stuff like this. I don’t want some unhinged developer deciding they’d like to arbitrarily delay things like this, just render the page and stop making things worse.
I agree re: scroll hijacking and with a preference for minimal styling, while noting that the styling on docs.mux.com is pretty minimal compared to other docs sites.
What I'm wondering is what the anti-React folks are recommending for generating HTML and/or DOM itself in the docs use case, since most of it needs to be dynamically generated from OpenAPI definitions.
Going by the response headers, it seems that most if not all of the HTML served by docs.mux.com consists of cacheable static files. As the OP article mentions, using React for static generation is one of the big use cases for RSC and Next.
Which templating technology would you recommend for the use case instead? Keep in mind that generating HTML from OpenAPI specs can become complex and will require plenty of maps, filters, recursion and indexing into the data in the course of transforming it into HTML.
> Are there a lot of server side template languages that can’t do this?
Did I say there weren't a lot of template languages that can do this?
A dead give-away that this subject isn't as "straight-forward" as you think is that, at one sentence in, you've already misidentified the conversation taking place. This isn't about can vs can't, but about the right tool for the job.
What template language would you personally recommend for this project?
You can generate a swagger-ui doc page from an open api yaml spec by just mounting the file in their swaggerapi/swagger-ui docker container.
Same with Redocly.
Granted the pages probably wont look as good as what they have here or be integrated in their larger docs, but yea its possible.
To me, that is a separate level of decision. Sure, you could avoid the whole problem of building a docs generator by using an off-the-shelf docs generator, and letting the Redoc and Swagger dev teams deal with all the development complexity.
But if you are going to build your own docs generator, React and Next with RSC aren't a bad choice. Web development just isn't as simplistic as people on HN seem to think it is.
I agreed with most of your comment but this almost triggered me:
> React and Next with RSC aren't a bad choice. Web development just isn't as simplistic as people on HN seem to think it is.
Yes it fucking is. I've been doing it for 15+ years and most of the complexity added since about 10 years ago is not required. Many times they're actually regressions.
The web is complex because we made it so.
This is a perfect example where they could write their own docs generator with MUCH less complexity. You read a damn json/yaml file and make HTML out of it. Style it with CSS and you're finished. It's as maintainable as it gets.
Now let's look at running `yarn install` in this project a year from now and see how easy it's going to be to maintain it.
Odds are NextJS will be 5 versions behind and with 500 vulnerabilities found in the dependency graph.
I think that's a really motherfucking bad piece of advice. Isn't there a version of that which is actually made by someone with some kind of ideas about readability and design?
These are all satire. The point is to KISS. I doubt doco sites need JS except for say running code snippets type stuff. But not for the UI itself. And a big long page with a default scrollbar cannot be beat for accessibility and searchability.
I haven't used Blazor, but I shudder at the thought of using Jinja to generate the HTML here. Rendering documents from OpenAPI spec benefits from being able to easily transform data, map, filter and so on - especially if you are displaying the JSON schema for request and response bodies (which docs.mux.com appears to be doing).
The experience of doing these transformations in template languages is pretty sub par.
I use Phoenix LiveView and I’m really big on frontend. I also do a lot of backend, though, so I’m one of those “full stack” generalists that no one likes anymore.
Am I the only one that believes classic Turbolinks (pre-Turbo) is the ideal solution to SSR? It works out of the box with JS disabled. No extra logic is needed on the server side (as is needed with HTMX). You can still perform partial updates HTMX style if you want (data-remote="true", and wrap response with a script/dom insert).
I am using it in all of my products (non-Rails) and it has been so great.
I'm really sad that tree-specific context for server components seems to be an afterthought. As the Twitter thread suggests, if you have something that can be used across all the server components for an entire request, you can use the cache functionality or rely on Next's URL parameters. But if you've relied on Context as a way to let deeply nested components access some kind of business logic that's specific to only a part of a rendered page, and if you want/need those components to be server components, you'll need to switch to explicitly drilling the props through.
For Context support, I think the reason it's not supported is because Server and Client components have different lifetime. In theory they could add something like Server Context, that's accessible only to Server components.
For CSS-in-JS, those are all 3rd party libraries, so they need to adapt on their side. For example, `styled-components` uses Context heavily, so they need to re-think their approach. For `css-modules` adapting to Server components looks doable, but requires substantial amount of work.
PandaCSS and Vanilla Extract are subsuming styled-components, precisely because that is runtime CSS while the former two are compile time based and so work for the server.
If you’re rendering multiple pages concurrently on the server, it’s nice to be able to know, for example, the current user without having to pass it down as a prop through the whole tree.
I feel the history explanation isn't that great, making it look like the modern web development simply reinvented PHP. There are nuances to every technology that make developers choose it over another. Still looking for a good blog post on the evolution of web development since PHP+jQuery.
Slight newbie take here. I've just developed a personal webapp with python/flask/htmlx/tailwind. Its for my RPG group and its an interactive GUMSHOE character sheet with discord integrations through webhooks.
I used htmlx/hyperscript so I wouldnt have to get into JS - I find it a complete headache. Getting the balance between server-side and client side processing so its not a huge pain in my ass to debug also took a little bit of experimentation. But in the end I think I spend more time on styling the webpage with tailwind then on the htmlx/hyperscript which is a breeze to learn from scratch.
Have orchestrated production cloud setups for big tech companies and startups of all kinds of needs, in a week.
It’s been 3 days and I cannot get a value returned from a NextJS route to a React component.
All the blog examples look nothing like the project layout the tools generated for me.
Frontend toolkits are atrocious to work with. Reminds me of Chef/Puppet, solving hallucinated problems to soak up VC funding.
I’ll give it another day or two, because it could be me. But Apache web server, the Rube Goldberg of web software, seems as quaint to use as MS Paint relative to Reacts ecosystem.
https://chillin.online, build with next.js too. I have to say there are some annoying problems with next.js. You should have some tricks to handle them.
htmx + django + tailwind fixes 99% of problems on the web, and you get to leave npm behind
read the docs / a basic markdown to html converter would’ve been sufficient for static docs. Worked at a company the completely over engineered their docs. Created some job security for the people that knew how the monster worked, but added zero value for users. Never again
"This was called client-side rendering (CSR) or single-page applications (SPA) and was widely considered a bad move."
Why was it considered a bad move to go SPA? I generally disagree with this statement. But I feel like whenever this conversation comes up we're talking different applications altogether. A SPA is fine for a back office application. What it's not necessarily good for is a splash page or marketing page where each page truly operates independently. But in the case of an app that people use frequently, the client side code all gets cached locally anyways, and SSR doesn't buy you anything for that use case. SSR is great for getting a fast time to render on the very first hit to a page. But if you're making a real, rich app, that people will use daily client side JS is not bad at all.
I worked on Trello for a while, it was a single page app with a Node.js API. We served millions of users with it, and people generally loved the UX of our app. But it was a true web app, and not a website. Interactivity was always part of the user experience, and many of the behaviors would be impossible in a pure SSR app.
Most judgements I've read online of CSR vs SSR miss that distinction of website and web-based application.
Clearly if your website essentially just retrieves some data and displays it to the user, you can use SSR. It seems most frontend discussion - and even most of the frontend dev velocity - focuses on this context.
Other common advice is "you don't need global state mgmt - use component state and a query library with good caching". Nigh impossible to retain performance and high interactivity without redux/mobx/etc.
It's very empowering to be able to create sophisticated web apps that run on any device with a web browser! SPA is a very valuable pattern.
- API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wait for things. The page just doesn't render until it has the data it needs.
- You don't send the user code they don't need yet. If someone is viewing a page that doesn't have a widget, but you send them the code for the widget because you've bundled everything the site needs into one JS file, you've wasted the users time and bandwidth. SSR is a very easy way to solve that problem.
I'm of the opinion that SSR is a better alternative to a bad SPA, but marginally worse than a good SPA, so for most teams it's a good approach because building a good SPA is hard. If people want to use SSR and that results in me not seeing 4MB homepages any more that can only be considered a win.
The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable.
The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.
In practice, the SPA is so slow and the user's device is so much slower than the datacenter that the "something" you see is a useless splash screen, and the actual content takes longer to arrive than just doing it SSR.
Reddit is probably the most familiar example of this, because it actually has multiple implementations (old.reddit, i.reddit etc) that let you see the difference!
I am wary of gleaning anything on the matter from Reddit. Their engineering decisions don't fit either the convention nor the needs of most web applications.
As for whether the initial paint is of value, that comes down to product and implementation. Nothing is faster than offline-first or local cache, which SSR does not have a good narraative for.
"at least seeing something" leads to jira or teams where you open a thing and then its entries slowly pop in and shift as they get loaded. An illusion of a site being there that can't be used because you can neither focus on the text nor use any of the inputs as they shift beneath your eyes.
That'd be a poor implementation. CSR can generate immediately interactive forms that don't shift. JIRA and MS are absolutely subpar irregardless of this matter.
They work fine for everything that doesn't require immediate response on first load, and even the there are ways to address that - for instance special pages for entry points and/or loading indicators.
For general performance you can cache the modules using a service worker.
That's exactly what my team told me when we transitionned to an SPA. Turns out, splitting properly an SPA is complex and bundling is pretty annoying at the moment.
Why? I think most modern bundlers and spa routers supports code splitting out of the box by just using dynamic imports, aka:
`const myComponent = await import("/path/to/component")`
I don't understand your concern with it and why this is a problem.
I haven't personally noticed the vite/esbuild memory consumption, but I also run build only once at the end before deployment or generating the prod artifacts.
It wouldn't be an issue if other work tools were taking absolutely nothing yes but as it is now, 16GB of RAM with a JS oriented stack isn't enough anymore.
And getting more RAM is just delaying the problem anyways since it takes more RAM every week as the product evolves.
Yeah we all collectively had a look at it and there's not a lot of solutions available. The bundler needs to bundle everything at some point and you are going to pay the SPA tax.
That's why I personally don't recommend SPAs, it introduce a whole other class of issues on top of what you usually deal with. Google makes it work with Gmail and Youtube but it's Google, they can throw infinite engineers at any problem and could make those in pretty much anything.
I agree there is a complexity cost for bundlers. Whether to pay it is an equation that roughly aligns with how robust and interactive your client offering needs to be. Applications probably, websites probably not.
We're a web application and even with those, I'm not sure the bundling is worth it. Customers in some regions complain about the high payload, we made sure the chunks are split properly but with continuous deployment, there's a lot of cache invalidation anyways.
Doing database lookups on the server was the primary reason people STOPPED doing server side render and shifted to JS+API. Why do we now think that the way we used to do it was actually better?
Where do you propose database lookups get done in the JS+API world?
Surely they are getting done on the server that hosts the API? Unless you are using something like Firebase or SupaBase which can sort of enable client side database access (but not really, it’s still doing it on a server, just their server and running the call through RLS or similar)
You still need to do it, but now you additionally have a serialized data format in between client and server. Now you need to keep that format versioned and backwards compatible, otherwise users with cached clients will break.
We need to do that anyway, our customers call our application through our API. Building our web apps on top of the same ensures that they have the full functionality available, kind of eating our own dog food.
> - You don't send the user code they don't need yet. If someone is viewing a page that doesn't have a widget, but you send them the code for the widget because you've bundled everything the site needs into one JS file, you've wasted the users time and bandwidth. SSR is a very easy way to solve that problem.
Just saying: the generated HTML could be a lot larger than the Javascript generating it. Usually it won't be, but it's not a given that sending the HTML is less bandwidth.
> It also reduces the complexity of the page - devs don't need to build logic to wait for things. The page just doesn't render until it has the data it needs.
Devs don't need that anyways, since frameworks like Angular provide this ootb, may it be dynamic template renders (ngif) or as a prereq for finishing routinh
As you say it's very context dependent. Trello makes sense as an SPA because the user stares at the same page all day (the board view), for long stretches at a time, and often requires interaction like dragging cards around. For Google Maps the user spends some time finding the right location, and does a lot of panning. The HR solution my company uses… there the user goes to very distinct pages (time off, goal setting, etc.) and interacts with it by filling in forms. That probably shouldn't be an SPA (but is).
It's considered a bad move to use SPAs because product managers tend to err on writing an app when they should be writing a site; the reverse rarely happens these days.
I agree. I feel like in my decade or so of professional experience, server-side rendering has made sense a handful of times and client-side rendering has made sense a handful of times. As you're saying: each tool comes with its own strengths and weaknesses and you should really just aim to understand the use case for each so you know when to apply them, rather than look for some one-sentence dogma about which thing is the devil to recite back to yourself when presented with a choice.
That line was a fun, sassy one. And probably a bit too strong. I definitely meant to temper it with the next few sentences.
> Sure, it’s simple, which is worth a lot! … And for frequently changing, highly interactive pages like a dashboard, it’s probably enough
I spent years working on a medical dashboard SPA and we never once seriously talked about SSR. They totally have a time and a place for web apps. I agree with you and I’m glad you brought it up.
SPA required building out a separate back-end API, it had poor load times because everything had to be loaded at once (then you had all the complexity to find solutions within that paradigm with code-splitting), there was always this gap with the HTML part of the site, you had all the complexity with bundling, lots of reasons.
Trello is probably an example of an app that worked with SPA. But the other perspective of this is that people weren't sensible about using React, they tried to use it for everything, they got onto React because they could hire for a very discrete front-end role and then split back-end, very few companies did this sensibly. The big problem with React was really how people used it, and this seems to have guided the development efforts on the project.
Btw, the move to SSR is already having operational issues. I have noticed companies hiring now for "full-stack React" because they hired a lot of front-end specialists who don't know anything about Node and won't learn it...so I think the issues with hiring will continue.
That statement also stood out to me. I suppose the issue was that JS developers cargo cult and started creating everything as a SPA and bootcamps pumped out React developers who only knew how to make SPAs. This generation is now discovering server rendered html through React.
At the point of server components I sort of giggle to myself that we've come full circle and maybe I can come out of my SSR bomb shelter and enjoy life again
I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be.
I’m sure they’ll claim it’s different now because… hydration or something or another.
As a former PHP developer who spent a lot of time both working on server rendered pages and converting server rendered pages to be API/JS (render the core in HTML+JS and use APIs with two way data binding to update the UI), I can’t believe we’re going back that way, but with wildly more complicated patterns than we had before.
Yeah, I've witnessed the entire arc also as an ex-ex-ex PHP developer from the early 00s, and I literally recall the original justification for this whole exodus that lead to the creation of React and a slew of other things was "jquery bad".
I just wish we had skipped all the in-between stuff and just arrived at htmx back in 2011 instead of now. Maybe I'd still be doing frontend stuff and not burying my head as far into backend as humanly possible while I wait for a workflow that doesn't require a package.json and a 3 GB node_modules folder so I can make the same frontend widget I could make with 50 lines of js in 2007.
I started in 2010 with Java and JSP and initially thought the same thing. But after reading more about it, I see it as like foldable phones. We’re back to using foldable phones, but it’s totally different than before.
Also, I recall heavily using jQuery and Ajax to update parts of the page before Spa’s came along.
SSR is different I think because it can perform better, but given the state of most sites on the internet I think 2003 style rails is sufficient for most sites. And I haven’t met a JS-ey UI I have enjoyed using as much as a vanilla HTML one for most online stuff (drawing, games, 3D etc. excepted).
And turbolinks on modern rails apps literally feels like those fancy JS-ey UIs anyway in terms of responsiveness. Not to mention things like phoenix liveview..
Did you have a look at SvelteKit? It does that "hydration" magic, first page loads completely from server, then it can work like a SPA, only fetching required data.
It’s all JS, which we know from the frontend, all that "magic" is done by the framework in the background. You write it once, it works both ways automatically.
We already build 3 webapps using SvelteKit, still happy for the ease of use, or great "DX" as some call it.
> I also am baffled by the return to server side rendering as the new thing. It’s like people forgot that’s how it used to be.
People want that back, but they also like React, and their existing component libraries, and they want to generate the backend pages with React. It's not that strange.
And you can (I think) pretty seamlessly have part of the page rendered on the server, and parts still function on the client.
Is it because these devs can only do React and nothing else, so we will shoehorn everything into it?
I mean, more power to them, if they want to do it and have 10x the complexity and take 10x longer than learning and using normal, already available tools.
To clarify, I mean other server side tools that have been available a long time and had bugs ironed out. React Server stuff just came out recently, and still has a long way to go i guess.
How much experience do you have with RSC and Next.js?
I remember writing PHP and JSF back in the 90s and 00s, and the experience of both writing RSC and Next.js as well as using websites built with these technologies is simply not comparable.
No we didn't come full circle. I always wanted a server side rendered SPA where the server template is the same as the client template. With PHP/JSP you have to switch context to say jQuery for interactivity. With an SSR rendered React SPA you continue where you left as the page gets hydrated.
I think there is a difference this time round and it isn't just to do with where the pages are rendered. There's a yearning for simplicity. In days of yore, "simple" SSR (eg JSP, ASP, etc) came with a selection of "helpful" design patterns and frameworks (Struts, Stripe et al) that all added to the complexity, not reduced it.
Modern SSR implies just do simple rendering on the server and hook it up with simple tools like Htmx, Turbolinks, etc.
Keep the complexity accessible on the outside, like the Pompidou Centre.
Stupid question… why roll your own solution for a marketing site and doc site?
Why not use already battle-tested CMS solutions (opensource or paid) and focus your dev effort on your actual product, in this case a video platform product.
Maybe it's just the circles in which I've been active lately, but I feel like a lot of time and effort is spent these days practically just moving code around between implementations, without much practical change in user experience.
What drives this behaviour? I mean the question on a deeper level. An answer like "the technology hype cycle" just begs the question. Why does someone feel like they have to move business logic onto a particular framework (and then realise it's a mistake and move it again to a different framework that's similar to the one they started on?)
We are constantly bombarded with the idea that society is progressing - towards.. "something" - and change means "good", because "moving forward". Ergo, yesterday's things are inherently worse.
IMO I think that's at least part of the issue.
There's also the common notion that movement seems productive. If you are not moving, what are you doing? This effect happens on a lot of levels. Especially managers have to show they are moving needles. Any movement is better than no movement.
I think that one factor is that staying on old tech is a risky career move both for the individual and the business. At work we have an Angular (the old one) app and while many new devs pick up some React, they definitely don't play around with ancient Angular versions for fun. So now we're stuck with a pretty big app using tech no one is interested in anymore.
Partly due to frontend framework hype, I would say. If we take traditional backend web frameworks, like lets say Django, you could simply look for Django devs and would find plenty, even though it exists for a long time. Choosing a hyped JS framework is what is the risky move, because people jump ship quickly. There are design decisions in Angular for which I would never even consider Angular for development.
When angular.js came when you needed to do something highly interactive it's competitors used to be either amature hour hipster shit frameworks or hacking stuff using jquery.
The web browser is both a critical UI technology - it's the only working truly cross platform sandbox - and therefore a battlefield between potential monopolists that has stagnated like a WW1 field of trenches and wire.
Because only the tiniest, most incremental changes can be made to the browsers, and because there are fundamental native/universality conflicts all the time, making tiny improvements to UX requires huge behind the scenes troop movements. And then it's subjective, so maybe it just makes the UX worse in the end.
UI frameworks seem to be surprisingly hard conceptually. Neither Microsoft nor Apple have really proven that they can do better when on a field entirely under their control.
Not to mention business model considerations, such as the worsening of Reddit.
Not sure if the OP is here but on Firefox clicking the "API reference" button on the top left causes the full page transition to stutter. The profiler says more than 150ms is spent in a getBoundingClientRect call in a componentDidMount triggering reflow + style computation and 30ms on set Element.innerHTML. That seems excessive especially since I'm looking at this on a recent M1 Macbook.
Web tech never ceases to amaze me in how they keep over-engineering simple things.
You have a backend service, you implement it in whatever language you want, presumably C++ if you care about performance or are doing something non-trivial. It provides REST and WebSocket endpoints to input and receive data.
You have your GUI to visualize the thing. Common sense is to have the overall structure in HTML and fill it in with JavaScript that queries the backend. The advantage is that you have a rapid and interactive development environment in the browser and can quickly iterate on a useful GUI without touching the backend.
Then, moving the GUI to be part rendered on a server, that sounds like a terrible idea, a good way to increase latency and to add load onto your servers. If you need to do that to get decent performance then probably your backend API is inadequate.
Compiling the code also breaks the whole point as it makes the development non-interactive.
I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it.
It’s a neat trick but still second to useful content on the first page (that is the page you get to read, if it lets you).