13 ms·

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 tas

by luxphl 6y ago

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.

Dowwie 6y ago
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.
- networkimprov 6y ago
  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 :-)
  - owl57 6y ago
    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.
    - MattGaiser 6y ago
      Users complain to Microsoft for making the OS slow or complain to their internet provider.
- thomascgalvin 6y ago
  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.
- Spivak 6y ago
  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.
- root_axis 6y ago
  > 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#.
- luxphl 6y ago
  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
mmaunder 6y ago
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.
c22 6y ago
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.
- rossdavidh 6y ago
  Why not both?
  - beckingz 6y ago
    Both is good.
  - TeMPOraL 6y ago
    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.
burlesona 6y ago
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.
- simonw 6y ago
  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!
  - duxup 6y ago
    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.
conorh 6y ago
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.
- bobthepanda 6y ago
  > 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.
  - mattmanser 6y ago
    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.
- commandlinefan 6y ago
rossdavidh 6y ago
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.
- MattGaiser 6y ago
  I haven't seen a bootcamp teaching Django recently, so I can see where that might be true. The cheap people are overwhelmingly JS.
  - wlll 6y ago
    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.
austincheney 6y ago
> 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.
- luxphl 6y ago
  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.
  - austincheney 6y ago
    > 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.
    - luxphl 6y ago
      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.
microcolonel 6y ago
> 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.
userbinator 6y ago
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.
- MattGaiser 6y ago
  > 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.
  - millstone 6y ago
    Right. If your product is paid for in eyeballs, then by the time users have perceived your low quality, they've already paid.
    - TeMPOraL 6y ago
      This (and related phenomenon with subscriptions) is arguably a big drive for the software becoming increasingly infantilized; shiny toys instead of useful tools.
  - luckylion 6y ago
    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.
commandlinefan 6y ago
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?
- rjknight 6y ago
  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 https://angular.io/guide/architecture
mirimir 6y ago
> 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.
- mavhc 6y ago
  Proof that hardly anyone cares about privacy
  - mirimir 6y ago
    Yeah, that does seem pretty clear. So it goes.
  - dbbk 6y ago
    Most people don't because it never impacts them in a visible or tangible way.
waheoo 6y ago
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?
jrochkind1 6y ago
You suggest React is at once both "easier to work with"; and "largely more complex" and "gatekeeping" (harder to learn?). Aren't those opposites?
- luxphl 6y ago
  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.
  - jrochkind1 6y ago
    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?
    - cutemonster 6y ago
      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
retreatguru 6y ago
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?
post_below 6y ago
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.
pjmlp 6y ago
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.
- int_19h 6y ago
  Speaking as a user, I generally prefer non-SPA web apps as well. They're much more predictable.
- kitd 6y ago
  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 https://github.com/turbolinks/turbolinks
  - ksec 6y ago
    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 https://github.com/hopsoft/stimulus_reflex
  - ComputerGuru 6y ago
    See also unpoly and intercooler, which are more powerful and intended for more fine-grained usage. https://unpoly.com/ https://unpoly.com/ https://intercoolerjs.org/ https://intercoolerjs.org/
- m33k44 6y ago
  What frameworks do you use?
grey-area 6y ago
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.
- deiznof 6y ago
  >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.
  - grey-area 6y ago
    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).
  - marcosdumay 6y ago
    > 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.
  - ryanbrunner 6y ago
    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.
azangru 6y ago
> 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.
1337shadow 6y ago
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.
- danjac 6y ago
  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).
  - marcosdumay 6y ago
    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.
andrepd 6y ago
>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.
- WesolyKubeczek 6y ago
  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.
  - deleted 6y ago
    [deleted]
rimliu 6y ago
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?
- marcosdumay 6y ago
  > 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?
mwcampbell 6y ago
> 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?
- tcgv 6y ago
  Salaries are high because the supply of (skilled) software developers is low.
boomlinde 6y ago
> 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.
- dbbk 6y ago
  Do you also wear tinfoil hats?
  - nyanpasu64 6y ago
    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.
