Hacker News new | past | comments | ask | show | jobs | submit login
Second-Guessing the Modern Web (macwright.org)
721 points by erict15 17 days ago | hide | past | web | favorite | 453 comments



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.


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.


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


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.


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.


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"


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


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.


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.


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.


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.


> 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.


> 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.


>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.


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!


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.


> 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.


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)


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.


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.


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.


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."


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.


> 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.


>“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.


> 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


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.


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.


> 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.


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.


> 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.


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



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.


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


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 find assumptions like "people are lying about liking it" for any popular thing are always wrong.


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.


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.


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


> 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.


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.


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.


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.


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.


What an absolutely sociopathic attitude


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..


> 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.


[flagged]


If you mean to equate wearing tinfoil hats with employing a blacklist-by-default Javascript policy I'd gladly hear your reasoning. I'm sure it would help others not confuse your point with vapid shitposting, as well.


Yes, that's what I'm equating it with. I think it's a fair analogy. Disabling Javascript isn't enough to 'protect your privacy', and even if it was, I haven't heard of any tangible impact that would have on anyone's life.


> Yes, that's what I'm equating it with. I think it's a fair analogy.

That you think it's a fair analogy doesn't help me in the slightest to understand what your reasoning is.

> Disabling Javascript isn't enough to 'protect your privacy',

In the same sense as wearing a face shield while operating a chainsaw is not enough to save your life. It goes a long way.

> I haven't heard of any tangible impact that would have on anyone's life.

Have you heard of Facebook? Google?


Okay, taking Facebook as an example. Let's say you visit a random website and get tracked by a Facebook Pixel (which happens to be an image, not JavaScript), what happens then? You see behaviourally-targeted advertisements on Facebook and partner destinations, instead of generically-targeted advertisements. I don't agree with the assertion that this has a materially negative impact on anyone's privacy or life as a whole.

I understand that this is an unpopular opinion, but it's what I believe.


> I don't agree with the assertion that this has a materially negative impact on anyone's privacy or life as a whole.

I haven't asserted that it has any negative impact. To say that it has no tangible impact (as you have) is decidedly wrong. Either the manipulation is working at a grand scale (which is scary in its own right), or people that invest that much money in targeted ads are idiots buying snake oil. Regardless, Facebook and Google now command huge social and political influence, and they're entirely in the business of using my private information to sell ads.

I guess wanting to be the constant target of increasingly direct attempts at manipulation is a matter of personal preference, but the fact that it has an obvious material impact on the world is not.


> I haven't heard of any tangible impact that would have on anyone's life.

I installed the NoScript plugin (alongside my existing adblockers that also block social media stuff).

I love it. My browser (Firefox) is now far more responsive and more stable, and my CPU fans turn on far less.


I spent several months with JS off by default. I relented after one too many broken sites. Since then, I've suffered from sites with HTML popups, autoplaying videos, and not one, but two "subscribe to my newsletter" prompts which trigger when you move your mouse to the address bar.

Disabling JS by default severely reduces the ability of websites to pull user-hostile tricks (though it breaks web apps). No website (presenting static information to be consumed) should ever break with JS off, and any site that does is defective. I won't extend this to web apps (interactive dynamic functionality like Google Docs) though.


> 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.

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?


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.


Both is good.


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.


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/


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


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 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.


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


Serious question:

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


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.

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.


> 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 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.


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.


> 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.

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


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


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


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.


> 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#.


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.


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.


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.


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?


> 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.

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.


> 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.


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


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.


I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people just for the sake of it.

If you think we have a large amount of fresh frontend people, understand they are hired almost with a one to one correspondence with fresh product/business people.

Modern product development is essentially a polishing job on every component that Twitter Bootstrap or Jquery UI ever invented. Over and over, we dress up a modal, with a slider, with a ‘user flow’, with some tooltips, and so on, and allow the process to masquerade around as real design/engineering. There’s so much money in this industry that we can hire entire teams to basically take a Bootstrap component, and theme it. This gets passed on as product development, and from the developer side, it gets passed on as engineering.

If this is the level of masquerading occurring, why would a frontend developer ever go ‘what’s the right solution here?’.

Something similar is happening on the backend and infrastructure. It too will take on a mask behind devops and data science and start pumping out what are probably straight up SQL queries and cron jobs. This will get passed off as design and engineering as well.

We’re too big.


> There’s so much money in this industry that we can hire entire teams to basically take a Bootstrap component, and theme it.

This feels a tad reductionist based on my experience. Sure, most apps are designed around an agreed-upon set of affordances and design principles that the community determines, but modeling application behavior for real-world scenarios involves way more than theming a bootstrap component. I think it’s a mistake to reduce a developer down to the code that they write, because the ultimate value of a developer is in the code that they choose not to write just as much as the code they do write.


I think you're bordering on a contentious idea that I will take a step further. I would argue that frontend, nearly in its entirety, is effectively one giant bike-shed operation. And like you're alluding to, it's an operation that exists mostly because there is money to burn. At best, frontend exists to save backend engineers the trouble of dealing with the tedium of HTML/CSS.

