3 ms·

In theory, the "modern" frontend frameworks could be useful for a subset of applications. In practice, they are wildly overused, largely (IMHO) because front-en

by runako 4y ago

In theory, the "modern" frontend frameworks could be useful for a subset of applications. In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them. If I gave this as an example, people would say I'm being unfair to the front-end folks. But since Deno posted it, I think it's fair say that it's overkill to use a front-end framework like React (mentioned as a comparator in TFA) to implement add to cart functionality on an e-commerce site. And that for users with slow browsers, slow/spotty Internet, etc., an architecture that uses a heavy front-end framework produces a worse overall experience than what most e-commerce sites were able to do in 1999. Edit: IMHO all of this is an artifact of mobile taking a front seat to the Web. So we end up with less-than-optimal Web experiences due to overuse of front-end JS everywhere; otherwise shops would have to build separate backends for mobile and Web. This, because an optimal Web backend tends to produce display-ready HTML instead of JSON for a browser-based client application to prepare for display. Directly reusing a mobile backend for Web browsers is suboptimal for most sites.

revskill 4y ago
There's always a "what if". What if you don't just stop at "adding a add to cart button" ?
- runako 4y ago
  Correct. The design tradeoff is dependent on knowing how much of a Lisp interpreter you need to build. For most sites, the answer is "none" and it's not worth degrading user experiences just in case your e-commerce site ends up needing the ability to also serve as a designer for Minecraft levels. (Even if it does, there is no requirement to ship the heavy JS needed for the Minecraft editor to all the e-commerce product description pages.)
