Hacker News Reader

Comment by luxphl | Hacker News Reader

I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.

It's true that they are largely more complex than O.G. web technologies, and it worries me that they create a sort of gatekeeping effect on the industry, but I think it's disingenuous to outright claim React & co. are bad from a development perspective. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.

I've done lots of native development on Desktop and Mobile and I can sort of see how you get there if that's your point of reference, but if you work on web apps daily it's clear why the popular technologies are popular, and it's not hype.

View on HN

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice.

Lastly, I wouldn’t underestimate how this has built up slowly over time, and therefore how many people just don’t know any better.

Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing react libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done.

At the end of that session this developer said to me, “wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.”

This is a good, very productive, very fast-learning developer I’m talking about. He literally had never tried to use the DOM api, and didn’t realize it was, you know, useful.

I think there’s a lot of that in front end world today.

What a great anecdote. It aligns with my big worry here: we are raising a cohort of front-end developers who don't know how to use plain HTML and forms!

IMO, it's kinda hard not to end up learning those things even if you are in react all day.

At one point or another things don't work and it's because of simple HTML... and not react.

Maybe that's not the right path to learn it but we've reached a point where if you want a job, plain HTML and JavaScript isn't it.... plenty of folks who had the benefit of developing their skills from HTML + JS all the way up will bemoan this situation.... but if they're hiring people they're not hiring anyone who just knows HTML and JavaScript without any exposure to anything else.

That's what the C devs said about all the people learning Java.

"We are raising a cohort of developers who knows nothing about memory management."

Sure, there are things you do not know if all you know is React, but technological changes make it irrelevant in all but the most niche of cases.

Except that "niche cases" here means "everything you do with software but not in a web browser".

I meant to constrain my comment to the web development sphere. Niche cases mean some scenarios where bandwidth limitations prevent the use of React or something.

Although you can use React for mobile (Native) and desktop (Electron)

> That's what the C devs said about all the people learning Java.

That's not a great argument here. Web development is much more of a continuous spectrum. Programming platforms are designed to hide the the layers beneath to a large degree. I'm not saying there aren't leaky abstractions!

We use the term "full stack" for web developers, but people visualize this with layers, but for me it's a really wide list of items and not a very tall stack.

> but for me it's a really wide list of items and not a very tall stack.

That is fair. You need a bit of many technologies to launch a website. I always interpreted full-stack to mean that you could launch a site on your own, from the database to the buttons and thus do not require a dedicated frontend, backend, or dba.

But yes, that makes developers wide and not deep.

And you know what, the C devs weren't wrong.

Coming back to C++ after a decade of Python I realised I had largely forgotten about how memory management works and that felt bad. I felt stupid, because not thinking about that wasn't necessarily a good thing.

React still requires you to write HTML and forms.

And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.

It literally doesn't. You can build a fully normal HTML form in react. The only reason to do any of it yourself is because you need something regular forms can't provide and even then you can still use as little or as much custom parts yourself.

It literally does, unless you have the form POST or GET to an API directly + a redirect from the API.

You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because they validate on the client.

You do have to override the submit functionality if you don't want to load a new page, sure, but that was always the case with plain Javascript or jQuery or whatever.

You don't have to maintain the state of what the user inputs if you leave the inputs as uncontrolled (https://reactjs.org/docs/uncontrolled-components.html) and access their value via a ref. You could even give them IDs and access their value directly via that if you wanted to, just like you would pre-React. But there are clearly advantages to making the inputs controlled by React, otherwise there'd be no reason to bother doing so (not saying that there aren't probaly a lot of cases where you could keep it simpler but people have been led to believe they need to put their form data in Redux so use some elaborate solution which doesn't scale, or whatever).

Also if you are doing forms in React, check out formik, it's the nicest library I've found so far. Granted it's not as "easy" as a straight HTML form that POSTs to a new page, of course, but modern web experiences often demand richer functionality than "the old way" allows.

Note that we specifically recommend that people _not_ put most form state in Redux:

https://redux.js.org/faq/organizing-state#should-i-put-form-...

Also, per the form libraries question: Formik and React Final Form are the two standard packages I suggest folks look at. React Hook Form seems to be gaining some popularity. Also, I recently ran across https://github.com/wsmd/react-use-form-state and tried it in one of my own projects, and was pretty impressed with it as a lightweight option.

It's sad how convoluted something as simple as form submission has become with "modern" Javascript frameworks. I'm not sure if it is React's fault, or the way most people use it, but it does seem to degrade into a mess of over-complexity. (I've been working on web sites since CGI scripts were a thing.)

Its as simple or as complex as you make it, you can use react to render a perfectly plain html form or you can manage it totally in react. And honestly, once you have everything set up and some previous examples, managing and submitting forms in react is trivial as well.

> And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.

Show me the HTML standard that supports SPA submissions that don't reload the page.

It seems that your problem is about SPAs, not React.

>Show me the HTML standard that supports SPA submissions that don't reload the page.

Any HTML form that uses a standard button element rather than a submit button. Attach a JS event listener to it, read the form, post by AJAX.

That was a thing long before React came along.

You can actually do that with React. Nothing is stopping you.

It's not the recommended way because as soon as you want validation or dynamic fields you need state anyway.

And there're easy libraries like Formik that handle all the annoyances for you (although taking you away from raw HTML at the same time).

Do you miss punch-cards too?

Of course you can do that with React. GP implied that it was impossible without React, because standard HTML didn't support it, but wasn't correct.

There may be plenty of advantages to using React but it isn't necessary for "SPA submissions that don't reload the page."

That was a thing even before AJAX came along, eg via forms targetting an iframe.

A long time ago, I wrote a single-page chat application that continuously updated through chunked transfers, with submission via a plain old HTML form that received a 204 response.

I want to hear a war story of someone starting from a React bug report, reducing it to pure JS, fighting through the Chrome build process, isolating the v8 JIT bug, producing a patch, and going on to a successful compiler career.

Heh, I could almost tell that story. We had a bug in a React app that started when a new Chrome release came out. I boiled it down to a small piece of JS that V8 was clearly misinterpreting and which looked like it might be memory corruption in the JITed code. Yep, I got a Chrome build going and was tracing through to see what was going on ...

... but I'd also submitted the JS fragment to Chrome, of course. They ended up flagging it as a high security bug and, not surprisingly, beat me to a fix.

So I never got as far as making a patch, which I guess is why I still don't have a successful compiler career.

I did get a $1k security bounty from Google, though, so that was cool.

Let me see if I can google the bug report. This is it: https://bugs.chromium.org/p/chromium/issues/detail?id=282736

Ah, report reminds me that at that point, the app was all knockout.js. We ported it to a knockout/React hybrid later.

Hey all

I remember when jQuery was the React of its day. Then browsers copied most of its stuff. And now we have moved in to Angular and React.

Frankly, web components can do most of the stuff React does - and even the JSX can be done with eval and concatenating some backticks to strings. As long as you are SURE the strings are coming from templates, they can be assigned at runtime similar to how React assigns at compile time. Not that you should do any of that crap!

Still, React and Angular are insane. React makes you use Babel for JSX and a bunch of esoteric rules that they then make workarounds for, such as “hooks”. And Angular is even more complex, with its digest cycles and mocks and bindings etc. It totally sucks you in.