As an example, the article brought up Craigslist; renowned for its brutalism. Craigslist would only be hindered by any frontend changes: arbitrary and confusing interface changes, (necessarily) slower load times, and increased complexity.

That said, I agree with the article that HTML form UX often requires more advance strategies like React and Vue. The decision requires discretion, of course.


I'm actually more of the opinion that a lot of backend is bikeshedding! Branding and UI/UX design are very important for emotionally influencing a customer's opinion or improving their user experience with your product. On the backend, how often are the any different than some cross set of options from:

  * synchronous CRUD
  * async data flow
  * bidirectional realtime messaging (message in the "data packet" sense)
  * search
Most products are not serving traffic that is large enough or solving a computational problem that distinct enough to not be covered by some off the shelf combination of the above. We just haven't figured out how to make these different solutions composable on the backend. Over the next 10 years I think we're going to see more and more codeless SaaS services, like Webflow for the backend.


It seems that each generation of programmers at some point comes to this epiphany that a lot of things that they're doing are repetitive enough that they ought to be doable by non-programmers, if you just come up with a way to glue those common things together easily. That was the story behind "4th generation" programming languages, for example; and to some extent, behind RAD.

Every attempt so far produced many technologies that died very fast, and a few (e.g. SQL) that survived long enough to become a natural and useful part of the landscape - but even that part still requires programmers to tend to it. When non-programmers try to use that tooling, the result rarely works well; and in those few cases when it does, it's rarely maintainable anyway.


RAD died because it could only cover 98% of business needs and idiot managers thought they needed a language to deal with 100% and so threw away really great tools.

I could fully foresee VB making a comeback in the future.


RAD never really died, we just stopped calling it that.

But open Visual Studio today, and create a new Windows XAML app, then open the form designer. You can still drag a button from the toolbox, move it around, then double-click it to wire up an event handler - exactly like it was in VB6. In fact, it's quite possible to ignore all the modern stuff like data bindings entirely, and just manually read and update all widgets, as a typical VB/Delphi app did.


A typical Delphi app might have done that, but a selling point of Delphi was that it had data binding.

Connect the TDB* vies to a TDataSource, and it would show the values of a database, without requiring manual updates.


VB6 and WinForms also had data binding. But in practice I've rarely seen it used, except for data grids.


WPF has databinding available today, it's not gone away.

https://docs.microsoft.com/en-us/dotnet/desktop-wpf/data/dat...


For WPF, data binding is idiomatic. It wasn't back in those days.

My point is basically that the tooling that we use for desktop UI development is still very much rooted in the RAD era - but as best practices around it changed, we dropped the "RAD" label. It was a gradual evolution, though.


>Over the next 10 years I think we're going to see more and more codeless SaaS services

Maybe it will finally happen, but some variation of this has been the holy grail for a lot of years now.

I read an article a while back that talked about how many times developers have implemented the same thing in different ways at different companies; for instance payment processing. And it's true. But, you have companies like Stripe and Braintree. Now, there's even a SaaS subscription management SaaS businesses that sit above these (I don't recall any names).

But these just become other things to which we have to integrate. Now the task has moved, but we still have to build the connections and implement all of the business rules that go around that. I guess my point is that with every business having different logic, processes, models, etc it becomes very difficult to have some generic tool that allows a codeless solution to all of these problems. It's not the individual components like those you listed that cause the complexity. It's the way they are wired together and the underlying rules. So, while it seems inefficient to keep building these things, I think it is reductionist to say "well, it's only another CRUD app" or whatever.

Sure, tools can make things easier, but they make things easier for everyone. So now the bar is raised in terms of what you must do over and above that baseline in order to win.

Maybe a good analogy is that back in the day everything was written in assembly. High level languages came along and made it easier to do more faster. But then the complexity of software and the demands on it also increased, so in a similar fashion it just moved the problem.


I suppose another way of looking at it, is more about what you've mentioned with Stripe, Braintree, etc. A lot of the things that a web business needs to run are getting built out as APIs. At some point, I predict non-tech companies that still need some tech components, they will:

  * pick out the SaaS they need, and someone will write a tool to integrate the top different SaaS providers together
  * they will differentiate themselves from their competitors based on their product offering and branding, less so on tech
So, I'm not saying that programmers in general will be able to plug and play backend infra like Legos, but that non-technical people will be able to mix and match the infra components they need without doing coding. For these kinds of people, what the computers are doing is not important, and the frontend is more important, IMO.


It might be possible that product development itself is the actual bike shedding, and all the frontend, backend and product devs help the product owner realize that ;) However, you can't know in advance, yet the process has a tendency to self correct over time - creative destruction and all that.


> the process has a tendency to self correct over time - creative destruction and all that

I wonder how long it takes for the correction to kick in, because for the last decade+, software seems to be getting worse and worse - slower, bloatier, less functional, and with more user-hostile business models.


