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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
"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.
- 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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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 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.
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).
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.
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
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'
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."
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.
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.
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
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.
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.
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?
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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'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.
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.
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
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.
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 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.
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 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.
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
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.
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.
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.
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?
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.
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.
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.
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?
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.
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.
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.
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 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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?
539 comments
[ 3.5 ms ] story [ 322 ms ] threadI clicked the link out of morbid horror.
The experience of doing these transformations in template languages is pretty sub par.
I hate the scroll hijacking and other shenanigans on modern 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.
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?
This is straight-forward stuff.
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?
How would you approach SSG with Classic ASP?
"The web is too complex! All these web frameworks are too complicated!"
"Okay, what do you suggest instead?"
"I'd just use [completely unmaintainable technology from the 90s that is no longer supported by its vendor]"
"Okay, how would you approach [basic feature of the web framework]?"
"Stop moving the goalposts!"
Come on, you could at least come up with some hand-waving about cache headers and CDNs.
Granted the pages probably wont look as good as what they have here or be integrated in their larger docs, but yea its possible.
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.
> 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.
EDIT: http://bettermotherfuckingwebsite.com
Funny read: https://archive.is/dR1mQ (need to use this link because it is one of those HN-traffic-hostile sites).
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.
Some more unhinged stuff I noticed:
- swiping backwards exists the drop down menu for some inexplicable reason
- clicks on menu bar items take so long I genuinely thought I hadn’t tapped on it correctly.
- taps on the menu bar sometimes just don’t work. Like, at all. Oh scratch that, the menu was there after I swapped tabs to write this sentence.
- massive chunks load in at different times: the signing key page shifts as more content loads in 3.5 seconds later.
“Nah, this guy on hacker news said we’re dumb hipsters for adopting the new normal for react. We should stay on the old versions.”
That’s like saying you don’t trust a company because they updated from PHP 5 to PHP 8.2
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’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.
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.
We kind of did (well, 2013), but it just wasn't backed by a massive developer marketing effort.
It feels like the end state here is going to be HTML+CSS with JS for interactivity using APIs, which is exactly what I was doing in 2006.
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 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.
Also, I recall heavily using jQuery and Ajax to update parts of the page before Spa’s came along.
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.
The server side components didn't seem to me at a glance significantly less convenient then say a normal PHP server stack.
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.
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?)
People (rightly or wrongly) believe the new technology is better suited to their problems.
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.
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.
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.
There are two main advantages of SSR;
- 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 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.
For general performance you can cache the modules using a service worker.
In any case they are fine for most use cases.
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 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.
We're using typescript so building only once a day isn't an option.
I don't know what machine you're using, but filling 2.5GB of RAM was already taking less than 200ms back in 2018.
I don't suspect memory usage is an issue here.
And getting more RAM is just delaying the problem anyways since it takes more RAM every week as the product evolves.
During development vite has HMR and you don't need to run build after every change. This is no different when using SSR.
But I don't want to further argue. If you think that SPA is not suitable for your use case, that's ok.
It does reload changes very quickly so I guess it has some caching somewhere.
> But I don't want to further argue. If you think that SPA is not suitable for your use case, that's ok.
I personally never seen a use case which did not end up the way I'm describing, my 2 previous companies suffered the same issues.
I even warned my current company that there's a good chance that it would end up the same way and sure enough it did.
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!
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.
Thin client vs thick client has been a point of contention since mainframes and minicomputers.
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)
(but yes, we have unusual customers I guess)
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.
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
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.
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.
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 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.
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).
Simpler times.
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.
[0] https://www.coursehero.com/study-guides/physics/15-6-entropy...
[0] - https://isso-comments.de/
(though seriously, in my dorm room in the 90s, my pentium 90 desktop at the end of my bed had a fixed IP address and was the server...)
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 not awaken the Ancients for only the pure of heart will survive such an encounter.
I swear you js haters never fail to make me laugh with all the ignorant lamentations.
> 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."
Let us not sink into unproductive musings of the intellect, but meditate on the nature of the pendulum swing.
I would be careful assuming too much about us, who are wise in the ways of the world and, dare I say, exceedingly goodlooking.
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.
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.
Seriously though, I saw someone described as a 22 yr old software engineer in an article. There is a better term: "Software Engineering Apprentice"
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
that's the opposite of what a union does. A union rewards seniority and nothing else.
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 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.
He talks about using WASM for applications and HTML/CSS/JS for basic websites.
What does he suggest we do about the UI layer? Draw pixels on a canvas from WASM?
Yes he says to use a language that compiles to WASM for the UI parts to draw pixels on the screen.
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 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...).
I personally use Flutter for a lot of my apps, as well as React/NextJS for SEO based apps, the combo works pretty well.
Whelps. Time to learn C++ again!
The JS ecosystem destroys the past like nothing else.
On top of that, the breadth and depth of its complexity and ecosystem and the solutions it helped build means it's really not going away in a hurry.
Updating a 2013 site from jQuery to Angular was small potatoes compared to updating a site now from react to react2.
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.
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.
https://w3techs.com/technologies/overview/javascript_library
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.
That it's still in active development with tons of users?
https://blog.jquery.com/2023/08/28/jquery-3-7-1-released-rel...
God, I hope not.
Fixed that for you. I think this is the real reason.
what other options did i have?
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've tried to produce a lot of technical content, arguing for htmx on its merits:
https://htmx.org/essays
https://hypermedia.systems
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
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.
Jinja2 is better, but most of the time, I would just build the API and not bother with rendering anything on Django itself
Do you mean having a javascript templating system maybe? Not really worth it's weight in gold.
Ruby example that Github is using: https://viewcomponent.org/ https://viewcomponent.org/viewcomponents-at-github.html
Plus if your frontend is react, it’s much easier to keep all the html generation in one place.
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.
Frontend docs sites almost always include runnable examples, that you can play with inside the docs.
Pretty sure Google started / had this years earlier (before Stripe even existed?). And there may have been others earlier as well.
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.
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.
This is the curse of software developers and employers everywhere tbh.
Edit: downvoters, I'm genuinely curious to hear your perspective.
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.
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.
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.
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.
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.
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.
None of this is prescribed by React.
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.
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.
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.
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)
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.
Not really, the percentage of users for Solid, Svelte, and Remix are vanishingly small. They're essentially testgrounds for React anyway.
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 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.
It's less full-circle, and more a blob that vaguely resembles a circle when you use are fully zoomed out.
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.
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.
https://en.wikipedia.org/wiki/Comparison_of_data-serializati...
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.
It's not a bad idea, but it's strange to see old ideas presented as novel.
As Sagan said, “If you want to bake a cake from scratch, you must first invent the universe.”
We’re remixing everything all the time, nothing is completely new and that’s fine. We still move forward.
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.
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.
Context is a really nice way to do this.
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.
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
These frameworks were not created to solve “Simple hello world” apps.
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.)
This wasn't a rant against React. It was about the inmates (or junior devs) running the asylum.
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 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 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.
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?
I have worked on international teams where it was a running joke the individuals had ended up assembling the same Ikea furniture on three continents.
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.
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.
One still can simply drop html file and sprinkle it with jQuery.
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.
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.
Makes you feel clever.
Idk what else to tell you.
> npx create-next-app@latest
Press Enter a few times for default settings and voila, you have a hello world app up and ready to run.
There you go.
Emphasised the parts I think you should re-read
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.
I mean, don't use "the fattest framework" then, who is forcing you to use it for writing hello world?
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. :)
Cheers!
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.
But yes, it's still interesting that you haven't responded to those other comments, as I've said.
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!
- npx: command not found
- install node / npx
- npx create-next-app@latest
- realise your node is too old
- install nvm / node
- npx create-next-app@latest
- answer a bunch of questions
- npm start
- get an error: Error: ENOENT: no such file or directory, open '/tmp/my-app/.next/BUILD_ID'
- npm run dev
- hello world in browser
It's not as simple as shipping code to the user.
For me it has never worked in first attempt.
On other hand Ruby on Rails bundler very rarely game me errors, and for every error provided hints what to do.
- browse to file:///tmp/index.html
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.
Yes, as I said.
> - npx create-next-app@latest
> - realise your node is too old
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.
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.
Pipe dreams, my friends. Pipe dreams.
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.
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).
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.
There are actual forums of normies and the most notorious meme factory on the internet is hardly a wonder of UX technology.
We are not on some subreddit for a reason.
This has other reasons though, like the fact that this site has better moderation and better users in general.
The simple truth is people are drawn to websites for what they get out of them.
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.
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.
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.
https://nextjs.org/docs/app
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.
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.
becomes 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.
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.
FWIW: Material UI for Svelte has been around for a while as well.
https://sveltematerialui.com/
Just make a descriptive class name and write your CSS styles. That's it. You're done.
https://learn.svelte.dev/tutorial/styling
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.
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.
But the rest of us stuck in legacy-land the toxic waste dumps of these over-engineered behemoths will be with us for years to come.
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.
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.
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
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.
"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
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.)
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.
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.