If you want to use a framework that’s much more lightweight, use Vue. Or use the one that we built ;-) It treats CSS, HTML and JS — and the rest of the Web - exactly as it was meant to be, and doesn’t try to reinvent the well. Well, it does use Handlebars for templating, but can support any other one also.

The React fad is like jQuery.

to me, though, javascript development has always felt like a chaotic tangle of duct tape, until I started working in React. somehow React feels like _writing software_ - building things in small pieces with well-defined inputs and outputs.

And JSX feels like the programming style that I didn’t know I was I’ve been missing since the 1990s - like it’s the logical conclusion for working in HTML, when everything else was either doing sloppy string manipulation or really indirect object-graph walking.

I don’t love babel, but we have a hot-reload script that auto-compiles while I’m working and even swaps in components to my webpage without a reload! It’s actually _less_ friction than vanilla javascript. I cannot imagine going back.

I hope eventually some of these technologies get pushed into the browser, but honestly it doesn’t matter much - javascript is fast, we can afford to use it as a compile target

Want to jump on a call with me - just for fun - for 10 mins? I will show you our framework that we use internally:

https://calendly.com/qbix/meeting

IMHO the framework makes way more sense than React in that it is a lot simpler to reason about, and it also treats HTML CSS and JS sensibly. React is a bit esoteric... but it has the backing of a large company so everyone uses it. It’s a bit like Wordpress is used by everyone despite its codebase being from 2004. Like it’s OK, I get it, you have to buy into the ecosystem. But I think one day it will be replaced by something cleaner.

https://qbix.com/platform/guide/tools

This is what I meant by gatekeeping; there is common misconception that you have to go looking for a library to solve a problem. And it makes it seem like there's a higher barrier to entry than there is.

But the reality is that React is plain HTML and Javascript, in a less error-prone and maintainable package.

Everything you can do with vanilla JS you can do in React, but with React you benefit from being forced to separate the state of the DOM from manipulating it.

I don't buy the hipster-centric logic, for me it comes down to productivity. The bugs of yesteryear, tracking down which procedural code path led to modifying a variable, are mostly gone with React. And if you don't use it (or something like it), you end up implementing a subset of it anyway because it's a foundational part of coordinating UI with business logic. /shrug

React is not the problem, it's fine as a component in a page. The issue is the abuse of SPAs.

As a sibling comment notes, and as I noted in a reply to the OP, I agree with you that working with components is a nice approach and very useful. Using React as you describe is perfectly fine. The SPA craze where everything has to be done via React components is where we've jumped the shark IMO.

Doing things with react is mutually exclusive with SPAs. You could even do a purely server-rendered website using react on the server if you wanted to, and all the benefits of functional component design can still be utilized.

You probably meant "orthogonal" (a smarter-sounding way of saying "perpendicular", in the sense of "linearly independent"). A framework made and used primarily for doing SPAs can't be "mutually exclusive" with doing SPAs.

Maybe they just wanted to say "isn't"

That's fair. I have an app that is rendered server side (Node.js/Express) and the frontend is built with jQuery. Made sense at the time. But I ended up adding two very interactive modules and decided React was best for them and added it in piecemeal, and I was right. But now trying to integrate the new features with the older ones, I wish I started with React for everything. This happens more frequently than I'd like and it's why I'm skeptical of saying SPA's are bad. To me they make my life easier and are very flexible.

Currently the site I'm building is a pretty static site of about 30-50 pages that is just brochureware for a non-profit scientific organization, on one hand I feel sort of embarrassed because it feels like I'm back in 2004 and I have a hard time justifying my salary for something like this, on the other hand I'm really super embarrassed at making the wrong solution because a React SPA with a service worker has been ordained as the way to make this thing.

Gatsby (static-site generator powered by React) was a massive timesaver for me. Sure, you spend a bit longer setting up some basic components, but the trivial ability to share those components between pages more than makes up for it...

Yes of course I want Gatsby, but that is one of the things I'm not being allowed to do. I think I may have gotten overly sensitive these years to not getting my way on architecture.

You still have to debug those - if you set the wrong state/etc, things will break like before.

All react does is remove the need to modify the DOM directly when you want to modify things.

But setting the wrong state is someting that happens far less and is much more traceable, because the encapsulation of state changes into a single place massively reduces the side effects (and global state) that were the cause of 90% of those bugs in the bad old days.

The OP said: "The bugs of yesteryear, tracking down which procedural code path led to modifying a variable, are mostly gone with React."

Which is wrong, React doesn't address that in any way, shape or form.

> But the reality is that React is plain HTML and > Javascript, in a less error-prone and maintainable > package.

This is far form the reality. And the reality is, that more often than not you do not even need JavaScript, not to mention React.

>If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most

I see this everywhere in programming, not just frontend. I think this silent peer pressure influences us all to some degree. Whether through not wanting to look outdated or foolish, to just being tired of the uphill battle involved constantly fighting against the unstoppable momentum of the cargo cult.

Can you give an example of a problem that would take significantly longer solving with React than with DOM manipulation?

https://bugs.chromium.org/p/chromium/issues/detail?id=604033

You want to log an integer to the console 100,000 times? Not sure why you would, but you can do that in a React event handler or lifecycle method.

A lot things can be easier if you do things the "wrong way". App development can be faster if you don't use Typescript, liberally use the "any" type, or just avoid. Most of recent javascript tech like React, Redux, Typescript, et all, came to reign in the multi-paradigm language that is Javascript so that larger organizations can actually make maintainable error free code from a language and ecosystem that is very easy to shoot yourself in the foot in from junior developers.

Sure, you just do some javascript and HTML to get your thing working quickly, but that hasn't even been recommended since the days of Jquery (where it was recommended over just doing vanilla JS in order to maintain cross-browser compatibility).

It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable, and that's before even considering things like browser compatibility, accessibility concerns, localization/internationalization, etc. A simple app or product does not mean the internals are necessarily simple.

> A lot things can be easier if you do things the "wrong way".

> It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable...

I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to full-on SPA.

When presented with most spectrums of choice like this, it's expected that most people will weigh in requirements first and choose the solution based on the requirements (if they are an engineer, or pretending to be one.) In terms of expertise, they might love to write SPAs, but they realize that the other options on the spectrum exist for reasons other than being in, or out of fashion.

The problem is that some folks overemphasize what's in fashion. There are many reasons for this, and it's something that happens across other disciplines, not just programming. That said, we have a unique situation with programming in that someone can be quite an expert while only understanding one end of the spectrum. It's very easy for these folks to hold sway.

When it comes to the "wrong way", I agree with you, but I'd go further. If the requirements demand a SPA then you need to go all in and use the best modern tools. There are a lot of things created as we moved out of the full page render ages which don't result in good SPA development (for users or devs.) Embrace Typescript, React, etc because these solutions have evolved from that in-between stage.

Using "browser compatibility, accessibility concerns, localization/internationalization" isn't a great argument here. These are often orthogonal requirement. It's easy to argue that full page rendering, or static HTML meets all these more easily. These apps can't compete if you need particular interactive experiences.

