7 ms·

This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written

This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway. What is the cause of this? 1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)? 2. Non-JS developers mystified and irritated at a bunch of practices they've never really internalised? 3. The undercurrent of "frontend is not real programming" prejudice that existed long before React etc al. and will continue to exist long after it?

cleoxjefbjxis 1y ago
You miss the whole point and the author is correct about this: Modern CSS is powerful, and HTML is the way to deliver web content. Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice. For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll minimize it.
- zero_shift 1y ago
  Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system). What I find interesting though is the assumption that web dev is done by "JavaScript people", that even the best "JavaScript people" have no technical breadth, and therefore fester in a cesspool of bad ideas, unlike your median backend dev who swims in the azure lakes of programming wisdom. Now, I've done plenty of SPAs, but I've also done plenty of other things (distributed systems, WebVR apps, metaprogramming tools, DSLs, CLIs, STB software, mobile apps, a smidgeon of embedded and hobbyist PSOne games). Which gives me the benefit of a generalist perspective. One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy. These groups all regard each other with contempt, even though they are largely addressing similar fundamental issues in different guises. It's a social dynamic as much as any technical one.
  - PaulHoule 1y ago
    It’s connected with the questions around occupational licensing of programmers, unions, and similar structures which would not be so much about getting paid more but about getting quality up, squashing bullshit, and getting our quality of life up. Without a cohesive community, mutual respect, and recognition of a shared body of knowledge, we don’t have the solidarity to make it happen. As for Laravel, I’d say people were making complex applications (Ebay, Amazon, Yahoo) in 1999 —- Google Maps were better than Mapquest, which drew each image with a cgi-bin, but many SPA applications are form handling applications that could have been implemented with the IBM 360 and 3270 terminal. The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw. You need two handfuls of helper functions, for instance <? draw_select($options,$selected_options,$attributes) ?> to make forms which can be populated based on what’s already in your database. People never wrote down “the 15 helper functions” because they were too busy writing frameworks like Laravel and Ruby-on-Rails that did 20x more than you really needed. So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built. As for performance, web sites today really are bloated, it’s not just the ads and trackers, it’s shocking how big the <head/> of documents get when you are including three copies of the metadata. If you are just drawing a form and nothing else, it’s amazing how fast you can redraw the whole page —- if you are able to delete the junk, old school apps can be as fast as desktop apps on the LAN and still be snappy over mobile.
    - wredcoll 1y ago
      > The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw Yes, I was there, I wrote and used these pages. It sucked. Things are better now. > So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built. Building a form with zero user affordances is not difficult. It just isn't good. We absolutely know how the pyramids were built. You get a whole bunch of humans to move a very large amount of stone and then stack it up in a big pile. The reason nobody builds pyramids today is because we have better alternatives.
- zwnow 1y ago
  Even with Laravel you will write lots of Javascript unless you go for blade templates or that other templating thing. Javascript is also great for making the web interactive. Maybe the sheer amount of SPAs out there shows us what we really want from the web. Most things ppl use in their day to day life cant be built with HTML and CSS only
  - brigandish 1y ago
    > Maybe the sheer amount of SPAs out there shows us what we really want from the web. A distribution and installation system that works on almost any device?
    - zwnow 1y ago
      Interactivity and a way to build experiences and applications. Not just passing documents back and forth
  - esskay 1y ago
    What 'other' templating thing? I'm assuming you're likely talking about either Intertia or Livewire. Inertia's more geared towards SPAs than Livewire though. Most Laravel devs tend to use JS sparingly - not everything needs JS. Theres next to no reason why the vast majority of sites on the web would ever need to be heavily reliant on JS. Rendered HTML/CSS with JS being used sparingly for page functionality is a far better user experience. I'll never understand the obsession with JS for the sake of JS.
    - zwnow 1y ago
      Yea Livewire, couldn't think of the name.
- graealex 1y ago
  Are you aware that nowadays you can write SPAs in dozens of languages? It's an entirely different concept. It's certainly not the right technology for a news site, but days ago in a different place, there was for example the discussion about how an SPA and minimalistic API services fit a lot better with your average embedded device.
