5 ms·

I don't understand why all the arguments around frontend stacks on the web are treated with such dogma - it's a tradeoff space! You can send JSON, HTML, or what

by klysm 3y ago

I don't understand why all the arguments around frontend stacks on the web are treated with such dogma - it's a tradeoff space! You can send JSON, HTML, or whatever, but it depends on _what you are building_. The decision about what tools to use is nuanced, and difficult, and most importantly vastly depends on the context of what you are trying to accomplish.

endisneigh 3y ago
There really is no incentive. I remember intercoolerjs a long while ago. People love arguing over nothing instead of picking a stack and shipping.
- hnrodey 3y ago
  >People love arguing over nothing instead of picking a stack and shipping. The most valuable code is the code that runs in production.
  - blowski 3y ago
    That’s an oft-quoted aphorism, but it’s not always true. Sometimes, the piece of crap you’ve just deployed becomes somebody else’s support and maintenance nightmare. With a bit more care, it could be avoided. Other times, the piece of crap was just what was needed, nothing more. It’s important to think about the right solution, and it’s also important to know when and why you’re putting something into production. Golden mean and all that.
- klysm 3y ago
  That’s one way to deal with the trade off space - pick one and send it. Sometimes it even makes sense due to other constraints: the best technology for the task may not be the best technology to choose! If you can shoehorn something you have experience with then it might be worth it.
lordgroff 3y ago
Yep. I have a Woocommerce site that's mostly modified by my own custom plugins. Most of my own custom work plugs in to the old school PHP server side rendering and that works just fine. I also have what's in effect two separate SPAs in the backend. Doing these in htmx and Alpine or whatever would be an absolutely enormous headache and it would perform worse. There's no one size fits all.
WD-42 3y ago
The key there is what you are building. The problem is that people who aren't aware or don't have appealing alternatives will still build a full SPA for something simple like a blog. This just makes the internet a worse place. It's frameworks like this that are trying to capture that audience, I think. AFAIK there is still nothing comparable to Rails/Django in the Javascript world.
- gedy 3y ago
  > The key there is what you are building. The problem is that people who aren't aware or don't have appealing alternatives will still build a full SPA for something simple like a blog. In fairness, most of my experience in past 10 years is dealing with companies trying to fake SPA style apps in blog-style server side frameworks. Maybe it's gotten better very recently, but Rails+jQuery mess is not better if folks really want a SPA-style app and interactions.
  - stephenhuey 3y ago
    It has. Among the 4 production B2B Rails apps I've been adding features to in the past year, the only one using jQuery was created 13 years ago. None of the others ever used jQuery, and using Hotwire Turbo to replicate SPA functionality is easy nowadays. One of the Rails apps serves a Flutter mobile client on the front-end, and as much as I appreciate all the lifting Flutter does for me, the sheer amount of code required to support that is enormous and laborious in comparison to writing a few Turbo frame tags in the fullstack Rails app. If not for a few gotchas that the client app needed, that mobile app would have been done with Jumpstart Pro iOS & Android with Turbo Native (great code reuse potential). Users of Rails apps leveraging Turbo frames or streams don't think those apps feel more shiny and cool and performant than legacy SPA frameworks such as React, and the modern Rails developers spend less time churning out code.
- klysm 3y ago
  I’ve seen it done poorly in both directions: blogs with SPAs and people trying to build SPAs with MVC frameworks.
bee_rider 3y ago
Some of the tradeoffs are paid more by different parties. For example, sending out scripts instead of content was (presumably? I don’t do webdev) easier for the developers. But it has a cost to the customers (wasting battery, starting up this crazy ecosystem where the expectation is we’ll just download scripts from the internet and run them). When only one side pays the price, I think it isn’t that surprising that it gets dogmatic. Because there isn’t any trade off, really, for me as a user, getting scripts is simply bad, and getting plain old documents is simply good. Where’s the nuance or tradeoff? I don’t care if setting up a static site generator takes more time or is harder or whatever, I only see the output, which is obviously better in one case. In the case of web devs talking to web devs, I’m not sure, having not been in that room. But from an outsider point of view, it seems like some sites care about this sort of thing and others just don’t. Maybe which parties are included in the cost calculation is basically an axiom, not really something that can be logic-ed out, and so it tends toward dogmatism and statements of preference? (hopefully I’ve accurately represented the fact that this is 100% a comment from the user point of view, so heap of salt and all that).
- joshuaissac 3y ago
  > I don’t care if setting up a static site generator takes more time or is harder or whatever, I only see the output, which is obviously better in one case. Don't these static site generators serve the scripts that you do not like? On a statically-generated site, the dynamism of the site is in the script and is evaluated in your browser. On a non-static site, the server does the evaluation, so your browser does not have to run as many scripts for the same level of dynamism.
  - throwbadubadu 3y ago
    Nope, you got it mixed around..
  - foolswisdom 3y ago
    Sounds like you're using the concept of statically served files vs dynamically generated, but that's a different conversation to whether content files are generated at all.