I did address that it depends on your requirements. But my point is that it is highly unlikely that any requirements would be better served by vanilla JS + html than say writing your code with ES Next or React, unless you truly have some sort of limited use one-off thing.

Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA, but are meant to decouple the maintainability of your code from the implementation details. React itself isn't even a framework but a paradigm which just happens to have a specific implementation that requires their runtime. The most recent shift is to turn your components into pure functions, and this is less about the framework and more about decoupling your app rendering logic from the react implementation. There's no objective argument that writing vanilla JS is better than writing modern ES next code. These language improvements are done to improve the failings of the javascript language after all.

You can totally use React to purely statically render your website. This is what most SSR implementations do, and the only reason JS is still activated is most modern apps require interactivity.

If you start doing vanilla JS and HTML you're doing a direct implementation. That's almost always the wrong way just because of browser differences between operating systems, mobile vs desktop, and all the other features that aren't really bells and whistles but more and more necessary as technology serves a bigger role. Perhaps in 1990 it's fine that a website can be made for a specific user for a specific purpose.

> Tools like webpack, babel [...] but are meant to decouple the maintainability of your code from the implementation details.

Let's be real, the only reason we really need WebPack and Babel at this point is for IE11 compatibility and JSX.

Currently >90% of the browsers (that depends on the country) are evergreen, and have support for most ES6 features, including ES6 modules. As soon as we're able to drop IE11 (when will Google remove IE11 support from Youtube?), the only reason to keep those tools will be JSX, which is frankly a minor convenience compared to the rest of React, and there are multiple alternatives to it that are not that terrible. [2]

Apart from that, WebPack and Babel are extremely hit-and-miss and terrible slow for anything but small-ish projects.

If you're doing SaaS or enterprise, chances are most of your customer-base is already 99.9% on Chrome or, in the worst case, in enterprise Windows-centric companies, Edge and that 0.01% is just waiting for something to tip them off.

I really can't wait to get rid of those two shitshows. Or maybe replace them with something actually useful, like Typescript compiled directly to modules.

[1] https://www.npmjs.com/package/domz / https://www.npmjs.com/package/htm / https://www.npmjs.com/package/react-hyperscript

Babel is there so you can write your code with the latest Javascript features and separate your written code from what is actually deployed. JSX and IE11 are a subset of problems that this type of abstraction can solve.

This is miles better than the previous alternative: manually importing shims or adding in css prefixes. Babel and webpack also enable macros and static code analysis tools so you can write code in "inefficient" ways that's more readable, and automatically generate more performant code automatically.

Browsers are still split, even if considering only desktop users. If you add in mobile users then all those iOS people are using Safari, not Chrome.

And because of this fragmentation you can't expect the latest ES features to be usable on day one. So you'll always want Babel so you can write the code the way you want, and have platform targeting be a separate concern.

It sounds like you believe that we should be writing very platform specific code for the web, which is a bad practice in general. Nobody should write platform specific code. Leave that to the compiler.

Nope. You're the one advocating targeting a specific platform, and it's called Babel.

What I'm advocating is targeting evergreen browsers whenever possible: Chrome, Safari, Firefox, Edge, and their forks. They already have most ES6 features. Even Safari has great ES6 support. iOS is known for being very up to date. Fragmentation in Javascript is a thing of the past, as long as you only use features available for +90% of the people on caniuse.com.

If you're targeting evergreen browsers you can already write the latest Javascript, and would only need Babel for something like JSX. All those browsers have async/await, ES6 modules (aka import), arrow functions, and destructuring.

To separate your written code from what is actually deployed is much more of a con than a pro. I'd rather not need a compilation step if possible. My time is valuable. Babel and Webpack are slow as a dog for non-toy projects.

Manually importing shims are a thing of the past when you're targeting evergreen browsers. You can use something like Polyfill.io for edge cases, and it will cover the small number of

CSS prefixes have nothing to do with Babel or Webpack, they're normally handled by tools like PostCSS. Nothing to do with Javascript. Static Analysis is normally handled by tools like ESLint that can use Babel but can be completely decoupled from the compilation step. Or Typescript, which actually brings a lot to the table compared to Babel.

Again, this might be hard: maybe you need to handle customers with IE11. But to not need Babel is something we should aim for.

I honestly can't wait for Babel to be 100% unnecessary and to die. It is valuable in a world where Internet Explorer exists, but there is zero advantage in using it when it's unnecessary.

I have been working with various SPA frameworks for about 5 years now, from the bad old days of AngularJS to mostly React nowadays.

Your comment about 1990 seriously rubs me the wrong way because it seems to imply React et al. actually does something to address the points you make. It does not, at all. You still need to test your code on every viewport you support. And now you have to deal with an insane build process that rivals some C++ projects while doing it.

And there is absolutely an objective argument that staying close to the web platform is preferable than 200 layers of leaky abstraction and a 10MB uncompressed bundle of transpiled JS. The language itself is pretty okay in 2020, certainly not worse than anything else from the TIOBE top 10. I would definitely say writing a bunch of plain JavaScript is all that’s needed for most applications out there. If you can’t manage that without a frontend framework, the problem is certainly not with the platform or language.

Yes you still have to test your app on different platforms and browsers, but the point of the build process is that they make them work on those various platforms, whereas before you would have to manually fix those failed tests and hack in fixes for obscure conditions. That's what frameworks and libraries are for. They've abstracted away things so you can focus on higher level things. Tests are always going to be required, even if your framework and libraries are perfect.

We don't need to stay close to the platform because abstractions allow for more advanced applications. That's why most web apps don't use C, and should never use C, because 99% of the coding work is higher level tasks that don't need the bare-metal performance optimizations.

> than say writing your code with ES Next or React

Say again? One is a framework, the other is an updated version of the language that can be transpiled to ES3 for (non-mathematically) provably identical results.

React isn't a framework. It's a library for writing functional components which can, at the moment, target native mobile components and HTML components so that you are not writing the components manually in a platform specific way.

> chances are there’s at least one front-end hipster around who will mock you as outdated

Well, React isn't something very 'shiny' anymore, for shiny things you would look at things like svelte or wasm.

React is older than jQuery's age when React was first born now.

WASM is entirely different from Svelte/React. WASM is a compilation target for native-code languages, and can't interact with the DOM except through JS shims.

> Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice.

This is a huge assumption. For example, I don't think any web dev enjoys wrangling with CSS positioning or workarounds because they want to be "rewarded by keeping up".

> Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing React libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done.

I don't know what your feature is. But any decent web dev today has to think of multiple angles that are not present in non-frontend development

- Responsiveness

- Browser support

- Accessibility

- Internationalization

That is in addition to testing, error logging, analytics, etc. We haven't even gone to the business logic yet.

Many people underestimate how much work a good web app entails

1) CSS works great, and while it continues to incrementally improve, has been fairly stable since its introduction. What I meant about "solutions" that don't work well are things like React state which has gone from "not a thing" to "redux" to "redux is an antipattern" to "redux is moot because now graphql" which oh BTW means you now need a whole new API? Ok. That framework churn is because those problems are actually difficult, and to date there's no "one true way" that is pretty straightforward and covers 90% of cases pretty well. By contrast, things like "how to set up a webserver that handles HTTP requests" are easier and already well-solved in every serious language, and thus not so subject to the same degree of churn.