Just look around your government systems. They have had decades to fix themselves but are they fixed yet? Are they faster, less bloatier, less user hostile and privacy invasive?


Let’s hope the public sector isn’t the model that the software industry is following.


Why, but it is. It's not the public sector that's causing these problems, it's the private companies that fulfill government contracts.


Don't be shy, go that last extra mile and just say that frontend engineers are fraud.


What do you consider "our industry" to be ?

Software development? Web development? What used to be called "Application Development" back in the 1980s and early 1990s?

I'm asking because there's a lot of software developers/engineers whose jobs don't feature any of the keywords in your comment ("Frontend", "Backend", "SQL queries", "modal" etc. etc.)


If all one has been exposed is a development world of web-based consumer-facing front-ends (CFUI), it is hard to imagine that the majority of software lies elsewhere. Hard to imagine that anything else is important. It leads to a viewpoint that modern programming is mainly about UI interacting with a database.


I'd say you have to group business-facing front ends with consumer-facing front ends, as well as big chunk of mobile development, because all of these are done by the same people from the same programming culture, with the same technologies, patterns and ways of thinking.

And with that, I'd argue this is majority of software.


By what measure? Majority of individual 'products'? Majority of programmers? Majority of investment? Majority of revenue?

I think that at best what you're describing is a thin simple majority by some of those metrics. But there are so many developers working on factory automation, networking, gaming, small embedded systems (anything with a chip in it, from washing machines to cars), not to mention the huge frameworks that power am off the simple apps you are taking about - Linux, Windows, Chrome, Firefox, Android, iOS, the major SQL DBs, the major NoSQL DBs, the language tools for all of these, the web servers, the distribution frameworks at Google/Facebook/Microsoft/Amazon and so on.

While the number of core technologies is obviously easily dwarfed by the number of applications, the number of people working on each of these core technologies is so large that I can't believe your assumption.

Also, some of these industries, particularly gaming, and maybe networking as well, are so huge in terms of revenue, that I don't think CRUD apps could win on that side either.


I'd say majority of programmer-hours, because anything else is a metric that's too unreliable / easy to fudge. "Individual products" is an arbitrary marketing distinction (e.g. a company I worked for could create and sell new products by tweaking few lines in a config file; every customer would get their own mix and match of software pieces). And neither investments nor revenue are directly correlated with the amount of software you have.

Note also that out of the things you mentioned, "factory automation, networking, gaming, small embedded systems", perhaps only small embedded systems projects aren't partly done in web technologies. Gaming definitely is (in AAA games, all the UI that's not the part of core gameplay - e.g. launchers, lobby, marketplace - is likely to be done in Electron or some embeddable webview library). Factory automation, if two companies I worked with over the last decade are any indication, is slowly moving towards webapps for everything. So I imagine networking on the admin side.

It's basically too cheap to make a shit, bloated but somewhat pretty UI with JavaScript. Everyone's doing it, everyone keeps hiring for it.


Using web technologies is not the same as doing crud web apps. Games for example are a very different kind of programming. And even if network admin and factory automation apps have web front-ends, that's still a minuscule part of the code.


Games are very different programming. Code surrounding games - lobby, game server lists, marketpaces, IAP - this is pure CRUD, and it's entirely unrelated to the game code.


I think there's a strong overtone of that in many places, including in business and popular culture. Most peoples' interactions with software are phone apps and web fluff.


Does the majority of software lie elsewhere?

Type "developer" into a job search.

The majority of all software in the world actually does lie in CRUD web apps today.


<rant>

At this point, I am convinced the problem is not web frameworks but browsers. Someone needs to take all the legacy bloat away and put it in the side while starting from the scratch. Web doesn't need three different languages. It doesn't need freedom that costs accessibility. It doesn't need to be so primitive.

It smells. Awful defaults.

import "reset.css"

import "reset.js"

</rant>


I agree, I feel like all the points both for and against SPAs and frontend frameworks in this thread are just circling around the idea that browsers make an awful platform for building software. But the delivery mechanism is so much more compelling than anything else available, and the momentum so great, that we're all willing to put up with it.

It will never happen, but I wish there was a second stack that browsers understood, totally separate from the DOM, purpose built for developing _applications_, rather than abusing the fact that this document creation tool allows us to put styled boxes in different places.

This is not really a failing of HTML, CSS, or JavaScript, but if your platform SDK's total feature set for building UIs amounted to some basic form inputs, incredibly inflexible tables, and a handful of ways to add semantics to otherwise featureless blocks of text and boxes, you'd be laughed out of the room. The fact that anything remotely feature rich must be built from scratch is part of the reason the ecosystem has such a bad rap for over reliance on packages, and for constantly reinventing the wheel.


Well, and this is it, isn't it?