- motorest 1y ago
  > You miss the whole point and the author is correct about this: your comment is funny, because you are so wrong you aren't even aware how and why you are wrong. It's in "not even wrong" territory. I'll explain you why. > Modern CSS is powerful, and HTML is the way to deliver web content. Irrelevant. That's not why the world uses JavaScript frameworks. It seems you aren't even aware of the most basic reasons why the world migrated to SPAs. The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads. Also, classic old timey server-side rendered WebApps end up being far more complex to develop and maintain as you mix everything together and you are unable to have separation of concerns regarding how your platform is deployed and ran and how your frontend works. SPAs even allow your frontend team to go to the extent of handing your backend as if it was a third-party service, and some SPAs are even just that. There are plenty of CMSs out there which eliminate the need for a backend by providing all content needs through their commercial APIs. This makes webapppp projects greatly cheaper and simpler to finance and support as you can simply bother about developing and maintaining your SPA. Lastly, those JavaScript frameworks you're trying to criticize also use CSS and HTML, by the way. So as you may understand your point is moot. > Every web framework is _literally_ a hack to make the web something it isn’t. You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedurally. Updating only specific elements or branches of a DOM is a very basic usecases. In fact if you had any frontend experience at all you'd be aware that all mainstream GUI frameworks, including desktop, represent their UIs with a DOM. So here you are trying to argue that frontend development is not frontend development just because you have an irrational axe to grind regarding a specific class of web development technologies? > For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. If you hadn't already proven you are completely ignorant and detached from reality, this argument alone would leave no room for doubt.
  - tucnak 1y ago
    Thanks for dissecting all this nonsense. Although in all honesty, we may as well be dealing with comedy here: green account, recommending PHP and Rails in 2025 as if that's supposed to solve anything... we're being trolled.
- weego 1y ago
  Every web framework is _literally_ a hack to make the web something it isn’t This sentence is doing an awful lot of heavy lifting that doesn't fit with reality
  - cjonas 1y ago
    Ya this is nonsense. The web is what it is. You could maybe say "every framework is a hack to workaround protocols primarily designed in the 90's before we really understood the full application of the web"
    - goatlover 1y ago
      The internet isn't the web, and there are plenty of applications who use those protocols just fine outside of the web browser. It's the html tech stack initially made for hypertext documents and resources that's been heavily upgraded to do web-based applications.
      - deleted 1y ago
        [deleted]
    - m_fayer 1y ago
      I would go as far as saying that the genius of the web is that it can grow, develop, be hacked, modified, expanded through technical and institutional means to be many things it wasn’t originally envisioned to be. Why is that a bad thing? Why is originalism a good thing?
- tossandthrow 1y ago
  > Every web framework is _literally_ a hack to make the web something it isn't. Not this old grumpy person take again. Yes, the web is developing beyond delivering html content.
deleted 1y ago
[deleted]
j0rd72 1y ago
I find myself agreeing with the article (although I also agree that it assumes you've chosen an SPA when you shouldn't have). To add my own perspective: I work on an app, the front-end of which essentially consists of 6 nav tabs, 3 of which show an index of records with corresponding add/edit forms. We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React. Yesterday, I needed to add 1 new field (representing by a checkbox input) to both our app and a corresponding back-end application we have, which uses Rails views. I checked the git logs after to see how long each took. The Rails view took me literally 2 minutes to update (add field to model, add field to controller, add input to HAML with a class on the parent div). The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model. Is this a problem with React itself? Not really. But it's a problem in the way that it's used, and our 6 nav tabs and 3 forms don't need all the overhead of React. So for people in a similar situation, this article really rings true.
- wredcoll 1y ago
  People absolutely use technologies poorly and make things harder than they should be. At the same time, the part of the program that interfaces with the physical world (e.g., people) is always going to be far more complex and thus harder than the bits that get to live entirely inside the computer world.
- thefreeman 1y ago
  Just because you are comfortable with one technology and inexperienced or unfamiliar with another does not make one better than the other. How much rails have you written in your career? How much react?