2) All those concerns were present in the project I worked with said developer on, and were easy to handle with the basic tools of the browser.

Yeah I'm also laughing.

The senior engineer could have just as easily wrote worse code.

Just some weird obscure Javascript floating around editing the DOM directly causing untraceable errors in the future.

React helps with lots of things;

- Testability

- Readability

- Less side effects

- Documentation

- Rendering

- Error Protection

I could rattle on forever, might be time to write a blog post, gets a bit tiring reading the HN users who think we've just made the frontend complex for fun.

Frontend development is HARD, factors include;

- Plethora of device models/sizes

- Latency / Async / Fetching (data)

- Rendering speeds based off how you coded it

- State Management / Cache Freshness / LocalStorage

- Server Side Rendering

- Code Bundling (js and css)

- Design / Transitions / UX / UI

etc

Now why is all this important? Because to be a competitive app, it simply has to be sexy and slick.

If I could do that with one style tag and one script tag, I would.

> If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most.

It sounds like you're reinforcing this divide by classifying people who have a different opinion to you as "hipsters."

They label your technology choice as outdated, and you label them as hipsters. You become the thing you fight.

The problem with using some shiny new library/software/app/technology is, that it might dissapear in a year. The developers will move on to new companies, and work with some new shiny tech, and all your codebase will be useless due to a unmaintained library and no new people (developers) who know how to use it.

I wanted to make an example that it was like starting work at a company, and seeing that they're still using phpBB (but with a 1 year old library)... but it seems phpBB is still being developed...

> but it seems phpBB is still being developed

Doesn't that underline your point though?

Does library-support-wise (well, software-wise). Trying to find a developer with phpbb experience now, would be a totally different story.

Haha, that's fair. It would be more fair to say "advocates" or something like that. My bad.

> I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting.

Yes. And its important to remember that React is heavily marketed to developers by Facebook, just as MS does with Typescript, and Google does with Angular. The point of this marketing is to create a feeling that these technologies are "safe" and "standard". Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising.

That said, there are a few major functionality gaps in native JS that leave the door open for front end libs. The biggest one is some kind of sane support for templating, and the second big one is that async is too complicated (people who actually understand callbacks and Promises often dont realize how many devs dont understand them). Facebook, via React, provides solutions to these problems, and leverages them to get users to buy into the React ecosystem.

If somebody could show how to make a component in JS that could be included in a page as an HTML tag, and could talk to other components on the page then the need for React would just evaporate.

> Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising.

Of course. Most devshops don't have the manpower that FB/Google/MS have. You don't really have months to tinker around and create some new framework and then another 2x months to fix bugs and add new features to cover some edge cases. So you pick whatever is backed by a lot of manpower as it has the highest chance of being usable even 3 years from now.

Having done some old Skool desktop dev recently I can't shake the feeling that modern web development is mostly just trying to reinvent wheels that have mostly been sorted for 20+ years.

I guess it's understandable though, the web was never really designed with its current use-case in mind.

People do so love forcing square pegs into round holes though.

>“wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.”

Wow. These two sentences completely capture modern day Web Development, Javascript as assembly.

>I think there’s a lot of that in front end world today.

In modern Web development, ( and in possibly all area of software development ), instead of making things simpler ( not easier ), it seems we have been building premature abstraction after abstraction.

FWIW, the first conference where I heard speakers talk about learning JavaScript first before leaning on a framework, was jQuery 2008.

Frameworks are not inherently premature abstractions, but can be used that way.

It's always good advice to start with the conceptually simplest tech you can get away with.

About your junior dev it might also be the way he was taught React.

I'm also a junior and the way I was introduced to React was by teaching me enough JS that I could theoretically write React (with a bunch of research).

One of the things I've noticed among other junior engineers (including myself) is tutorial driven development. Through a mixture of inexperience, laziness, and self doubt it can be easier to find someone else who's implemented something and just use theirs. Rather then thinking about a complex problem and naively coding up a solution finding someone else's hopefully battle tested code.

An example of this is how I used to make JS based games. I essentially used an array to toggle classes on a grid of divs divs in the style of an LCD screen. I hadn't heard of html's canvas element. My solution worked but I don't think anyone would think it's a particularly good one. If I had found someone's snake game and saw they used canvas I could have saved myself some headache.

I find assumptions like "people are lying about liking it" for any popular thing are always wrong.

At work, I've been forced to use angular. It's just awfully complicated, breaks subtly, changes (not improves) constantly and has sucked in hundreds of developer hours that could have been better utilized.

I was appalled at the state of things in front end development till I realized my current project uses kubernetes (implies docker, helm), spring for implementing REST endpoints and ansible for deployments on the back end.

Now things are really fucked.

On both ends.

I disagree. Do you remember the days when J2EE was the hot stuff? Popularity comes and goes and is not necessarily correlated with whether something is a good idea or not.

Over the last 15-20 years or so as a web development shop we've gone through Prototype, Jquery, Backbone, Angular, Vue and now React for JS frameworks. We've mostly settled on React lately. Our experience is however that it is wildly overused where it is not needed and adds significant time to development. Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue) and take several weeks. We've seen this in several projects while working alongside experienced developers.

We do use React extensively and we find the sweet spot is in smaller components on a page, or highly interactive sections, things without lots of shared state, but it often seems like web developers have one hammer and it is not the right one.

> Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue)

This sounds like bad system design rather than a problem of React.

In general, I find React hate massively overblown. The problem seems mostly to be that everyone is using it, and "everyone" in the case of frontend devs is all over the place in terms of how they got there, what they know to do, and what they know not to do. If you're not careful, all of the JS ecosystem can give you a lot of rope to hang yourself with. The relative accessibility of webdev is a blessing and a curse.

This sounds a lot like the days in web dev before Ruby on Rails came along.

When they (and django) took the web dev world by storm they were prescriptive and told developers how to do something, not just giving them a bunch of tools where you had to build your own app lifecycle, usually massively over-engineered. A whole load of mental overhead disappeared.

Just before Rails, etc. everyone was going on about Factories and the Gang of Four and people were building crazy startup patterns on their webapps using Singletons.

> J2EE was the hot stuff

Whenever everybody except me seems to love something and I just don’t get it, I remember CORBA...

Ah, the heady days back when everybody bought books written by Don Box which only Don Box could understand!