The whole conversation ignores, for example, the reason that jQuery was invented: At a time when there were many competing browsers, all of which spoke different dialects of JavaScript (that's my punny way of saying that they had different bugs), HTML/CSS bugs that were all different across browsers... jQuery brought order to chaos.

And the problem is, that as browsers improved and got closer to general standards compliance (where we STILL ARE NOT today), they didn't remove the cruft and the past bad behavior - no, they continue to support code that implements that crappy API that was deprecated 15 years ago.

These problems continue today and as long as that is true - as long as fundamentally, the problem is the browser itself -- these frameworks will continue to have a place.


I'll take it a step further and say we shouldn't be using the Web paradigm at all.

We've tried a million different ways now to essentially generate HTML. So many frameworks. So many libraries. Front end. Back end. Etc.

But, we're still working within the paradigm of the stateless Web, designed to display documents and images. Trying to hammer an application in there (especially a SPA) really doesn't make sense.

So, why do we just keep forcing it? If leveraging the ubiquity of the Web is the objective, then there's nothing to say we couldn't have a VM running in a browser that itself uses web protocols/languages, but abstracts them away. That would leave us writing code a la Swing, an event-driven, component-based model that makes so much more sense for a GUI style application. No CSS, HTML, fighting back-buttons, state management, routing, etc. That's all handled in the VM.


> So, why do we just keep forcing it?

Because hyperlinked documents are the whole ball game. Web technologies are a pain in the ass for developers but a boon for the advancement of human knowledge and connectedness.

The great islands and continents of web space float in the same aether. They interconnect, despite being built at different times, in different styles, on different technologies. It all just, for the most part, works. It’s fucking beautiful.

The system is greater than the sum of its parts.


My comment was WRT to a better model for developing SPAs and complex Webapps, not sunsetting the Web in general.


I'm personally curious how far we could go with using just canvas and wasm. If we focused on making a browser that was just incredibly efficient and focused at using wasm and webgl, and had no other concerns, a lot of the cruft could be cut. Then any given "page" would essentially just expose the canvas for wasm to draw to, and GUI frameworks like Qt (which already can compile to wasm I believe) could just target this. We could then have different UI toolkits targetting this model, and hopefully even have something akin to Flash without being the same security nightmare.

Keep the current browser stack for the things it still makes sense for - static content like articles and blogs, and forums too, but anything with greater complexity and reactivity would run faster and get better gains from just abandoning html/js completely, and browsers themselves could stem the unending march of feature creep.

I'm just spitballing here, I'm not sure I think this is actually a good idea - you'd be losing a lot of accessibility you get for free with HTML for example, but I'd like to see some experiments in this area to see how far this could go.


> I'm personally curious how far we could go with using just canvas and wasm

In a word: accessibility. HTML is inherently accessible - you can curl a webpage and read the contents of any (static) web page. If you curl an entirely <canvas> based web page, you'll walk away knowing only that the web page has a <canvas> element in it.

You mentioned Qt. I've never programmed a Qt app, but I went hunting for its accessibility features in the docs[1]. I'm encouraged that Qt takes accessibility and Assistive Technologies seriously. However, if you're coding a web page in canvas/wasm/Qt you're going to need to make sure all the content, links and additional accessibility/AT requirements get ported from the <canvas> into the surrounding DOM to make it accessible.

That's a huge amount of work!

[1] - https://doc.qt.io/qt-5/accessible.html


Yes, the Web should stay what it is for static documents. In fact, what I advocated would continue to be based on Web standards (HTML, CSS, Javascript, and newer constructs like canvases, etc).

So, you would have a JS-based VM that runs in the browser. No Flash or other binary. Just pure Web standards for executing the code, rendering, etc. However, as an app developer, you wouldn't touch HTML or Web standards. Instead, they'd all be abstracted away and you'd work within a component/event driven model that's provided by the VM.

Instead of CSS, you'd roll themes, allowing you to stylize components. They'd ultimately be applied via CSS, but ideally you'd have a GUI interface for creating these themes. CSS gives you ultimate flexibility, but why are we still fighting whitespace and these other low-level document layout constructs when we are really working at a UI component/control level? It's like designing in assembly.

Instinctively, people won't want to give up this granular control. But that's only because we've been thinking about apps in Web terms for so long.

For me, that's the problem with a lot of these frameworks. They do a great job of helping you to wrangle the impedance mismatch between the web and apps. But, they are all predicated on deference to the Web, so they keep us immersed in this world, essentially fighting the Web's ill-fittedness to the task: HTML templates, DOM management, render functions with HTML strings, CSS styling embedded in "components", etc.

Why go so far to create a framework only to hamstring it with the very problems it aims to solve?


We should embrace flash again - https://github.com/ruffle-rs/ruffle


And yet, unlike newspapers with an in house advertising staff. All web adverts are 3rd party. That are easily blocked. Google laughs to the bank everyday it killed old advertising.


Since 2013 my work has generally consisted of applications that run in the browser, right now I'm working on the first normal website I've worked on in 7 years. And I agree this is a bunch of little polishing jobs.

I do say to myself what's the right solution here, but I know for business reasons I am not allowed to do the right solution.


Isn't this the same in almost any industry? For example, in engineering this kind of "reinventing the wheel ad infinitum" you are describing is incredibly common. How many times to you think engineers have separately designed and tested clips to hold capacitors in place in the ECU of a motor? Many thousands of times, while being paid competitive salaries. Maybe you should argue there should be some "book of capacitor clip designs" but actually this doesn't work in practise because every capacitor clip design needs to fulfil very slightly different requirements. Often it is just easier and faster to redesign from scratch.

Taking existing components and redesigning them in some small way to fit your specific requirements is common in almost every industry I can think of.


The alternative is just having premade components lazily glued together. It seems that the markets have decided that highly polished custom tools are worth the cost.


Low code and no-code markets are growing rapidly, so don't be sure the markets have decided.


"Growth" != profit. I can sell $10 bills for $1 and grow rapidly too, doesn't mean I will ever become profitable.

Are these low/no-code providers actually making profits, or is it a temporary fad and eventually 1) the market will re-adjust and these no-code tools will become more expensive to sustain themselves, bringing up the cost of a no-code app and/or 2) users of these tools will realise their limitations and eventually word will get out that you end up spending twice as much with no-code than doing "code" to begin with?