- dinfinity 1y ago
  > Is this a problem with React itself? React is far from the best tool for most jobs (if any), but it has a shitload of inertia. I can highly recommend looking into Lit (used to be Polymer): https://lit.dev/docs/ https://lit.dev/docs/ IMHO it allows just the right amount of encapsulation and structure, whilst building on W3C web components and being highly interoperable with other javascript libraries/vanilla code. It's pretty much what web components should be out of the box.
psychoslave 1y ago
That is considering that front end dev is necessarily implying js, which is exactly the erroneous premise one should try to dodge.
wredcoll 1y ago
> Non-JS developers mystified and irritated at a bunch of practices they've never really internalised My current explanation goes something like this: "I'm a smart guy. Front end development looks simple. If I find it hard to do, that must be the fault of javascript somehow"
- abustamam 1y ago
  I started my career in FE and still consider myself a FE dev despite technically being a full stack dev. Sometimes I'd be working with my team on something and they'd be like "why is this needed?" and I'm like "because javascript" or "because react." While I agree with your sentiment that FE dev is certainly not simple, JS and front end architecture ad a whole does have its faults. That's why highly skilled FE devs who can build scalable, beautiful FE apps (whether using SPA or SSR) can be highly paid.
- dataflow 1y ago
  Note those are not mutually exclusive. It's entirely coherent to believe you find a tool hard to use for reasons relating to the tool itself, and that the task you're trying to accomplish is also difficult independently of that. Analogy: imagine trying to give a good presentation with a horrible text-to-speech (or translation) system. Just because good presentations are hard that doesn't mean you don't get to complain about the program being terrible.
  - wredcoll 1y ago
    Yes, but now you're getting into "there are two types of languages, the ones people complain about and the ones nobody uses". There are obviously flaws and issues and annoyances in js world, but a lot of those come from having to solve much harder problems (compared to say, do a sql query and turn the results into json).
    - vanviegen 1y ago
      I'll bite. In essence a user interface just presents the data it got from the server in some nice looking shape, and sends any edits and button presses back. Should be simple, right?
computerthings 1y ago
[dead]
benreesman 1y ago
I don't know that there's "real" programming, that seems like a hard fight to fight on either side, it's like arguing about whether animals are conscious or something. Are people? Who knows, pass the blunt. But there's been this really sharp over-correction to where now an obvious thing that is just common knowledge and that was never taboo is now considered impolite to even allude to. Frontend programming is among the easier kinds of software work as measured by the number of people who can do it? I bet if I tried really hard, I could probably be pretty kickass at pickleball, small court, not a lot moving around. But to be like, that's the same thing as the NFL. No, no it's not. I would never have been able to try out for the NFL, not if I live a thousand times. There's pickleball and pro football in programming too.
- christophilus 1y ago
  > as measured by the number of people who can do it That’s a poor measure. It proves only that there’s a demand for such programming. I have programmed in tens of languages professionally and many more for fun. Programming is programming. I haven’t found much difference in difficulty between any of the stacks I’ve worked with. Except, maybe C++, but that’s just C++ being garbage. I now happily use Zig as an alternative, and it’s no more difficult— easier in fact— than building a well-architected, complex UI application of any kind.
- suzzer99 1y ago
  Front-end programming is easier in the sense that you can make little mistakes and your entire app doesn't fall down. As someone who's done decades of both, there's nothing conceptually easier about well-executed front-end programming over back-end. The stakes just aren't as high.
  - gmadsen 1y ago
    I think the argument might be that it takes less domain knowledge of hardware and all its abstractions, which does require a minimum threshold of reasoning and abstract thinking ability. I have high confidence someone who could built a database or kernel could also do front end work with a reasonable ramp up time. I don’t share that confidence for the inverse in the nominal case
TacticalCoder 1y ago
[dead]
reactordev 1y ago
I don’t know, I think reducing bundle sizes and bloated javascript in favor of built in support for view transitions warranted a blog post against one of the primary arguments for why SPA. I agree with the author. I love React. I shouldn’t need two dozen more dependencies. We ditched server side for client side in 2010 for speed. Now that we have 200x more compute power, more powerful CSS, more robust html (with web components), we can go back to server side rendering and only send what’s required for the user at the time of action.
mdavidn 1y ago
Some of us have been building web apps since before Node.js existed, and we remember the problem that CSS was invented to solve.
hasanhaja 1y ago
Are we aligned with the claims in the article that a SPA architecture is not a suitable baseline architecture for content-focused sites with shallow sessions (low number of interactions)?