(Edit: yeah, of course, that was DCOM not CORBA, but anyway, that's where I flashed back to. :-) )

I really like Svelte because of what you are describing. It feels almost like writing normal JS/CSS/Html but you get access to some QoL features that make writing JS easier

It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.

As a user and developer myself, that's the sort of selfish attitude that really really angers your users.

I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.

I've worked on "complex"[1] websites in PHP, all static/server-side rendered; zero need of JS, near instant load times, ultra low bandwidth and server CPU utilisation, and don't even need to think about "browser support" because it'll be usable with anything from the past two decades.

[1] complexity in terms of features and usefulness, not in terms of how much code and resources it needs. Unfortunately a lot of developers seem to think complexity as in the latter is a good thing.

> As a user and developer myself, that's the sort of selfish attitude that really really angers your users.

A user is only unhappy if they withhold some money over it.

Right. If your product is paid for in eyeballs, then by the time users have perceived your low quality, they've already paid.

This (and related phenomenon with subscriptions) is arguably a big drive for the software becoming increasingly infantilized; shiny toys instead of useful tools.

And they do, even if it's not a conscious decision. Most large scale experiments see bounce rate increase and revenue decrease with page load time. More load time because "it's easier to develop this way and it saves developer time, which is expensive" means more bounces and less sales.

Of course, that only matters at scale. If your site never takes off, optimizing for user experience (instead of developer experience) wouldn't have paid off. On the other hand, maybe putting your users second lowers the chance of it being well received.

A user is only unhappy if they withhold some money over it.

Yes and no. If you are selling to the CFO on the golf course, then you get paid and all the actual users are unhappy. This is the entire ERP industry.

As others said, user != customer. A big chunk of software (perhaps the majority) is bought by someone other than the end-user. Think workplace, or all the OEM garbage that ships with your phone.

On top of that, on the mass market, customers don't have a meanigful choice. They can't signal desires in the entirety of concept space; they choose out of what's available on the market. Which means the choice really lies with the vendors.

What an absolutely sociopathic attitude

zero need of JS

XHR was invented because without it, Microsoft couldn't make a web-based email client that behaved the way users expected an email client to behave. 20 years ago. I'm not sure you can reasonably claim this stuff is not also strongly driven by the expectations of users and and the desire to meet those expectations.

I'd like to know which users desired a web-based e-mail client 20 years ago. It is my impression that this kind of software is very much push, not pull - i.e. the idea comes from the vendor, not from customers expressing a demand. Which is not a bad thing in itself (a big part of progress is speculative creation); I just don't like the unspoken assumption that companies do things because customers want them to, it's not always true (almost never in B2C).

I'd like to know which users desired a web-based e-mail client 20 years ago.

Millions of them, by then.

https://en.wikipedia.org/wiki/Outlook.com#History

See also Rocketmail.

20 years ago, the market for web-based email was well-established, not some push experiment.

Many of us only used it because it was free/available for everyone and we were students or stuck in another situation were it was the only option. If there was both a webmail interface and imap we chose imap.

Some of us still to this day prefer imap/jmap/exchange if the server support it in a meaningful way.

those crazy users, not wanting to install, configure and update software, download their emails and make sure their backups work, and just get on with actually reading their emails on whatever computer they wanted

Those crazy users who then cry, "what do you mean I've lost 10 years of e-mails forever, becuase my daugher commented with an emoji on a YouTube livestream, and Google decided to go nuclear everything associated with that account?".

Cloud services aren't more reliable than owning your data. They're just unreliable in a different way. You need backups anyway.

That happens less often than people's computers dying.

Which emoji did she use?

The green one.

I'm of course referring to the Markiplier drama of last year, where a streamer asked people to vote on his stream by typing in red/green emojis. This resulted in hundreds of people losing their Google accounts due to an oversensitive spam filter. The matter fortunately got sorted out (somewhat, not all accounts were unbanned), but essentially only because it involved a fairly well-known youtuber.

https://www.engadget.com/2019-11-10-youtube-reinstates-banne...?

And random automated bans (which happen on all big social networks) are only one fairly common failure mode of cloud services. Smaller services shut down or get acquired, taking your data with them, or they just shutter the products you depended on (and even if you can export data, there often isn't anything you can import that data back into). Governments may randomly make whole populations lose access to service (c.f. Adobe's Creative Suite and trade sanctions on Venezuela, earlier this year). And, of course, no Internet access = no access to service = no access to data.

In general, owning your data makes you vulnerable to physical world problems - floods, fires, etc. Using cloud services makes you vulnerable to relationships between you and third parties, as well as between these third parties themselves.

Server side email has the failure mode of the company going broke or banning you. Client side email has failure modes like destruction of device (house fire, flood, other accidents) or even just obsoleting of OS/app. Neither is inherently superior to the other.

In the particular case of the emoji ban, the problem is that the FTC should never have allowed one company to control search AND email AND school document sharing AND maps/reviews AND video AND mobile phones, etc. If you don't use Google for your email, there's no danger of Google banning you from it. :-) More seriously, Google (and Amazon and Facebook and Microsoft+Github) needs to be broken up to protect consumers from one company having a chokehold on their digital lives.

and don't even need to think about "browser support" because it'll be usable with anything from the past two decades

Not including a patchy or high latency internet connection though, right?

I'd say especially including these; plain, old, JS-independent, server-rendered sites handle these conditions much better than modern SPAs.

I don't agree. A classic PHP-as-it-was-used-15-years-ago site either loads or fails for every user request. That isn't good enough any more. An SPA either loads or fails for the first request, but then they do a lot of things that can mitigate a patchy internet connection - prefetching content, offline mode, bundling things to reduce the number requests, etc. A server-side rendered app doesn't take advantage of those optimisations, although things like rel="prefetch" are starting to get used more which helps a lot.

Like the article suggests, there's definitely some middle ground where enough of the site is loaded on the first request for it to work, and then more things can happen in the background to make subsequent interactions faster and more reliable. That isn't a pure SPA and it isn't a pure SSR site either.

Very few SPAs give proper user feedback. There could be any number of silent errors in the background.

It's even evident for relatively basic things such as infinite scroll. Users on sketchy connections won't even see all the items in a web store if their mobile connection is sketchy enough, and they will never even know it.

There are some real costs here. Had anyone seriously A/B tested these things they wouldn't be so widespread.

Very few SPAs give proper user feedback. There could be any number of silent errors in the background.

Badly built apps that ignore errors and don't work well for users are certainly not limited to SPAs, and blaming SPA tech for that seems a bit unreasonable.

For "classical" websites, it was not possible to screw it up. The feeback was always there - clear, unmistakable, universal across sites. Boom, "No Internet", site's gone. Press "back" to get the previous state and click again/resubmit later. And it was nice that you could actually do that - use the "back" button to revert to the last correct state even without an Internet connection. Can't do that with almost any SPA these days.

I suppose it just boils down to the fact that with more freedom comes more freedom to fuck things up. But when you see an industry systematically fucking things up, and being driven by economic incentives that encourage fucking things up, one has to wonder whether some of those freedoms should be taken away.

The feeback was always there - clear, unmistakable, universal across sites.

It wasn't clear for lots of users. There were common stories of people getting a connection error and refreshing a page only to find their order on an ecommerce site had been taken twice, or that a comment they'd made had been submitted a second time, or that a request to delete something had actually worked but the second request threw up an error because it couldn't be deleted again so it looked like it had failed. These aren't so much of an issue today because browsers warn about form resubmission, but let's not forget that server-side rendered websites in the past were absolutely riddled with UX problems and bugs.

That's not a defence of SPAs, far too many still get the basics wrong, but if you believe it was better when devs made "classical" sites I think there's some decidedly rose-tinted nostalgia going on.

Yes. And want to add that links are not links anymore.. They look like links but cannot be copied..