Nice take. Yes design/frontend has rarely been about actual design. Backend web has rarely been about engineering either, I'd say. Just look at all the elastic search engines left open to the public internet as proof of unconscionable levels of ignorance.


Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those.

I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, and unfortunately increasing) will quickly make me go back since I can often find what I'm looking for somewhere else, on a site which doesn't require running arbitrary code just to render what usually turns out to be static content anyway.

The state of web development has always seemed a bit odd to me, largely driven by fashion and a desire for developers to "outdo" one another in complexity. There's a ton of churn and ADHD as people jump around from one trend to the next; instead of settling down and focusing on getting the most out of a platform, they're eternally in search of the next one. Reinventing/reimplementing in JS what basic HTML and CSS can do is just one example of this behaviour. The massive overuse of the "modern" adjective is another, and quite frankly all this really irritates me, as someone who just wants to use the Web as a hypertext document system to find some information.


I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens.

You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least for me, I have to fight against every client, employer, and coworker to execute this approach.

Maybe web developers as a whole just got bored. They don't want to make webpages like they did in 2002.

Make a folder with some .HTML, .CSS, .JS files. Then sync it to a linux box. Wow, you're on the internet, a modern marvel. I see younger devs who don't even know this basic stuff. As if, this were all way more complicated than it actually is. It's not.

How do we get web devs back on track? Makers need to thoroughly understand their tools and materials, inside and out, for any industry. I'm just not seeing that as much anymore. It seems like an education problem, or maybe it's just human nature to go for new and shiny instead of practical and reliable.


I agree with the sentiment of what you're saying, but I don't agree with the premise that there are no use cases for single page apps. You can achieve a decent UX for some applications by using small amounts of vanilla JS, but it's simply not possible to avoid re-rendering the entire page without using XHR requests at some point. That is how the browser is designed, fundamentally. Because it wasn't designed as an application platform, it was designed as a document platform.

But some products are actually better as applications, not interconnected documents. For those applications, the browser fights you every step of the way, because that's not what it's designed for. You simply can't compare the UX of document-based web applications to native clients.

An SPA is just the web approximation of a native client. Your application truly runs in the client process continuously, so rendering transitions happen smoothly instead of blank pages and jumping transitions. Everyone would benefit from understanding more and using that to simplify all areas of the tech stack, but the experience that an SPA offers is simply not possible otherwise.


SPA is a poor approximation of a native client with a hugely bloated browser stuck in some level of the abstraction, bypassing native app libraries, design sensibilities, typography guidelines and accessibility by implementing some UI framework that was developed by people that are entirely unqualified for it. Have you looked it the guidelines for UI development, say for MacOS? Here you go: https://developer.apple.com/design/human-interface-guideline...

PWAs, browser apps - they bypass all this work from professionals and give it in the hands of an unequiped developer. Oh god.

A browser is a window, an area of the screen that is allowed to do whatever it wants in a sandbox mode. This is a terrible idea. It becomes complete wild-wild-west.


>it's simply not possible to avoid re-rendering the entire page without using XHR

Wrong on two separate levels.

First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever.

Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs.

The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity.

If you pay even a little attention to order of loading you can avoid FOUC entirely. If you pay a little attention to defining sizes of leading elements, you'll have constant layout of the top part of the page, and avoid flash of white background. If you use anchors here and there your user will be scrolled to the proper position.

Yes your page can easily look as if it got only updated with JS after doing a full load+render.

The technology is already in the browser; no need to approximate it with three layers of JS.


You can’t compare the UI of a web page built in this way to an SPA or a native client. Re-rendering an entire page on every interaction is strategically never going to get you the same experience. I understand wanting to be a browser purist, but web applications have had pretty laughable UX compared to native apps of even 20 years ago.