cleoxjefbjxis 1y ago

You miss the whole point and the author is correct about this: Modern CSS is powerful, and HTML is the way to deliver web content. Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice. For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll minimize it.

zero_shift 1y ago
Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system). What I find interesting though is the assumption that web dev is done by "JavaScript people", that even the best "JavaScript people" have no technical breadth, and therefore fester in a cesspool of bad ideas, unlike your median backend dev who swims in the azure lakes of programming wisdom. Now, I've done plenty of SPAs, but I've also done plenty of other things (distributed systems, WebVR apps, metaprogramming tools, DSLs, CLIs, STB software, mobile apps, a smidgeon of embedded and hobbyist PSOne games). Which gives me the benefit of a generalist perspective. One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy. These groups all regard each other with contempt, even though they are largely addressing similar fundamental issues in different guises. It's a social dynamic as much as any technical one.
- PaulHoule 1y ago
  It’s connected with the questions around occupational licensing of programmers, unions, and similar structures which would not be so much about getting paid more but about getting quality up, squashing bullshit, and getting our quality of life up. Without a cohesive community, mutual respect, and recognition of a shared body of knowledge, we don’t have the solidarity to make it happen. As for Laravel, I’d say people were making complex applications (Ebay, Amazon, Yahoo) in 1999 —- Google Maps were better than Mapquest, which drew each image with a cgi-bin, but many SPA applications are form handling applications that could have been implemented with the IBM 360 and 3270 terminal. The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw. You need two handfuls of helper functions, for instance <? draw_select($options,$selected_options,$attributes) ?> to make forms which can be populated based on what’s already in your database. People never wrote down “the 15 helper functions” because they were too busy writing frameworks like Laravel and Ruby-on-Rails that did 20x more than you really needed. So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built. As for performance, web sites today really are bloated, it’s not just the ads and trackers, it’s shocking how big the <head/> of documents get when you are including three copies of the metadata. If you are just drawing a form and nothing else, it’s amazing how fast you can redraw the whole page —- if you are able to delete the junk, old school apps can be as fast as desktop apps on the LAN and still be snappy over mobile.
  - wredcoll 1y ago
    > The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw Yes, I was there, I wrote and used these pages. It sucked. Things are better now. > So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built. Building a form with zero user affordances is not difficult. It just isn't good. We absolutely know how the pyramids were built. You get a whole bunch of humans to move a very large amount of stone and then stack it up in a big pile. The reason nobody builds pyramids today is because we have better alternatives.
zwnow 1y ago
Even with Laravel you will write lots of Javascript unless you go for blade templates or that other templating thing. Javascript is also great for making the web interactive. Maybe the sheer amount of SPAs out there shows us what we really want from the web. Most things ppl use in their day to day life cant be built with HTML and CSS only
- brigandish 1y ago
  > Maybe the sheer amount of SPAs out there shows us what we really want from the web. A distribution and installation system that works on almost any device?
  - zwnow 1y ago
    Interactivity and a way to build experiences and applications. Not just passing documents back and forth
- esskay 1y ago
  What 'other' templating thing? I'm assuming you're likely talking about either Intertia or Livewire. Inertia's more geared towards SPAs than Livewire though. Most Laravel devs tend to use JS sparingly - not everything needs JS. Theres next to no reason why the vast majority of sites on the web would ever need to be heavily reliant on JS. Rendered HTML/CSS with JS being used sparingly for page functionality is a far better user experience. I'll never understand the obsession with JS for the sake of JS.
  - zwnow 1y ago
    Yea Livewire, couldn't think of the name.