Perhaps the SPA pattern, for all the justifications from developers (and yes, of course there are genuine cases where it's a good fit) is really an outcome of Conway's Law[1] in action. In a large enough organization, you corral your dev teams into isolated, specialist "backend" and "frontend" groups which end up communicating largely through decoupled APIs. As with microservices, it's not really about whether this is the most efficient and user-friendly approach to delivering useful apps to the end users, but how much this architecture mirrors your company's org chart.

[1] https://en.wikipedia.org/wiki/Conway's_law

> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.

I have a 20 year history of building websites, and a recent three year stint of building front-end applications professionally using mostly React, which I'm now proficient in. I also normally use a strict whitelisting policy for Javascript using NoScript. If it's not a tool that depends on it that I really want to use, or if I find no obvious reason for it to be using Javascript, websites don't get added to the whitelist.

Javascript, as far as I'm concerned, is a wide open vector for an ongoing large scale attack on my privacy. Not only that, but I also have to pay for it in battery life and memory. The occasional blog built in React without a static fallback will usually go unread on my end, and no one is losing sleep over it.

I also think that you are fundamentally missing the point of the article if you your experiences building native applications vs building web applications is supposed to offer a counterargument. It's a false dichotomy in this case; the blog was never a native desktop app. The marketing site was never a native desktop app. They're collections of documents and I have no idea how anyone could come to believe that arranging that using a framework designed to facilitate reactive web applications is easier than just delivering the documents using technology designed to do so.

So, this is the kind of thing I make for my employer. But guess what? I can still do things the way I did them back when I learned Rails over a decade ago: HTML templates and a very small amount of JS to tell the server to re-render them when the user needs it.

What many of us really need is not fully dynamic SPA-type things, we just need some dynamic forms and some page elements that dynamically respond to user input. This is all stuff that you can also do without JS, if you design your site to handle that use case! Rails still makes it easy to make this kind of site with plain JS (or a lightweight framework like Stimulus, or jquery if you really want).

But all that's to say I fully realize why and how JS is useful... and that's actually why I disable most JS by default in uBlock Origin.

The problem isn't the existence of JS, it's the fact that massive tools like React become the hammer, and everything starts to look like a nail. There's no reason for the sites I am usually interested in visiting, which are either content hosting sites (no JS needed at all) or sites like my own (that could be enhanced with JS but still functional without it) to pull in so much code unrelated to the primary function of the site.

I always wondered if we take shortcuts because we have to re-write everything every 14 months or if we have to re-write everything every 14 months because of all the shortcuts we take.

Why not both?

Both is good.

Why not all three? We take a shortcut by rewriting everything every 14 months, because this way we don't have to learn anything long-term.

I put food on the table, and I do more work in Django than I do in SPA's. In fact, one of the complaints I read about from management is that Django devs cost more than JS devs (don't know if that's true, just saying it's a management concern).

But I think the "React everywhere" error, is more or less the same as the "one language for everything" error, the "everything should be Windows" error, and many other cases of wanting to use only one technology and have it work for all cases.

I haven't seen a bootcamp teaching Django recently, so I can see where that might be true. The cheap people are overwhelmingly JS.

I've been working in the tech industry for 20 years and from my experience rarely do "cheap developers" ever actually seem to work out costing less in anything other than the very short term.

The cheaper the developer, the shorter the period where they cost less.

I have been developing all sorts of native and Web applications for a couple of decades now, and SPAs is something I avoid as much as possible.

And yes, I also implemented interactive desktop like applications as Web applications.

Server side rendering frameworks, with support for components and just enough JavaScript go a very long way, and best of all, they are faster than SPAs in every kind of device that customers might have.

Speaking as a user, I generally prefer non-SPA web apps as well. They're much more predictable.

Server-side rendering + Turbolinks [1] + jQuery-or-equivalent gives you an SPA experience anyway, without the client-side bloat. With judicious use of markup, it can be massively more responsive.

[1] - https://github.com/turbolinks/turbolinks

There is also Stimulus Reflex [1] which is like a Turbo Charged Turbolinks. The idea is from Elixir / Phoenix 's LiveView.

I think Laravel has something similar as well. These are the three big groups that are actively frighting the SPA trend.

[1] https://github.com/hopsoft/stimulus_reflex

See also unpoly and intercooler, which are more powerful and intended for more fine-grained usage.

https://unpoly.com/

https://intercoolerjs.org/

What frameworks do you use?

for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time

The premise of the article is that they are not easier to work with and do not save time in most situations. I agree.

Most websites are fundamentally documents, even those that think of themselves as apps. You could even build gmail quite easily as a document based app with some limited use of fetch() or WebSockets to get the data you need, though it's one of the few applications where a less document based approach might help.

React and other js frameworks are a huge amount of overhead for very little gain if you see the web this way. Your about page is not improved by using react.

>Your about page is not improved by using react.

Well...fortunately people don't use React for making About pages.

These examples of why not to use React in these comments are silly, people use them for web apps 95% of the time.

I gave an example of a prominent web app I don't think needs a js framework - most web apps don't IMO as the web correctly centres the experience on documents. Games would be the obvious exception where an immersive app experience is warranted and there are no documents as such, almost every other app works with data organised into stores of documents (i.e. in gmail every email is a document and deserves its own URL IMO).

> fortunately people don't use React for making About pages.

No, About pages are out of fashion and people don't do them in high numbers anymore. But they do use react to display news articles, web shops, and all kind of text.

This doesn't match my experience at all. I've seen many, many places where a bleeding-edge React stack was deployed to serve what was 100% static content.

Gmail has a HTML app which requires a reload whenever you click stuff and still manages to be faster than the JS app.

> for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.

Our salaries are expensive because, presumably, we're being paid to make something that serves the users. So anything that benefits us at the expense of the people we're serving should be rejected. How self-centered can we be?

Salaries are high because the supply of (skilled) software developers is low.

Do they really save us time?

What about if you used a mature back end framework such a Rails, Django or Laravel for 95% of your app. And then vue or react for the 5% that rally needs it? Would this be more or less productive?

The author wasn't claiming that react and co are bad for development. Rather that they are great for particular use cases and inferior to other options for other use cases.

I think that's undeniably true.

You hinted at something that to me is a key point: A lot of web apps are built by teams at big organizations.

In that environment trends are compelling because they keep everyone on the same page. It's easier to onboard people, it's easier to hand things off, easier to maintain going forward.

That makes a strong case for using the latest frameworks even when they aren't the best solution for a particular problem but it doesn't make it right from an efficiency or user experience perspective. There are a lot of reasons why arbitrary complexity is expensive. One example: what happens when your page load times start to rise above the threshold where it starts hurting organic traffic? You probably don't scrap everything and start over, instead you hack solutions on top of what you already have. Now you've lost money in both free traffic, one time development costs and increased maintenance costs going forward.

Again it's not that react is bad, and either way people aren't going to stop using it for things it's not ideal for until another trend replaces or absorbs it. But I think there's value in seeing things for what they are, and having conversations about it.

> they're easier to work with and they save us time.

I have never seen evidence of this.

Its a lie developers frequently mention because it sounds so thrilling to say. Approximately how much time does it save you in estimated hours? Its like asking for a helicopter to take me to work, because supposedly its faster. I'm simply assuming its faster without looking at any numbers or finances.

I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more.

It's certainly faster to use jQuery to change a CSS attribute than it is to setup a React project but what's not considered in that calculation is maintaining the state of that attribute or making changes to the logic in the future. Especially on code you didn't write originally.