I mean look at an iOS app designed by Apple. I always reference the AppStore app itself. You simply can’t build that app as a web app, certainly not by using iframes as a “solution.”


You don't need an SPA to use XHR, and your description of the SPA experience for the end user is a fantasy - there's a reason pretty progress bars are popular in SPAs, and it's not because of fast state changes, quite the reverse.


It's funny, your example actually shows the primary benefit of an SPA, and doesn't do anything to show any downsides. A progress bar is a perfect example. You can't show a progress bar with HTML. You would have clicked something, and a new page would be rendered entirely. In the time it took to create the new page on the backend, the user would be staring at either a white screen or the current page. If they're looking at the current page, they probably think the application is malfunctioning, as no user feedback was given to their action.

Whereas, with an SPA, you can _instantly_ show a progress bar, at least indicating that something is going on. And, the very fact that you're showing a progress bar means that the client side rendering isn't the slow action, it's retrieving something from the server. So, the UI was as interactive as possible.


This is an amazing feature you simply don't need on the majority of web apps, because a) the browser has a loading indicator and b) most web apps are fast enough to not need to tell the user about it, they just load new pages in milliseconds instead.

An in-page progress bar is in most cases a failure of UX, not a success.


I'm pretty sure I can find more pages that take more than 200 milliseconds to load than ones that are under.


Please write more about this because I feel the exact same.

Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today?

What should have happened is the following:

- Develop web-to-native-UI mapper, call that thing a browser.

- Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.

- Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.

The web went downhill the day `<input>` tag was allowed to be styled by CSS. We had a web-to-native-UI mapper!

I am forever a believer that democratically designed things generally suck unless there is a BDFL who can make shots. Dictatorship is a necessity of great products and services - Steve Jobs to Guido, democracy is good in politics, not in software development. Feature creep from the public will ruin whatever youre buidling. Designers will ravage through what worked well and replace it with "taste".

/Rant, I am getting old. Humans tried to make the web "pop", but instead it exploded with chaos.


Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static

Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable element invoking some JS.

I've had some pretty annoying conversations with customer support and developers about things like this; almost always, the response is something like "we didn't think you would have a need to do that". They would not have needed to think about it at all, and it would work for me, if they had just used a regular link.

That said I'm not totally opposed to SPAs; highly interactive apps, e.g. realtime games and such, would definitely benefit as they wouldn't really make sense as a linked set of documents. But for everything else it feels like they not only reinvent the wheel, but make it square.


It's not even the ability to bookmark it. It's basic stuff like the ability to restart my computer (e.g. because Windows demands that for updates), and go back to the same exact spot I've been at. For desktop apps, this works. For web pages that are just web pages, it works. But with something like Facebook, if you close a tab in which you've been scrolling through the feed, that state is forever lost.


“Let the page refresh” translates to a terrible UX. It devalues the application. It’s equivalent to buying a physical product, say a car, but the car jerks up and down whenever you hit the gas, and you hit your head on the roof every time.

Yea, the web page _works_ but it’s ugly, and in poor taste. Users do not care about browser purity, they want an app that seems polished. You can’t get that experience by using semantic HTML at all.


I'm pretty sure blind people don't even notice this 'terrible UX' problem you describe, and that sighted folks aren't quite as jarred by it as you think.

This 'taste' issue probably matters more in some organizations than others. Hopefully they don't involve blind people in their business, because SPAs are notorious for being unusable to them. You can design an SPA with accessibility in mind (https://www.deque.com/blog/accessibility-tips-in-single-page...) but most devs either can't be bothered or aren't even aware of the issue.


Yes, people who don't have the ability to see won't care about flickering on the screen and the better user experience that a single page app affords to users who can see. Not even sure why you're making that point other than to try and imply that people who write single page apps automatically don't care about blind people, which is self-righteous and rude.

We have a single page app and we regularly run it through screen readers to see what the experience is like. Since an SPA is not some magical entity and it does produce a real DOM tree, we can achieve a great degree of accessibility (not perfect) by simply focusing on the markup that's produced. That doesn't help with things like loading screens, but again, since we actually check applications on screen readers, the experience for pages that take a long time to render is not much better with pure HTML either.

I read the link you posted and it's a good resource. The #1 takeaway I got from it is:

> Make sure that client-side view changes are known to screen reader users by announcing the change in page title, using ARIA live regions and/or focus management.

That's a good idea and one we'll incorporate into our application.

Some other comments in the article are not helpful, such as:

> Consider whether a single-page app is really necessary, and if you even need to use a JavaScript framework at all.

This is a moot point. Using a JavaScript framework to create an application is not only acceptable, but extremely popular. So instead of trying to politically smash the idea of building an application using JavaScript, we should be focusing on how to improve accessibility in that landscape. We can and should figure things out.


I appreciate you taking the time to look at that.

I'm glad there are people out there taking the accessibility issue seriously, what you said does make me more inclined to evaluate framework-based solutions. Nice to know at least parts of the most popular JS platforms are maturing enough for this to be easier for devs to implement.