graealex 1y ago
Are you aware that nowadays you can write SPAs in dozens of languages? It's an entirely different concept. It's certainly not the right technology for a news site, but days ago in a different place, there was for example the discussion about how an SPA and minimalistic API services fit a lot better with your average embedded device.
motorest 1y ago
> You miss the whole point and the author is correct about this: your comment is funny, because you are so wrong you aren't even aware how and why you are wrong. It's in "not even wrong" territory. I'll explain you why. > Modern CSS is powerful, and HTML is the way to deliver web content. Irrelevant. That's not why the world uses JavaScript frameworks. It seems you aren't even aware of the most basic reasons why the world migrated to SPAs. The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads. Also, classic old timey server-side rendered WebApps end up being far more complex to develop and maintain as you mix everything together and you are unable to have separation of concerns regarding how your platform is deployed and ran and how your frontend works. SPAs even allow your frontend team to go to the extent of handing your backend as if it was a third-party service, and some SPAs are even just that. There are plenty of CMSs out there which eliminate the need for a backend by providing all content needs through their commercial APIs. This makes webapppp projects greatly cheaper and simpler to finance and support as you can simply bother about developing and maintaining your SPA. Lastly, those JavaScript frameworks you're trying to criticize also use CSS and HTML, by the way. So as you may understand your point is moot. > Every web framework is _literally_ a hack to make the web something it isn’t. You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedurally. Updating only specific elements or branches of a DOM is a very basic usecases. In fact if you had any frontend experience at all you'd be aware that all mainstream GUI frameworks, including desktop, represent their UIs with a DOM. So here you are trying to argue that frontend development is not frontend development just because you have an irrational axe to grind regarding a specific class of web development technologies? > For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. If you hadn't already proven you are completely ignorant and detached from reality, this argument alone would leave no room for doubt.
- tucnak 1y ago
  Thanks for dissecting all this nonsense. Although in all honesty, we may as well be dealing with comedy here: green account, recommending PHP and Rails in 2025 as if that's supposed to solve anything... we're being trolled.
weego 1y ago
Every web framework is _literally_ a hack to make the web something it isn’t This sentence is doing an awful lot of heavy lifting that doesn't fit with reality
- cjonas 1y ago
  Ya this is nonsense. The web is what it is. You could maybe say "every framework is a hack to workaround protocols primarily designed in the 90's before we really understood the full application of the web"
  - goatlover 1y ago
    The internet isn't the web, and there are plenty of applications who use those protocols just fine outside of the web browser. It's the html tech stack initially made for hypertext documents and resources that's been heavily upgraded to do web-based applications.
    - deleted 1y ago
      [deleted]
  - m_fayer 1y ago
    I would go as far as saying that the genius of the web is that it can grow, develop, be hacked, modified, expanded through technical and institutional means to be many things it wasn’t originally envisioned to be. Why is that a bad thing? Why is originalism a good thing?
tossandthrow 1y ago
> Every web framework is _literally_ a hack to make the web something it isn't. Not this old grumpy person take again. Yes, the web is developing beyond delivering html content.

deleted 1y ago

[deleted]

j0rd72 1y ago

I find myself agreeing with the article (although I also agree that it assumes you've chosen an SPA when you shouldn't have). To add my own perspective: I work on an app, the front-end of which essentially consists of 6 nav tabs, 3 of which show an index of records with corresponding add/edit forms. We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React. Yesterday, I needed to add 1 new field (representing by a checkbox input) to both our app and a corresponding back-end application we have, which uses Rails views. I checked the git logs after to see how long each took. The Rails view took me literally 2 minutes to update (add field to model, add field to controller, add input to HAML with a class on the parent div). The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model. Is this a problem with React itself? Not really. But it's a problem in the way that it's used, and our 6 nav tabs and 3 forms don't need all the overhead of React. So for people in a similar situation, this article really rings true.

wredcoll 1y ago
People absolutely use technologies poorly and make things harder than they should be. At the same time, the part of the program that interfaces with the physical world (e.g., people) is always going to be far more complex and thus harder than the bits that get to live entirely inside the computer world.
thefreeman 1y ago
Just because you are comfortable with one technology and inexperienced or unfamiliar with another does not make one better than the other. How much rails have you written in your career? How much react?
dinfinity 1y ago
> Is this a problem with React itself? React is far from the best tool for most jobs (if any), but it has a shitload of inertia. I can highly recommend looking into Lit (used to be Polymer): https://lit.dev/docs/ https://lit.dev/docs/ IMHO it allows just the right amount of encapsulation and structure, whilst building on W3C web components and being highly interoperable with other javascript libraries/vanilla code. It's pretty much what web components should be out of the box.