If all you have to do is validate a form, sure, use jQuery if that's your cup of tea. But I would still rather use something like React because I know I'm less likely to write buggy code or introduce a regression in the future. To each their own though.

> I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more.

Its a lie so long as the number sounds completely invented. I suspect the number comes from somewhere, maybe a vague memory, or a grossly unqualified estimation, but it isn't based on anything. It is something superficial that primarily serves as self reassurance.

When you have never had to bill people for your time, or you have never been to a board meeting, or never briefed senior executives this kind of fantasy is perfectly fine. The moment there is money on the table you are expected to do more than invent fictional numbers, or you will be replaced by somebody who can.

I have worked as a consultant for 5 years where I billed people for my time, and paid at least $200k to other contractors in that period for help on projects; it's not made up and it is based on my experience tracking my own time and productivity, and that of my subcontractors.

I do think it's more abstract and harder to justify properly when someone is a well paid salaried employee for a FAANG. But that's not me.

> It's saved me hundreds of hours, if not more.

How did you come up with that? You tracked the time it took to complete the project with and without React and diffed it?

The same way anyone would come up with a time estimate if asked how long it would take to mow the lawn with a pair of scissors or lawnmower -- experience and extrapolation.

Fair enough on the experience and extrapolation. But I would argue your analogy is a bit off. It's undeniable that a lawnmower is faster than scissors. I don't think that's the case between React and no React.

A closer analogy would be a comparison between different models of lawnmower or between a lawnmower and a different kind of mechanical grass cutting device. In which case, it seems you would need to log time to see if you've saved time using one over the other.

I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on:

> There are a lot of problems for which I can't see any concrete benefit to using React. Those are things like blogs, shopping-cart websites, mostly-CRUD-and-forms websites.

And the thing is, this still comprises an awful lot of the web. If I can produce a web site with Lektor or Hugo or some other sophisticated static site builder, it's hard to see how React is going to bring anything to the table that either makes that web site easier for me to maintain or provides a better experience for that web site's users. If you introduce some dynamic elements to the web site -- well, just what are those elements? Ad banners? A simple image carousel?

And I think that's really the argument being made here -- use the right tool for the right job. If all you have is React, everything look likes like an SPA, but that doesn't mean that it is.

Serious question:

Is this really a problem with web developers? Or is it with product managers who demand SPA like behavior?

I suspect a little of both. Developers do like to play with cool new technologies, and product managers do like to see how spiffy they can make their products.

Having said that, though, I do not think it's a universal truth that all web sites must expand to fill all available functionality, which seems to be implicit in a lot of arguments here and in the highest-rated rebuttal to me.

For all the talk of "resume driven development" I think most developers - unless they are playing around with side projects and non-essential experimental stuff - prefer to do the simplest thing that will get the job done and keep the site maintainable, and the reason they resort to more complex and advanced frontend solutions is due to onerous requirements from stakeholders for more and more intricate and complex UI. It's another question entirely whether this more intricate and complex UI actually delivers business value or provides a better experience for the end users, but that question is above the developers' pay grade.

Your argument hinges on the assumption that the products have a final conclusion. I can start building a product in hugo, say - I’m just displaying information in charts and generating predefined reports. Time passes more users are added and now I need to identify each users reports. Now I need a server and at this stage I can get away with SSR. More time, more organizations, more complexity. All of this can still be handled by SSR. The real kicker happens when people start demanding the ability to generate their own reports by supplying their parameters. They want the ability to write their own queries. They want WYSIWYG building blocks. They want to define their own templates.

Very quickly we are in a territory well done with react than with Hugo.

Most products, especially if it’s a company, are like this. Products are constantly evolving. Whether products should be constantly evolving is a different discussion and tools are only a small part of that discussion.

I would say rather that my argument hinges on the assumption that the majority of web sites in the world are not the primary products of the companies that produce them. I would argue, in fact, that you're looking at web sites from a very particular lens. An absolutely valid lens, to be sure, but a particular one. nonetheless.

If you're an SaaS (or PaaS or whatever-aaS) company, then your web site is literally the core of your being. You're building an application that happens to run in the browser, so you want to build it like an applications! But a lot of companies aren't doing that. Hacker News, the web site we're on right now, doesn't need to be an SPA (and isn't). Does any CMS need to be designed like one? I'd never give a blanket "no," but I'd sure never give a blanket "yes." How about a company blog? A simple storefront? A customer-facing restaurant site?

Also, don't get hung up on my particular example of a static web site -- I wasn't arguing that all sites can be done with Hugo. :) But you could absolutely design a modern, maintainable CMS that lets internal customers generate their own reports, write their own queries, and define their own templates using Rails or Django or Laravel as the back end -- and that seemed to me to be what the original article was really trying to get at. We've gotten so hooked on "JavaScript is everything everywhere" that we may not always be considering whether a given project really fits that paradigm. "This project doesn't fit it now, but it might in the future" is nearly always a technically correct response -- but "what you're building couldn't possibly scale up to unicorn level" is nearly always a technically correct response, too.

My problem is that developers seem to be generally afraid of the technology and employers allow fragile products due to a talent deficit.

https://news.ycombinator.com/item?id=23137367

For me the real subject would be "the death of templates in favor of decorator based objects", which could have been predicted by the GoF that recommended the decorator pattern for GUIs, and makes great sense for the tag-based language that HTML is.

Template languages often impose language limitations to make easier for HTML/CSS coders to work with, without breaking the backend code, isolating their codebase from the backend codebase.

These limitations make them less composable and reusable than functions or objects, and obviously show more drawbacks than advantages for one-man-development, and reuse across projects.

My wild guess is that if we replace templates by components on the server side, we will see less React & friends, for me they mainly demonstrate the clear win of component based patterns against template spagetti.

Seems we are going full circle: the Python ecosystem had component-based template languages such as ZPT (Zope Page Templates) and Genshi. The former I think is still used with the Pyramid framework, but mostly these approaches have been replaced by Django/Jinja2 text-based templates. So in Jinja2 or Django you would have something like:

    <h1>{{ page_title }}</h1>

But in ZPT:

    <h1 tal:content="context/title">Sample Page Title</h1>

If you squint hard enough this doesn't look a million miles different from React or Vue.

This approach largely fell out of favor, but I don't know whether that was just due to Django's popularity vs other Python frameworks or Django template language just being more flexible and approachable, especially for front-end developers (and you could use it for any kind of text based content, such as emails).

It was that the template engine got a Turing complete text declaration language, while the tag based one had to rely on hacks that didn't scale very well. Also, as you said, because the template engine were useful for any kind of data, while the tag one carries a lot of opinions about the resulting text.

More flexible and conceptually simpler tend to win over time, as people try to learn less things.

I’ve written one or two web applications to put food on the table. I’ve found that unless additional complexity comes with an orders of magnitude benefit, it’s usually not worth it.

Seems like the author had a few well articulated and valid concerns, and probably likes the taste of food too.

Anyone who cares about privacy allows minimal JS etc. Especially if they're using Tor. And given Tor's high latency and low bandwidth, sites that require lots of client-server dialogue, and/or push lots of data, are a pain to use.

And yes, I've never built complex websites. Just static HTML. Because mostly they've been Tor onion sites, and that's what works best for them.

Proof that hardly anyone cares about privacy