Can't agree more. It's a very simple point but I am surprised that people couldn't realize it and even downvoted your view.

IMO, discussing this further will just yield a negative returns as I think there are some fundamental issues/gap between two parties in this thread.

No matter how much ppl kick and scream, the SPA is gonna make the web a much more user friendly place in general. When we fade away and the next generation of us come, they will take this as the new norm easily and happily.


Not sure why you think SPAs can't have unique URLs or real links.


They can, but it requires additional work on the part of the developers, which in my experience is almost never done. Also, that's kind of what the SPA acronym stands for, no?


It does not require much work, and basically none of you use any standard libraries or frameworks, which handle it all for you.

And SPA doesn’t mean you can’t use real links or pages.


> Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static.

To be completely honest, this is one of my least favorite things about HN. As I write this comment and click reply, if I wish to navigate “back” after I post this comment, the first back button click with take me to this still-filled comment form. (Will I fuck anything up by clicking “reply” once more? This is an easy trap for a user to fall into.) The second back will take me back to the post comments. Which is weird, because this is where I was taken after posting the comment. The third back will take me back to HN homepage. I expect to go back to the homepage on the first back click.

And this nav stack works as it does because HN uses plain HTML forms without any “overkill” JS. But the reality is that the default back behavior doesn’t really fit most user expectations, because most people don’t understand that clicking each of these buttons added more and more to the stack. Most people don’t know what a stack is! :) I think this is a great example of why the default document behavior of the web doesn’t really match most people’s user expectations, and the normal form behavior on the web makes it way to easy to do the wrong thing, like re-submit information.


> Will I fuck anything up by clicking “reply” once more? This is an easy trap for a user to fall into

Have you tried clicking "Reply" once more after going back? If not, do try.


> Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order

Designer hate it


> Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.

> Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.

I'm not sure if this was supposed to be a case of 'how it once was' or 'how it should be', but this was never a reality, at least after the 90s. Native apps have always tried to style themselves just so (my company has a C# B2B GUI that has a little bit of assembly somewhere calling a Windows interrupt directly because they couldn't figure out another way to change the color of some window element). Even the earliest web pages were often trying to look as different as possible.


How is it that there are so many of us, but I never seem to work with any of you?


haha, I ask myself the same question.

Someone should make a job board called noSPAjobs.com


Just chiming in to say this is an absolutely viable approach. I just built a project, over about six weeks, using mostly vanilla js and some jquery (the heaviest widget I have is tinymce, which is a necessity unfortunately), and started selling it about two weeks in. I'm up to $650 mrr and the sky's the limit (really, the market is huge and desperately underserved), and not one person has complained about it acting like an old style website. People are just happy it works. And mobile testing was a breeze.

If I tried to build this on a "modern" stack I cannot imagine any benefit, only drawbacks.


Got a link? I'm curious what your end product looks like.


So unfortunately the live project has no public-facing component; without going into too much detail it helps certain corporations and larger nonprofits with a kind of compliance. But, I can tell you that I based it very closely on the layouts provided by the ultra lightweight css framework, PureCSS. (This is also my favorite framework!)

https://purecss.io

The layouts are here:

https://purecss.io/layouts/

One other remark: people are happy when they learn about this. That is now my #1 predictor of success. Everyone I've demoed to has adopted the product within a day (usually during the demo), and tech wise it's no different from what was possible with the web 15 years ago.


> loads 50x-100x faster

And takes less time to develop in the first place! These frameworks just seem like pure overhead to me.


You end up dupe your layout page everywhere and have a hard time update all of them if designer changed their mind.

Or you could use some template system to do that… but if you need to use template, why not use react(or something like that) anyway?


Because Rails, Symphony, Django, Phoenix or whatever does the job in the preferred language of the developer/team and often has more batteries or better tooling included.


I bet those are not a Front end's preferred language and you end up need JavaScript anyway if you need some extra client form handling. Now you use two language to do one thing and made it more difficult to be maintained.

That problem was solved approx 20 years ago.

The alternatives are not react and templates vs writing html by hand.


The browsers had support for XSL templates

You write your website in XML and the browser renders it using the template


100% agree.

KISS - Keep It Simple, Stupid - Never let me down.


I'm agreeing with you that the "modern web" is too complex, but the "make a folder and sync it to a Linux box" solution doesn't work very well for real-world use. It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.


>It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.

I was pushing to *nix hosts I didn't have to manage in early 2000. Actually, one of them I recently remembered and had paid a small lifetime membership for limited static hosting (<$100) and simple shell access and guess what--the pages I put together 20 years ago and supplemental files I had hosted are still there. Not only that, they still render as intended.

I've done absolutely nothing for 20 years at this specific host and it's working today. Yes, the content is fairly static and very simple (its 20 years old) but it's all there. It's a simple shared system and no it wouldn't scale out to support more than probably 10k simultaneous requests but its served its purpose over the years. No, there's no SLA. I'm not saying services like S3 haven't been able to improve on that older infrastructure but it goes to show what very simple systems are capable of.

