I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline.
And now its extended with serverside components.
I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running.
I retreat back to my simple 10kb component framework in which i need only f5 to rebuild.
They simplify the on-boarding of 6 months boot-camped front-end developers. They can start working and delivering right away despite not being able to tell the difference between front/back ends and having no understanding of servers.
I can’t edit comment now. Not sure why some readers perceived my tone as negative. This is a neutral view and am just explaining why React server side is getting adoption and how this is being driven by the business side of things.
To be fair, we tend appreciate these kind of features when we are on the other side, buying, say, IKEA furniture. I respect, but don't particularly want to support professional carpenters if given the alternative. E.g. you can have cheap shit now or wildly expensive "proper" products later where the "proper" means something I do not and can not appreciate - to put it simply I know wood is made from trees and there ends my appreciation of the craft.
Getting me "on-board" quickly with some basic furniture is quite helpful, although it requires IKEA-level infrastructure and investment to get these things in front of the buyers which is definitely not easy. Dare I sare ridiculously complex?
When I was younger, in a new space, my priority was FILLING IT so I could go about my life. I appreciated how easy it was to fill a space with Ikea.
Now that I'm older, in an old space, my priority is EMPTYING IT so I can go about my life. I now appreciate how permanent your space can be if you carefully deliberate each addition.
Exactly! These frameworks enable people with 6 months of "software developer" education to enter the industry and enshitificate our careers with their minimum wage level understanding of actual software engineering, dragging all of us down to their salary level.
If your career can be significantly affected by devs fresh from bootcamp
Well, there are certainly problems if that's the case. But it's not necessarily senior ICs that are the problem.
I've experienced a few companies where "boot camp yahoos" wound up essentially running the show to ruinous effect. Why? They had numbers, essentially, and management was too hands-off to prevent it.
To give a specific example: we had a product where our UX was basically: fill out this HTML form to apply for a financial product. Traditional dinosaur-style server side rendering was more than enough.
The front end boot camp yahoos somehow wound up forcibly moving us to React. They got that pushed through and approved before anybody knew about it because they gave a bunch of BS stats to management who didn't care and also didn't have the technical chops to spot the BS.
The end result was that simple changes to the UX (like adding a question to the form, or removing it) required 1,000+ lines of code across multiple repos. Hundreds of hours dealing with that mess for zero gain instead of actually doing things that made the company money or improved our process in meaningful ways.
Senior ICs had no real chance to oppose this plan, and many of them were happy simply to get "React" onto their resumes.
So yeah, problems aplenty, but it's possible to be an IC and have one's shit rocked by this kind of thing through no real fault of one's own.
(I'm not crapping on React specifically here. It is powerful and there are use cases where it excels. I am also not crapping on junior or boot camp engineers. They are doing their best. It's a management problem.)
You describe the scenario I am complaining about. These boot camp developers do not have the background for large scale engineering, yet get cast into it side by side with real seasoned engineers. However, that real seasoned engineer is a small fraction of the "dev team" and gets overwhelmed by the boot camp developer's group thinking - their opinion is just as good as the guy with the CS degree they figure, after all, their boot camp crowd seems to win the debates! And the employer's development quality goes to shit as the people actually trained on large scale project development are overwhelmed by fast food educated "developers".
However, that real seasoned engineer is a small
fraction of the "dev team" and gets overwhelmed
by the boot camp developer's group thinking -
their opinion is just as good as the guy with the
CS degree they figure, after all, their boot camp
crowd seems to win the debates!
Please don't do that; it's effectively turning "makes minimum wage" into an insult. There are plenty of people that earn minimum wage that are good people, doing their best, and (in many cases) doing a very good job. This is exactly the kind of wording that turned various minority terms into insults, as we shouldn't be doing it.
I see your point, but in my case above the term usage is correct. By stating "minimum wage level understanding" I am equating the work they do to be equal to what a untrained minimum wage employee is expected to be able to accomplish. These "boot camp developers" are not engineers, and are barely developers at all. They are logical pattern repeaters, with an extremely short list of logical patterns they know how to use. Presented with the open ended work actual software developers are commonly tasked, they reach for an ungodly large number of supports and produce these modern code crap piles that are growing oversized data centers, duplicating all over the landscape. They're fantastic for selling more servers, and that is about all these boot camp developers are good for - we end up cleaning up their crap piles anyway.
I don't really buy this argument. Raw CSS/HTML is easier to understand. At the end of the day, all frameworks really do is remove `getElementById` and a couple helpers like `element.style.display`. This does make code MUCH cleaner, but the argument is that raw code isn't easier to understand.
I have also had a couple of CSS wizards that wrote all the styles by hand - sounds great until someone has to fix it, even a senior designer. In short, a well-used framework that's understood is not necessarily easier, but it does lead to an agreed-on set of abstractions that make things easier to understand. Angular and React are very much there for a reason.
That’s not totally true though. React, used correctly, lets you use and share a mental model where you have clearly defined the minimum complete information required to display any state of the app, and separately you have a set of simple functions which reliably convert pieces of that data to correct html.
That’s insanely powerful and massively reduces complexity in highly interactive apps, because it means you no longer need to think about “user did this, update this here now, and here and here” chains, and can just do “user did this, update the state” and have that state update render potentially hundreds of changes across the app without needing to do additional implementation.
But if you aren’t disciplined with maintaining, or don’t understand the difference between pure functions and side effects, and fall back to hacks to try to “make things render” or “stop wasting render cycles” you’ll end up with even more complexity than necessary.
Using react as another version of `getElementById` leads to a horrible mess much worse than writing vanilla javascript, and most people who have that complaint are doing it to themselves by fighting react either unintentionally or on purpose to show how it can be bad when abused.
Raw HTML and CSS is much easier to understand, and mandatory to understand because at the end of the day creating HTML and CSS is the only goal, but higher level abstractions can be super useful to manage complex projects, and the mental models and abstractions are the actual benefit.
That's a good addition - I was being reductionist by saying it eliminates a couple of functions that identify and modify elements. With that said, I feel it's still pretty close to being "just that" - I understand the details of everything you listed, but at the end of the day it just keeps track of individual displayed items, if they are parts of objects and regardless of how they are passed in (params, state, context, etc).
To give some abstractions out of the box, mostly, so you don’t have to reinvent the wheel - the demands of a lot of websites and applications nowadays include interactivity on every level, very fast and smooth ui population, and pretty animations. Sometimes the tools are great for working in huge teams on the same codebase, sometimes it’s for giving a lot of features to a smaller team.
> the demands of a lot of websites and applications nowadays include interactivity on every level
The demands of the PM maybe, most users just want something the works and gets out of their way.
> very fast and smooth ui population
Neither of which your average JS/SPA/behemoth is actually good at.
> and pretty animations.
I’ll give you this though, JS web apps certainly do rep some pretty animations, often at the cost of thrashing my CPU and ram.
Crazy idea, but maybe, if instead of spending ages building “interactivity” we just built “applications that worked”, we might actually have less mess, and build better products.
Having seen systems be built up over time that do significant things (or run on many platforms, or have lots of abstractions) a lot of the time the tougher parts are.. well, complicated. Some of those tools are to make things better for a lot of programmers working on the same project. You have to have some amount of structure then. Sometimes it’s so business people can create content.
“Why doesn’t it work simply” is often a business decision.
Ironically, “Web Excel” doesn’t use any of them. And if you asked someone who can create Excel to implement it in a webpage, they wouldn’t probably even think about these frameworks seriously.
The real promise of these is web forms with a little interactivity. Anything more complex and you start to fight with it to drop back down to the level where it’s manageable.
React is a little bit painful and massive overkill for web forms actually (compared to other approaches).
It’s the fighting with it that’s the issue; my experience is that a lot of devs go in to “force this stupid framework to work” mode and blow up tasks that should be 10 lines of code with no edge cases into 50 or 100 which “mostly works, good enough.”
React is by far the most adopted framework for desktop-level or near-desktop-level web applications.
Not sure which web-based spreadsheet app you're talking about, because there are many that do use these frameworks. Here's a PS/AI clone built with a Svelte frontend: https://graphite.rs
What kills me is that many websites would be better in every way if they were just html and css. I have come to think of it as premature optimization for some fancy capability down the road. It's like telling people they have to hire engineers to take core samples and do seismic modeling before building a chicken coop.
As evidenced by the large numbers of production html and css apps that are outcompeting their competitors who use modern web technologies with greater product quality, and the swathes of customers who state their preference for these experiences.
But seriously I have no idea of a single remotely well-known application that satisfies the above. If the modern web is so bad where are the products that prove that it can be done better more simply? There’s billions to be made if that’s true in all industries, is nobody skilled capable of capitalizing on this gold mine of opportunity wherein the entire industry is self sabotaging?
I’m left to conclude that these HN commenters with their hot takes about how the modern web sucks just generally either don’t understand what makes products successful or never have truly experienced the issues these frameworks solve for.
While that is true the current state of reddit UX allows them to succeed by virtue of critical mass gained before they went nuts. If you created a new site with that UX you would get nowhere.
The simple truth is people are drawn to websites for what they get out of them.
I recall being turned off by Reddit's UI when I stopped using Digg. The content was so incredible that I learned how to love it. And now they've killed Apollo so my only interaction with it is via Google search results for my problem du jour.
It usually takes government to tie people up in these sorts of knots. These people have enthusiastically done it to themselves. Resume driven development is a hell of a drug.
This is precisely why you see this move from complexity. The younger devs are beginning to see it. Just like we dumped atrocities like SOAP and XML in favor of simpler and more ergonomic tech, this generation is learning - again - that complexity kills (and makes this job intolerable).
Who knows, maybe software development is going to be fun again, even if for a few years before the new batch starts turning it into a mess.
It’s the interest rate. When rates are low, devs are paid to build complexity, new frameworks, tools, languages. If the interest rate stays low other devs will get paid to play around with those new frameworks, build more complexity on top and so on.
SQL, html, C … get things done. When rates go up, these non-bs technologies are incentivized. Paying devs to create new frameworks/apps/products just so that those devs are happy and don’t go work for the competition is what results in complexity for complexity sake.
Those who hitch their success to the latest greatest shiney new bs tech are the same who used to sneer at those who didn’t cover their webpages in flash animation. They make the mistake of thinking the current way is the best way. It’s not old vs young, these two mindsets exist across different stages of the lifespan. Generally speaking, older people have more data and will therefore spot the patterns/cycles a bit easier.
After kicking and screaming about learning yet another React framework I took the time to build an app fresh in NextJS and it really was a breath of fresh air, felt more like a mature, simpler form of React.
Feels like bloated garbage to me. "Hold on, let me make an MVC React framework with a Node API, so you can call your APIs from another API!". Thanks Next.js. Really wanted this. Honestly, might as well go back to Angular at that point - no redundant "API" there, at least.
Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSideProps' function that will do magic and generate component props, but it has to live in the page, so the page gets extremely bloated, oooo."
I hate Next. And I realize "hate" is a strong word that takes some earning.
Have you tried SvelteKit yet? I can't say it lacks magic, but that magic is focused on eliminating boilerplate, not hiding where everything is coming from and going to.
It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left.
const { count, setCount } = useState(0);
becomes
let count = 0;
There is no more useMemo(…) or useEffect(…). They just don't exist. There's no need for them. State management "just works" by using a store variable like $store. No more explicit subscribe and then having to remember to set up an event callback to unsubscribe and avoid a resource leak.
Vanilla JS libraries typically work out if the box with it without some bespoke wrapper or adapter for your framework. ("bind:this" is really handy.)
Web development with 99% less BS. Lets you focus on your problem, not on your framework's abstraction leaks.
the only downside for me is that there aren't many mature UI libs for it yet. I was evaluating it for a Tauri-based project but I went with React instead because of this.
You guys can try https://bulma.io/ as a middle-ground. It provides some fundamentals styles that aren't married to JavaScript, so there are never any conflicts with any SPA version. It's not widely used, but it worked well for us before going to Material UI as the team grew and the designers wanted something everyone is familiar with.
Yep, the amount of UI component libraries for React is truly staggering.
I myself am more of a clean, standard HTML with PicoCSS kind of dev, but that model doesn't work for everyone. Some might be surprised how much plain old HTML and the ease of development for Svelte components narrows that gap, but I'll be the first to admit the gap absolutely exists.
Oh! I forgot one of the best parts! CSS is automatically scoped to your component. No manual shenanigans. No weird naming rules your dev team have to agree on. No giving up and just using inline styles. No hacks.
Just make a descriptive class name and write your CSS styles. That's it. You're done.
As long as a framework invents their own HTML-like DSL, I'm not using it. I've used enough Vue back in the day to know I wanted to move to React where I can use actual JS, as well as get excellent TypeScript support out of the box.
> As long as a framework invents their own HTML-like DSL, I'm not using it.
Okay, that's a choice.
> I wanted to move to React where I can use actual JS
You… uhh… know that JSX was literally invented as React's own HTML-like DSL, right? And that TypeScript is not "actual JS", right?
Just food for thought: HTML can exist and provide tremendous value on the frontend without JS. JS on the frontend without HTML is… not quite as useful. Be careful about which technology you want to be the central player.
I knew this comment was coming. JSX is not the same as the DSLs of Vue and Svelte. They often have poor support for TypeScript and cannot be mapped, folded over etc, because they are not "just Javascript with syntactic sugar," they are a much more rigid DSL. Trust me, I've made a lot of Vue sites, I know what it's like to use JSX vs that kind of DSL.
Never mind that TS is a superset of "actual JS," your point doesn't even touch my argument which is that I want type safety, such as when props are missing or invalid types, and so on. Even if TS is not "actual JS," that's a semantic argument and doesn't matter as long as type safety exists. I've even written sites in Rust via Yew, works great and outputs HTML at the end of the day.
> Just food for thought: HTML can exist and provide tremendous value on the frontend without JS. JS on the frontend without HTML is… not quite as useful. Be careful about which technology you want to be the central player.
Not sure what you're talking about with this point, I never said HTML isn't useful.
Why would I like HTMX if I already said I dislike HTML-like DSLs? I tried it, it has the same issues as Vue and Svelte DSLs. I don't want to turn HTML into its own programming language when I have a perfectly good one through JS/TS right there that I can use.
The API isn't redundant, it's convenient. You don't have to use it. Just delete the /api folder and make your requests either from the client side or fetch the data inside the handler that you're complaining about. With the new app router, you can fetch it from the server component itself without the handler.
Could you elaborate on the last point or link me please?
I disagree on the convenience point - it's bloat and not in the sense that people say "IDEs are bloat". It's regressive in going back to an MVC pattern in a framework that's meant to be an SPA and completely violates the "There should be one, and only one, way of doing things" principle in that it adds confusing options that people end up using in practice.
Next.js is pretty convenient, not sure why people find it so inconvenient. With the pages directory, each page is its own page, just like in the PHP days. Why do you think it's an MVC pattern? I don't use Next like that at all, it's just React.
See my comment above - it's greenfield projects too. Company I work for had a nice .NET Core / Gatsby React set up with reasonable Microservices on Azure. New leadership came in. Rewrote it "all" (3 years in so far) into a wait for it, MONOREPO! in Python (at least they used FastAPI), Next.js (just to have a useless API which calls other APIs, because apparently 'cookies are more secure than JWTs' (I guess they think not being able to fetch them in JS is somehow security), and AWS. So far it has half the functionality, 10x the libraries, 100x the confusion, but hey, at least we went from 5 devs to 100 just so everyone can be confused TOGETHER!
This kind of take really annoys me; your pipeline can be as complex or simple as you need it to be for your specific use-case. If you want to build an application using static file, or a little Makefile that uses a single esbuild command, or a hulking Webpack configuration with 30 plugins – you can easily do any of these in line with the demands and complexity of what you are trying to build.
Also, evaluating tooling based on how easy is is to create a "simple hello world" is only useful if your work involves creating "simple hello world" applications, which it doesn't.
One can choose to limit complexity. Nothing is stopping a personal from building things with html, css, and vanilla js.
Think of XHR -> Ajax -> Fetch API or others (Axios).
No one is stopping you from writing out a 20 line XHR request. You can also write a 2 line Axios (or some other XHR-wrapper library) request.
After I took the time study webpack (a day) or reactjs (a month) for example, I really appreciated the options webpack brought (code related plugins), and the structure reactjs brought to my project.
This blog post covered SSR better than most blog posts I've seen
Anytime SSR or any of its derivatives comes into the conversation I always ask myself if things are becoming unnecessarily more complex. React server rendered components sounds like it's taking things too far - it goes against the natural developer experience DX order
If your complexity on the app is doubled and it slows and confuses all the developers with increased coding footguns for only a measly gain in performance, is it worth it?
Good old php sites and rails app with no SPAs have worked fine over the years
This stuff appeals to a breed of management in the same way "full stack development" does, which is to say those in denial of the need or value of specialisation.
The other benefit of such developers is they don't need teamwork. You just throw a feature request out at each dev and they do it end-to-end with you oblivious to the mess that is being created in the process.
Hah, that breed of management predates the JS world of crap. My current manager sees no problem in the job postings ridiculously listing every single language/platform we have worked with, even 30 year old 8086 projects, even when any new hire will most likely be touching none of that and will be writing some mundane C for an ARM.
"It doesn't hurt to list everything!" - Him
"Why the fuck would someone want to apply to what looks like an absolute hell-hole?" - Me
"But they should apply anyway if they know some of it!" - Him
No shit the quality of applicants is sometimes not the greatest
I'm thinking of joining Kroger to help with the Albertsons merger. They are looking for Java developers, cool, some sanity. Learned they have decided to build all new stuff in Go. Like WTSF people? I can find no justification for building mundane business systems in Go. Ugh...managers.
You want to use substantially less RAM and therefore reduce the number of instances/containers you need to serve requests, thereby non-trivially reducing infrastructure costs?
Or you're on AWS moving toward a more event-driven or serverless architecture where Java doesn't really have the same flexibility (and you don't want to retool your builds for GraalVM)? Go lambdas are really fast and trivially easy to write.
You want substantially faster build times to reduce developer idle wait cycles?
There are plenty of reasons to move to Go.
(Note: I last coded a Java service last year in v17, and my first Java code was using v1.02. I'm no Java hater.)
I get what you are saying and I can agree with that. It would be nice if that level of performance was their main concern. However, we are talking about an org that never has full dev staffing and has a lot of turnover and needs to respond to business needs quickly. I would not want to be trying to hire Go devs in that situation.
They have banished AWS..."competitor." A company that can easily justify their own infrastructure (and save a ton of money) is plunging into the Microsoft Azure hot mess. I could go on and on about a lot of other issues brewing there. Very dysfunctional and panicy trying to look hip to investors in comparison to Wal-Mart and AWS. Basically dragged kicking and screaming into online ordering and pickup/delivery and trying to act like it was their idea (very much had/have a browse-in-store sell you more crap you don't need model).
I'm a life long customer of many of their stores and have been plugged into their tech issues via various contacts for about a decade.
Look at your computer. Are all its parts and pieces strictly necessary to display the text "Hello world" on your screen? No. Why don't you throw it away and buy something simpler, then?
React is a general purpose web framework, and is routinely used to do more than serving static documents. I would argue it was never even designed (originally) for that use case. And yet because it can, we have to have this tiring endless debate.
> When you're writing a specific program, e.g. it's never going to be anything more than "Hello, world!", why would you use the fattest framework when you can write it in plain HTML?
Sorry, I guess I disregarded it because I figured we were talking about serious programming, not literally "Hello world".
And if you're writing a single "Hello world", HTML is overkill. Make a free website on a random platform and literally just write "Hello world" in their WYSIWIG editor. Or hell, just serve plain text with "Hello world" inside, browsers will render it just fine.
As you get more experienced in programming you'll inevitably inherit projects that you didn't have any say over, when that time comes come back to this comment, I'd be interested to hear if you still feel the same way.
I have inherited such projects. But it seems like you're talking about code that is no more complex than hello world, as you've quoted, so it wouldn't be too complex to do in any language or framework. Now if you do inherit a larger project that you don't like, well, you either work on it or you switch jobs.
> Now if you do inherit a larger project that you don't like, well, you either work on it or you switch jobs.
Which you wouldn't have to contemplate if your predescessor had simply used the right tool for the right job, right? Such as not using an over-engineered framework for a problem that didn't need to use one. :)
I mean sure, but I wouldn't work at such places anyway. One cannot escape complexity, it's either in your code or in other people's code that you use. Don't overengineer, but not everything you'd think is overengineering is actually the case. Otherwise, just work in assembly.
It is also interesting that you haven't responded to the other comments that call out flaws in your argument, just mine, perhaps because you don't have an answer for them either, as your original comment is now dead.
I did not flag your comment, if that's what you're implying. I can't downvote comments I reply to and I'm pretty sure flagging has no effect either on such comments.
But yes, it's still interesting that you haven't responded to those other comments, as I've said.
Yikes! You can't post like this to HN and we ban accounts that do.
I don't want to ban you because your account has been around for a while—but when I look through your history I see so many comments breaking the site guidelines (and often quite badly) that I don't think we have much of a choice. However, we also haven't warned you before, so I suppose it would be fair to start with that.
If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules from now on, we'd be grateful. That means no more personal attacks, putdowns, name-calling, or flamebait—at a minimum. We want thoughtful, substantive, curious conversation. I did see at least one comment on the good side: https://news.ycombinator.com/item?id=37235139, which is a nice proof that you can do this. Please stick to this from now on!
I find it curious that we always see these opinions expressed about front end frameworks, but no one seems to have much problem with all of the complexity in back end frameworks like node, Python, Java, .Net... I have a sneaking suspicion that people are just more used to having complexity hidden from them behind a framework install, whereas front end puts everything front and center since it's all delivered to your project via npm.
The whole point is to have JS on front-end and beck-end, right? What is serving the JS? Isn't the server Node?
And large security surface means just one compromised package is required to get on the server side. If an npm update gives you security warnings after a few weeks of a vanilla project just sitting there, something is very wrong.
Sure, you could say the same about any language too though. I've used static site generators in Rust too, or Python, it's the same problem. People still use them because the benefits outweigh the minute risk of being compromised.
that's still better than CRA, to make the point a few weeks ago at work, I counted > 800 dependencies and 6 high security vulnerabilities warnings. If facebook can't get their shit together, who can?
Said no one ever. I can fully understand you not having Node installed (although having any kind of toolchain installed is a prerequisite for any programming so that's a weak argument against Node). But please don't tell me that somehow you will get an old version of Node after you just installed Node, because this is just reaching now.
> - npm start
> - get an error: Error: ENOENT: no such file or directory, open '/tmp/my-app/.next/BUILD_ID'
The README that gets generated with the project literally spells out the correct command you should use to run the project during development (which is not `npm start`), so this argument is also pretty weak.
What do you code in? For any language if you don't have the toolchain set up, obviously it'll seem laborious to install it, it's not a knock on the framework used on top of the toolchain.
Java/Kotlin. You define where to get the dependencies in a simple script, you define the version of the build tools, a wrapper script fetches the build tools (gradle) for you and that's it. Everything is neatly cached system-wide where possible and on a project-level otherwise. No conflicts, no shenanigans.
Which Python, 2 or 3? How will you handle local versus global dependencies? Will you use pip, conda, virtualenv or something else? How will you package up the code and/or executable?
echo - command not found (maybe you're on Windows)
browse - no browser installed
edit - no editor found
See, I can do the same thing. In any case you need a toolchain installed to actually program in the language you want to program, even if that toolchain is minimal. Complaining about a toolchain not being installed for the thing you want to do is not very useful.
For sure. Ever had to debug a bug deep inside of a webpage's code that relied on 5-10 preconditions to get it to appear? Without HMR, you're spending a lot of time F5ing and navigating to reproduce/fix it.
If only there was a way to programmatically reproduce the conditions under which the problem appears and then exercise the behaviour that triggers the bug. Then some code could verify whether the problem still appears. Once the problem is fixed this same “test” dark magic could help ensure the problem does not occur again.
You can add a test after debugging, no one's stopping you. But yes, it's annoying to debug some UI issue and having to set up an entire integration test for an issue you already know is there and can navigate much more easily via a mouse than via linking through HTML tag ids.
First, HMR doesn’t magically put you into a specific program state. Second, you can still HMR any website, as it is a feature of a bundler, not a web framework.
HMR is a feature of bundlers but your frontend code has to specifically interface with it if you want JS changes to live-apply to a running page without losing state instead of refreshing the page. With React, you have to use react-refresh in order to have HMR support. Frameworks like NextJS configure react-refresh and the bundler's HMR features together for you.
I had a tool that would automatically reload the page when files changed, it was great!
But I get what you mean; reloading a page is fine for simple pages, anything bookmarkable, but there's heavy weight pages on the one side, and state on the other. With hot reload, we're currently developing a React Native app, we can e.g. type stuff in a form field, update code, and the stuff will still be there while the behaviour around it changed. It's neat. While I miss native iOS development a bit, I don't miss the recompile/relaunch cycles.
I didn't like the idea of moving to frameworks but it does make things simple again. It is probably slightly simpler than the stuff before SPA (Django, RoR).
There is overhead with working out where something, should be rendered but, in my experience, a lot of the issues are raised at compile-time and are quite transparent (the articles overstates the issues you have here, there is mental overhead but it isn't bad). The SPA period of React was awful for complexity (this was also when React had lifecycle methods, wasn't well-integrated into webpack...awful).