Yeah, that does seem pretty clear. So it goes.

Most people don't because it never impacts them in a visible or tangible way.

You are contradicting yourself by opening with a claim of time savings and ease of use followed by admitting that the solution is largely more complex. More complex work does not save time in aggregate and is not easier to use.

The solution is not more complex to the developer or user, it's more complex to the browser, which hardly ever complains when you make it work harder :-)

Users could complain when someone makes their browsers work harder. Looking around the net, they mostly don't. I don't know. The only time I developed a serious full SPA, I intended to use it myself on a $50 phone, so I actually kept complaining to myself until it started loading in reasonable time and working instantly after that.

Users complain to Microsoft for making the OS slow or complain to their internet provider.

But that's a one-time cost. Spring Boot is stupid complicated, too, but once you know it you know it, and getting your next project spun up is a lot faster.

I'd rather maintain a React app because it will be at least somewhat familiar than try to fight my way through someone's home-grown rendering framework that can't even be Googled.

It’s all about where the complexity lives. As long as your client code needs aren’t too complicated then you lose time by using React^. But once you cross a threshold you end up inventing some subset of React^^ and hope that it’s overall less effort to maintain than using React itself.

^ maybe not if your dev team is used to using React but nonetheless.

^^ React could be any of the popular frameworks. They all solve similar problems.

> You are contradicting yourself by opening with a claim of time savings and ease of use followed by admitting that the solution is largely more complex

It's not a contradiction. C# is "largely more complex" than C, that doesn't mean C is inherently more productive than C#.

The calculator on my desk is a (relatively) complex set of circuitry but it sure saves me a lot of time when I do my taxes

I wonder, when did this shift happen wrt the Web: we only care about how it is easy for the developers, not for the users. Despite all the talk about UX a lot of the momentum is still in the wrong direction.

I've been writing working with the web close to 25 years now. It is amusing to see it come the full circle. How hard it is to understand, that you don't need react for some blog, or anything which is not even remotely an app?

> when did this shift happen wrt the Web: we only care about how it is easy for the developers, not for the users

Are you talking about the same web that ditched XHTML because you had to validate your site before publishing? And had those "works better on Mozaic in a 420x340 resolution" warnings?

Does wondering that help you come to terms with the idea that you're creating things that range between "not the best user experience" to "thoroughly unpleasant to use"?

Personally I have been building websites (anything between sysadmin to backend and frontend) for 20 years, and my experience of the JS ecosystem is that it's utterly unpleasant to work with and in no-way better than other web technologies, but then maybe that's a delusion brought on by not eating enough.

> It outweighs all the end-user-facing cons by a lot

Well, I got so sick of crappy JS "websites" spinning my CPU fans that I installed the NoScript plugin, and now the web is a far nicer place to be. My browser is more stable and faster, uses less memory, and doesn't hog my CPU as much.

> client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.

As a developer that started off with client applications going on two decades, this is the attitude I despise most about the modern web, the frameworks that power it, and the developers building on it.

Developers serve the user. The user must always be the primary beneficiary. Forgetting that is why we have this bloat, terribly frustration UIs, inconsistent UX, poor accessibility, and everything else that plagues software development today.

Developers serve their clients and employers. In the best situations, serving the user aligns with that.

> sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.

I've been developing single page applications, mostly, for six years; and I generally don't enable JavaScript on a website unless it is otherwise broken and I actually care to use it. I'm developing a website right now that has some persistent elements (video call, interactive charts) that don't play well with server side rendering. For the elements that are fine without it I prefer to render them on the server when there are enough of them, but ultimately there are limits.

You suggest React is at once both "easier to work with"; and "largely more complex" and "gatekeeping" (harder to learn?). Aren't those opposites?

Check out the sibling comments. Complex does not mean hard to use. My car is complex, but it's pretty easy to get a driver's license.

Gatekeeping refers to making it seem like it's too hard to get into and therefore not worth trying for beginners/non-technical folk.

So by "gatekeeping", you mean that you think it just seems harder to get into, but actually isn't harder to get into?

What do you think makes it falsely seem harder to get into for beginners, when it isn't really?

Maybe the docs new devs find, focus on fancy complicated libraries, instead of simple plain html or just a bit js

Writing such "more complicated" blog posts makes one look more talented?

I don't know

> client-side technologies like React have a pretty clear advantage... they're easier to work with and they save us time.

> it worries me that they create a sort of gatekeeping effect on the industry

Aren't these two quotes contradicting one another? If frontend frameworks make frontend developers' job easier, then how can they be regarded as contributing to gatekeeping? If it had not been for them, frontend development job would have been harder and would have required more expertise.

I’ve never used React, but I spent years fighting with Angular, and it seemed like all downside with no upside - I kept expecting the upside to become apparent eventually, but it never materialized... it just made site development take longer, crash more mysteriously, and run slower. Is React really “better” than Angular? That is, does it actually do anything?

In my opinion, yes.

Angular's model is based on "two-way data binding", which was also the paradigm used by Backbone and other popular JS frameworks of a ~decade ago. This means that any user interaction with your app directly causes some JavaScript value to change, potentially triggering side-effects. But you can also cause the same value to change in your business logic code, in response to some other event or change. Components maintain a lot of data internally, so your job as a developer is largely about making sure that these components stay in sync with each other, and with whatever non-component-oriented data you have.

This gets messy very quickly. Where is your data? What things can cause your data to change? What happens if you want to change a data schema, or introduce new fields, new components? Angular tries to solve this problem with a fairly complex architecture[1] which promises that all of this can be OK if you follow the rules.

The problem is that this architecture is so complex that most people can't follow it well: there are modules, components, views, directives, services, dependency injection containers, service metadata, bindings, a router, and events. That's ten concepts, and you can't build very much in Angular without knowing what those concepts are and how they relate to each other (and if you can build it without knowing these things, then you didn't need Angular).

React is much simpler: there is state, and there are views. State can be global or component-local, and I would suggest ignoring component-local state unless you can't avoid it. Views render whatever state is passed to them. State can be updated by events. This is the same basic loop that is recognisable in desktop apps, games, in fact most interactive software. There's no "two-way binding" because views render based on state, but can't modify it directly. This is a lot easier to understand and to debug.

React might be less "batteries included" than Angular, but Angular requires such an enormous battery pack because it is trying to solve problems in an insanely complicated way.

[1] https://angular.io/guide/architecture

It sounds like excuses companies make when they pollute the or exploit their employees. Solution for them to stop is to level the playing field by law. I think that one day the same will happen with software, and we'll all be sorry.

Your argument, ignoring every point they make, is that theyre contrarian and have never had to make a real website before.

And..

And youre afraid of a gatekeeping effect?

Did you even read the article or are you just here to make sure the gate's locked?

> It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.

What a user-hostile attitude

>for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time.

Not exactly making a value judgement about this, but imagine for a moment any other engineering discipline saying this:

Yeah, I kinda made this road 20x less efficient that I could have, but I didn't want to bother with the nitty gritty details.

Yeah I'm using trash materials to make this building, but I just didn't want the headache of thinking too much about it.

You would be shocked to learn how many roads and buildings are actually built like this. Except that in the case of roads and houses, people die sometimes as a consequence.

Reply on news.ycombinator.com