by klysm 3y ago

endisneigh 3y ago

There really is no incentive. I remember intercoolerjs a long while ago. People love arguing over nothing instead of picking a stack and shipping.

hnrodey 3y ago
>People love arguing over nothing instead of picking a stack and shipping. The most valuable code is the code that runs in production.
- blowski 3y ago
  That’s an oft-quoted aphorism, but it’s not always true. Sometimes, the piece of crap you’ve just deployed becomes somebody else’s support and maintenance nightmare. With a bit more care, it could be avoided. Other times, the piece of crap was just what was needed, nothing more. It’s important to think about the right solution, and it’s also important to know when and why you’re putting something into production. Golden mean and all that.
klysm 3y ago
That’s one way to deal with the trade off space - pick one and send it. Sometimes it even makes sense due to other constraints: the best technology for the task may not be the best technology to choose! If you can shoehorn something you have experience with then it might be worth it.

lordgroff 3y ago

Yep. I have a Woocommerce site that's mostly modified by my own custom plugins. Most of my own custom work plugs in to the old school PHP server side rendering and that works just fine. I also have what's in effect two separate SPAs in the backend. Doing these in htmx and Alpine or whatever would be an absolutely enormous headache and it would perform worse. There's no one size fits all.

WD-42 3y ago

The key there is what you are building. The problem is that people who aren't aware or don't have appealing alternatives will still build a full SPA for something simple like a blog. This just makes the internet a worse place. It's frameworks like this that are trying to capture that audience, I think. AFAIK there is still nothing comparable to Rails/Django in the Javascript world.

gedy 3y ago
> The key there is what you are building. The problem is that people who aren't aware or don't have appealing alternatives will still build a full SPA for something simple like a blog. In fairness, most of my experience in past 10 years is dealing with companies trying to fake SPA style apps in blog-style server side frameworks. Maybe it's gotten better very recently, but Rails+jQuery mess is not better if folks really want a SPA-style app and interactions.
- stephenhuey 3y ago
  It has. Among the 4 production B2B Rails apps I've been adding features to in the past year, the only one using jQuery was created 13 years ago. None of the others ever used jQuery, and using Hotwire Turbo to replicate SPA functionality is easy nowadays. One of the Rails apps serves a Flutter mobile client on the front-end, and as much as I appreciate all the lifting Flutter does for me, the sheer amount of code required to support that is enormous and laborious in comparison to writing a few Turbo frame tags in the fullstack Rails app. If not for a few gotchas that the client app needed, that mobile app would have been done with Jumpstart Pro iOS & Android with Turbo Native (great code reuse potential). Users of Rails apps leveraging Turbo frames or streams don't think those apps feel more shiny and cool and performant than legacy SPA frameworks such as React, and the modern Rails developers spend less time churning out code.
klysm 3y ago
I’ve seen it done poorly in both directions: blogs with SPAs and people trying to build SPAs with MVC frameworks.

bee_rider 3y ago

Some of the tradeoffs are paid more by different parties. For example, sending out scripts instead of content was (presumably? I don’t do webdev) easier for the developers. But it has a cost to the customers (wasting battery, starting up this crazy ecosystem where the expectation is we’ll just download scripts from the internet and run them). When only one side pays the price, I think it isn’t that surprising that it gets dogmatic. Because there isn’t any trade off, really, for me as a user, getting scripts is simply bad, and getting plain old documents is simply good. Where’s the nuance or tradeoff? I don’t care if setting up a static site generator takes more time or is harder or whatever, I only see the output, which is obviously better in one case. In the case of web devs talking to web devs, I’m not sure, having not been in that room. But from an outsider point of view, it seems like some sites care about this sort of thing and others just don’t. Maybe which parties are included in the cost calculation is basically an axiom, not really something that can be logic-ed out, and so it tends toward dogmatism and statements of preference? (hopefully I’ve accurately represented the fact that this is 100% a comment from the user point of view, so heap of salt and all that).

joshuaissac 3y ago
> I don’t care if setting up a static site generator takes more time or is harder or whatever, I only see the output, which is obviously better in one case. Don't these static site generators serve the scripts that you do not like? On a statically-generated site, the dynamism of the site is in the script and is evaluated in your browser. On a non-static site, the server does the evaluation, so your browser does not have to run as many scripts for the same level of dynamism.
- throwbadubadu 3y ago
  Nope, you got it mixed around..
- foolswisdom 3y ago
  Sounds like you're using the concept of statically served files vs dynamically generated, but that's a different conversation to whether content files are generated at all.