JeremyNT 6y ago
> 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.
ComputerGuru 6y ago
> 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.
- EEMac 6y ago
  Developers serve their clients and employers. In the best situations, serving the user aligns with that.
vmchale 6y ago
> 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
hawski 6y ago
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.
wlll 6y ago
> 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.

by luxphl 6y ago

Dowwie 6y ago

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.

networkimprov 6y ago
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 :-)
- owl57 6y ago
  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.
  - MattGaiser 6y ago
    Users complain to Microsoft for making the OS slow or complain to their internet provider.
thomascgalvin 6y ago
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.
Spivak 6y ago
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.
root_axis 6y ago
> 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#.
luxphl 6y ago
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

mmaunder 6y ago

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.

c22 6y ago

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.

rossdavidh 6y ago
Why not both?
- beckingz 6y ago
  Both is good.
- TeMPOraL 6y ago
  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.

burlesona 6y ago

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.

simonw 6y ago
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!
- duxup 6y ago
  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.

conorh 6y ago

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.

bobthepanda 6y ago
> 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.
- mattmanser 6y ago
  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.
commandlinefan 6y ago

rossdavidh 6y ago

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.

MattGaiser 6y ago
I haven't seen a bootcamp teaching Django recently, so I can see where that might be true. The cheap people are overwhelmingly JS.
- wlll 6y ago
  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.

austincheney 6y ago

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

luxphl 6y ago
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.
- austincheney 6y ago
  > 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.
  - luxphl 6y ago
    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.

microcolonel 6y ago

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

userbinator 6y ago

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.

MattGaiser 6y ago
> 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.
- millstone 6y ago
  Right. If your product is paid for in eyeballs, then by the time users have perceived your low quality, they've already paid.
  - TeMPOraL 6y ago
    This (and related phenomenon with subscriptions) is arguably a big drive for the software becoming increasingly infantilized; shiny toys instead of useful tools.
- luckylion 6y ago
  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.

commandlinefan 6y ago

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?

rjknight 6y ago
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 https://angular.io/guide/architecture

mirimir 6y ago

mavhc 6y ago
Proof that hardly anyone cares about privacy
- mirimir 6y ago
  Yeah, that does seem pretty clear. So it goes.
- dbbk 6y ago
  Most people don't because it never impacts them in a visible or tangible way.

waheoo 6y ago

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?

jrochkind1 6y ago

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

luxphl 6y ago
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.
- jrochkind1 6y ago
  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?
  - cutemonster 6y ago
    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

retreatguru 6y ago

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?

post_below 6y ago

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.

pjmlp 6y ago

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.

int_19h 6y ago
Speaking as a user, I generally prefer non-SPA web apps as well. They're much more predictable.
kitd 6y ago
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 https://github.com/turbolinks/turbolinks
- ksec 6y ago
  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 https://github.com/hopsoft/stimulus_reflex
- ComputerGuru 6y ago
  See also unpoly and intercooler, which are more powerful and intended for more fine-grained usage. https://unpoly.com/ https://unpoly.com/ https://intercoolerjs.org/ https://intercoolerjs.org/
m33k44 6y ago
What frameworks do you use?

grey-area 6y ago

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.

deiznof 6y ago
>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.
- grey-area 6y ago
  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).
- marcosdumay 6y ago
  > 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.
- ryanbrunner 6y ago
  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.

azangru 6y ago

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

1337shadow 6y ago

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.

danjac 6y ago
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).
- marcosdumay 6y ago
  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.

andrepd 6y ago

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

WesolyKubeczek 6y ago
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.
- deleted 6y ago
  [deleted]

rimliu 6y ago

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?

marcosdumay 6y ago
> 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?

mwcampbell 6y ago

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

tcgv 6y ago
Salaries are high because the supply of (skilled) software developers is low.

boomlinde 6y ago

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

dbbk 6y ago
Do you also wear tinfoil hats?
- nyanpasu64 6y ago
  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.

JeremyNT 6y ago

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

ComputerGuru 6y ago

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

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

vmchale 6y ago

> 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

hawski 6y ago

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.

wlll 6y ago

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