psychoslave 1y ago

That is considering that front end dev is necessarily implying js, which is exactly the erroneous premise one should try to dodge.

wredcoll 1y ago

> Non-JS developers mystified and irritated at a bunch of practices they've never really internalised My current explanation goes something like this: "I'm a smart guy. Front end development looks simple. If I find it hard to do, that must be the fault of javascript somehow"

abustamam 1y ago
I started my career in FE and still consider myself a FE dev despite technically being a full stack dev. Sometimes I'd be working with my team on something and they'd be like "why is this needed?" and I'm like "because javascript" or "because react." While I agree with your sentiment that FE dev is certainly not simple, JS and front end architecture ad a whole does have its faults. That's why highly skilled FE devs who can build scalable, beautiful FE apps (whether using SPA or SSR) can be highly paid.
dataflow 1y ago
Note those are not mutually exclusive. It's entirely coherent to believe you find a tool hard to use for reasons relating to the tool itself, and that the task you're trying to accomplish is also difficult independently of that. Analogy: imagine trying to give a good presentation with a horrible text-to-speech (or translation) system. Just because good presentations are hard that doesn't mean you don't get to complain about the program being terrible.
- wredcoll 1y ago
  Yes, but now you're getting into "there are two types of languages, the ones people complain about and the ones nobody uses". There are obviously flaws and issues and annoyances in js world, but a lot of those come from having to solve much harder problems (compared to say, do a sql query and turn the results into json).
  - vanviegen 1y ago
    I'll bite. In essence a user interface just presents the data it got from the server in some nice looking shape, and sends any edits and button presses back. Should be simple, right?

computerthings 1y ago

[dead]

benreesman 1y ago

I don't know that there's "real" programming, that seems like a hard fight to fight on either side, it's like arguing about whether animals are conscious or something. Are people? Who knows, pass the blunt. But there's been this really sharp over-correction to where now an obvious thing that is just common knowledge and that was never taboo is now considered impolite to even allude to. Frontend programming is among the easier kinds of software work as measured by the number of people who can do it? I bet if I tried really hard, I could probably be pretty kickass at pickleball, small court, not a lot moving around. But to be like, that's the same thing as the NFL. No, no it's not. I would never have been able to try out for the NFL, not if I live a thousand times. There's pickleball and pro football in programming too.

christophilus 1y ago
> as measured by the number of people who can do it That’s a poor measure. It proves only that there’s a demand for such programming. I have programmed in tens of languages professionally and many more for fun. Programming is programming. I haven’t found much difference in difficulty between any of the stacks I’ve worked with. Except, maybe C++, but that’s just C++ being garbage. I now happily use Zig as an alternative, and it’s no more difficult— easier in fact— than building a well-architected, complex UI application of any kind.
suzzer99 1y ago
Front-end programming is easier in the sense that you can make little mistakes and your entire app doesn't fall down. As someone who's done decades of both, there's nothing conceptually easier about well-executed front-end programming over back-end. The stakes just aren't as high.
- gmadsen 1y ago
  I think the argument might be that it takes less domain knowledge of hardware and all its abstractions, which does require a minimum threshold of reasoning and abstract thinking ability. I have high confidence someone who could built a database or kernel could also do front end work with a reasonable ramp up time. I don’t share that confidence for the inverse in the nominal case

TacticalCoder 1y ago

[dead]

reactordev 1y ago

I don’t know, I think reducing bundle sizes and bloated javascript in favor of built in support for view transitions warranted a blog post against one of the primary arguments for why SPA. I agree with the author. I love React. I shouldn’t need two dozen more dependencies. We ditched server side for client side in 2010 for speed. Now that we have 200x more compute power, more powerful CSS, more robust html (with web components), we can go back to server side rendering and only send what’s required for the user at the time of action.

mdavidn 1y ago

Some of us have been building web apps since before Node.js existed, and we remember the problem that CSS was invented to solve.

hasanhaja 1y ago

Are we aligned with the claims in the article that a SPA architecture is not a suitable baseline architecture for content-focused sites with shallow sessions (low number of interactions)?