teaearlgraycold 4y ago
IMO the big value add from React and friends is all of your rendering logic is in the same language and the same code base. I do not want to go back to templated HTML from Ruby/Java/PHP/whatever combined with ad hoc JS to handle whatever parts need to be dynamic. If you know your UI can be almost completely static (like with HN) then the trade-off from the old way is acceptable. But if you don't know where your site's going to go because you're a startup then it's hard to buy into old school SSR. NextJS, when done right, can be an acceptable 3rd option.
deleted 4y ago
[deleted]
horsawlarway 4y ago
> And that for users with slow browsers, slow/spotty Internet, etc., an architecture that uses a heavy front-end framework produces a worse overall experience than what most e-commerce sites were able to do in 1999. I think this is heavily dependent on company focus (and to some extent - the data requirements of the experience) Basically - I think you can create a much stronger, more compelling experience on a site for a person with a bad/slow connection with judicious usage of service_workers and a solid front end framework. But on the flip side... Making that experience isn't trivial, requires up front planning, and most companies won't do it.
devjab 4y ago
> In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them. I've been a "back-end" developer who sometimes does "front-end" stuff for a long time. Both with web tech going back to classic asp, web-forms and those Java beans for JSF or whatever it was called, and, with various gui-tools for C#, Java and Python, and I think one of the reasons people use the "front-end" tools you're talking about in 2023 is because all those other tools really sucked. I guess NextJS can also be server side rendering, but even when you just use it for React (with Typescript and organisation-wide linting and formating rules that can't be circumvented) it's just sooooo much easier than what came before it. Really, can you think of a nice application? Maybe it's because I've mostly worked in Enterprise organisations, but my oh my am I happy that I didn't have to work with any of the things people who aren't in digitalisation have to put up with. I think Excel is about the only non-web-based application that I've ever seen score well when they've been ranked. So there is also that to keep in mind.
411111111111111 4y ago
I started my webdev time with Django and flask, switched to Spring boot at the next job with various templating languages, depending on the artefact and some laravel sprinkled in. Finally, the employer decreed that moving forward all frontends had to be done in Angular (version 6 or 7 at that time) and I have to say... I don't understand the point you're trying to make. The frontend stacks aren't particularly more complex then the equivalent application done with html templates and varying ways to update the DOM. Personally I'd say they're easier, which is why UX also started to demand state changes to be animated etc, requests to be automatically retried and handle every potential error scenario, which was never even attempted with pure backend websites Nowadays I prefer using Typescript for anything html related and would not use backend templates unless the website is not going to be interactive
- runako 4y ago
  > I don't understand the point you're trying to make. > The frontend stacks aren't particularly more complex I'm not making a point about programmer experience at all. I'm saying that for most uses of most sites, the fact that Angular (or similar) is running in the user's browser is making the user experience worse. Performance is worse, accessibility can be worse, and so forth. And (again, for most uses of most sites) there is no benefit to the end user. Consider the blogs, brochureware sites, landing pages, and e-commerce product pages that absolutely don't need something like Angular that today nonetheless do include it. Most Web apps are much closer to those than to Google Earth, Facebook, or Spotify's Web player.

by runako 4y ago

revskill 4y ago

There's always a "what if". What if you don't just stop at "adding a add to cart button" ?

runako 4y ago
Correct. The design tradeoff is dependent on knowing how much of a Lisp interpreter you need to build. For most sites, the answer is "none" and it's not worth degrading user experiences just in case your e-commerce site ends up needing the ability to also serve as a designer for Minecraft levels. (Even if it does, there is no requirement to ship the heavy JS needed for the Minecraft editor to all the e-commerce product description pages.)

teaearlgraycold 4y ago

IMO the big value add from React and friends is all of your rendering logic is in the same language and the same code base. I do not want to go back to templated HTML from Ruby/Java/PHP/whatever combined with ad hoc JS to handle whatever parts need to be dynamic. If you know your UI can be almost completely static (like with HN) then the trade-off from the old way is acceptable. But if you don't know where your site's going to go because you're a startup then it's hard to buy into old school SSR. NextJS, when done right, can be an acceptable 3rd option.

deleted 4y ago

[deleted]

horsawlarway 4y ago

> And that for users with slow browsers, slow/spotty Internet, etc., an architecture that uses a heavy front-end framework produces a worse overall experience than what most e-commerce sites were able to do in 1999. I think this is heavily dependent on company focus (and to some extent - the data requirements of the experience) Basically - I think you can create a much stronger, more compelling experience on a site for a person with a bad/slow connection with judicious usage of service_workers and a solid front end framework. But on the flip side... Making that experience isn't trivial, requires up front planning, and most companies won't do it.

devjab 4y ago

> In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them. I've been a "back-end" developer who sometimes does "front-end" stuff for a long time. Both with web tech going back to classic asp, web-forms and those Java beans for JSF or whatever it was called, and, with various gui-tools for C#, Java and Python, and I think one of the reasons people use the "front-end" tools you're talking about in 2023 is because all those other tools really sucked. I guess NextJS can also be server side rendering, but even when you just use it for React (with Typescript and organisation-wide linting and formating rules that can't be circumvented) it's just sooooo much easier than what came before it. Really, can you think of a nice application? Maybe it's because I've mostly worked in Enterprise organisations, but my oh my am I happy that I didn't have to work with any of the things people who aren't in digitalisation have to put up with. I think Excel is about the only non-web-based application that I've ever seen score well when they've been ranked. So there is also that to keep in mind.

411111111111111 4y ago

I started my webdev time with Django and flask, switched to Spring boot at the next job with various templating languages, depending on the artefact and some laravel sprinkled in. Finally, the employer decreed that moving forward all frontends had to be done in Angular (version 6 or 7 at that time) and I have to say... I don't understand the point you're trying to make. The frontend stacks aren't particularly more complex then the equivalent application done with html templates and varying ways to update the DOM. Personally I'd say they're easier, which is why UX also started to demand state changes to be animated etc, requests to be automatically retried and handle every potential error scenario, which was never even attempted with pure backend websites Nowadays I prefer using Typescript for anything html related and would not use backend templates unless the website is not going to be interactive

runako 4y ago
> I don't understand the point you're trying to make. > The frontend stacks aren't particularly more complex I'm not making a point about programmer experience at all. I'm saying that for most uses of most sites, the fact that Angular (or similar) is running in the user's browser is making the user experience worse. Performance is worse, accessibility can be worse, and so forth. And (again, for most uses of most sites) there is no benefit to the end user. Consider the blogs, brochureware sites, landing pages, and e-commerce product pages that absolutely don't need something like Angular that today nonetheless do include it. Most Web apps are much closer to those than to Google Earth, Facebook, or Spotify's Web player.