I've not spent a second of time in 20 years worrying about security, someone else did for a very nominal fee. This isn't a new concept, now we have better scaling available for sure.


I've often said that web development has a big culture problem.

In any other field, 'modern' is the opposite of a selling point. People want tools that work, that are proven and have years of stability and momentum. But in web development, there is an obsession with the new and shiny. It's 100% about the developer's own experience in creating a program and 0% about the user's experience actually using the half baked and constantly changing web app.


Is that really true?

On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year! Since React was released, we’ve gone through through at least two new ways of deploying a server — containers and serverless, replete with their own huge abstraction layers like Kubernetes — and we’ve moved from monoliths to microservices and back again. And in native land, the “Rewrite It in Rust” crew is doing their best to bring the new and shiny to systems programming.

I agree that frontend web developers are maybe a bit too enamored with new tools. But I don’t think that mindset is unique to them, at all; they just happen to be the most numerous and visible examples.


Is Go really "shiny"? I mean, it's probably the most conservative mainstream PL on the market today, rivaling Java in some respects. Many claim that this is in fact why it's so popular.


I have just recently been tasked on estimating how many people in our city would fit your standard job requirements if we applied them to Go... since the requirements are legally necessary, we had to ditch any plans of using the language.

I don't think "exploding" is the correct word, although it is growing.


On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year!

This is only true in shops where webdevs dabble in back end, same as node.js. In most places you will find recent versions of things that may be decades old - Python, Postgres, Apache, even Linux itself.


Anecdotally, that is not the case — I know many non–web developers who are excited about new, trendy technologies like like Go.


Go and Rust are both older than react. And I 100% agree that backend people overengineer with stuff like kubernetes. I think that's less about the new and shiny and more an obsession with scalability - even though the site could easily be hosted on a single Linux box.


I appreciate your comment, but please refrain from referring to general lack of focus as a community as ADHD


Why? Its a pretty apt description if you know anything about adhd or have it.


I have adhd. in my experience, commodifying the use of ADHD as anything other than a mental disorder makes it easier for people to make claims like "everyone is a little bit adhd" etc.


I have adhd too.

In my experience this industry is riddled with literal adhd fueled idiocy.

I dont think everyone is a little bit adhd but i also dont give a toss if someone wants to use a metaphor on the internet.

Button up buttercup.


Maybe we are? Suggesting the whole world stop doing this is silly bud


> Maybe we are

https://adhdawarenessmonth.org/everyone-has-little-adhd/

An ADHD diagnosis is not purely based off of exhibiting behaviors typically associated with it. While everyone is forgetful/distracted sometimes, ADHDers have a physical/chemical difference in their brain which make such behaviors impossible to avoid.

> Suggesting the whole world stop doing this is silly

One person at a time


Just wanted to say that I don't think this is a silly pursuit, and I'm sure plenty of other people reading feel the same way. I think this is a serious issue because the language we use is related to how we act and treat each other, and talking about the issue has a real effect.

Reminds me of the quote attributed to Margaret Mead, whom I actually don't know anything about besides the quote: "Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has." Too corny? Idk. I like it


Yea maybe save it for when speech is actually a real issue and not over policing and treating it like it's your personal servant. Grow up and get over it


Regardless of disagreeing about the terminology or not (it's mostly a joke but I don't care), it's still a silly pursuit


> instead of settling down and focusing on getting the most out of a platform

How do you know when to settle? Should we have stopped at jQuery?

We are doing exactly what you are asking for, but not in the way you like. Web developers are getting the most of the web platform. The result is that new frameworks and libraries are keep popping up. Most will sink, a few will float and it's okay, this is how evolution should happen. I don't like all tech solutions that I encounter just because they are new. I simply just don't use them in my projects, simple as that.

I'm sorry, but the web not just a hypertext document system to find some information, it has outgrown this idea probably 20 years ago.


> Web developers are getting the most of the web platform.

I disagree, as so many (perhaps most) web developers have no idea what to do with web technologies aside from building SPAs in their pet framework.


And most backend engineers don't go architecture astronaut Kafka, Cassandra, Kubernetes, et al into seemingly straightforward concepts?

The number of times I've seen Kubernetes as part of an on-prem install of enterprise software when there will only be one node was hilarious. That front-end devs get flak seems to largely be because their choices are visible, not because they are any different from the weird heaps people throw together behind them.


Oh no, that's terrible and idiotic behavior as well. A lot of dumb decisions are made on both the backend and the frontend at many companies; one does not preclude the other.


>Should we have stopped at jQuery?

For the bulk of websites that are mostly static with a little sprinkle of fancy interactions here and there? Maybe.

There is a time and place for React. Shocking to some, that place is not actually everywhere on the web. The bulk of the web IS actually about finding information. Few sites are soundcloud style webapps.

For context, I like react a lot -- I love its clojurescript re-frame variant. It is what I reach for _when needed_. The rest of the time, give me boring forms, pages, and jQuery and let me get on with my day.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: