4 ms·

One of the frontend problems is that too much frontend engineers think a web app should be a single page app. A lot of apps don't need to be that. Server-side e

One of the frontend problems is that too much frontend engineers think a web app should be a single page app. A lot of apps don't need to be that. Server-side endpoints and templating + lightweight vanilla JS and framework-agnostic web components works and is now even easier than ever.

emseetech 2y ago
I've seen so many marketing websites written in React. It's so confusing.
nsonha 2y ago
clear boundary is good, I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense. They are just shifting complexity from a place they feel uncomfortable, to where they do, but at the cost of destroying their own nirvana. Certainly one way, but hardly the only one.
- JodieBenitez 2y ago
  > I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense. Because the tooling has been here for decades and it works damn fine. No need to trash the frontend with ever changing piles of dependency and build nonsense.
  - nsonha 2y ago
    > works damn fine when? View code in the back-end always looks like crap and never able to achieve the interactivity the front-end can. People wrestling with it was the reason SPA was born. There was no dictator forcing people to move on from such "awesome" working "damn fine" pipelines to modern front-end for no reason.
    - ejflick 2y ago
      > View code in the back-end always looks like crap That's probably the fault of the people writing it. People can also write crap looking code using frameworks too. > and never able to achieve the interactivity the front-end can. That's what small sprinkles of javascript is for. You don't need incredibly beautiful interactivity in every pixel.
alex_suzuki 2y ago
It‘s a kind of collective hallucination. It‘s affected me too. I just recently decided to go back in time and wrote a web app using Flask, all rendered server side, with a minimum of JS and JSON endpoints for a bit of client-side interactivity (e.g. autocompleting an input field). Very fast, iterative work. No duplication of data classes, no weird caching issues… Felt like a breath of fresh air, sadly. Have we witnessed a full turn of the wheel?
- JodieBenitez 2y ago
  That's a good old case of "the right tool for the job". But let's be honest: the frontend dev rat race had the effect to make the base web technologies better. Better CSS (variables, nesting, effects, media support, etc), better JS (webcomponents), useful libs available as wasm and so on... all good things that can be used natively and allow us to make better MPAs.
foul 2y ago
Commercial-grade applications need some grade of offline operativity that classic HATEOAS can't provide, often target users who won't learn or can't really use a web browser (tabs, back button, extensions, bookmarks besides whatever they can fit in the bar, etc), often want to give a UX which abuses and deforms a web browser by design. Yeah, FE engineers may all look like dumbasses with macbooks (i don't think this of them!), but they have real problems to solve.
- JodieBenitez 2y ago
  Not denying that, but just because I browse the web I'm pretty sure not all websites with "modern" frontend stacks have modern frontend problems.
  - foul 2y ago
    That's for sure, for example any blog software (a few SSGs included) is a failure for WWW and for itself (most of the interaction between author and reader must be mediated with third-party or big cloud to avoid spam and scam).
shortrounddev2 2y ago
I think most people choose SPAs because they also maintain the frontend state of a an application. If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell. How do you manage the transition between one view and another on the same page? How do you pass state between two pages? I think webcomponents solve some of this but there's a lot of react developers out there who don't have the requisite software engineering skills to handle this
- consteval 2y ago
  > How do you manage the transition between one view and another on the same page? HTMX solves this, and it's mostly automatic. You get some nice transitions. > How do you pass state between two pages? You don't. You submit some data to the server, it generates HTML dynamically, you replace HTML on the frontend or redirect all together, you're done. The state is on the server.
  - shortrounddev2 2y ago
    So then you need some kind of state management on the server?
    - consteval 2y ago
      > So then you need some kind of state management on the server Yes. You might call this an application, lol. You will require this no matter what, unless you have a fully client-side application. Like photoshop or something.
- JodieBenitez 2y ago
  > If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell. How so ? Vanilla JS has never been easier and more powerful. > How do you pass state between two pages? Why is it even considered to be a problem ? This is basic stuff. All web frameworks since the 90s have had this concept of sessions where you can store data that will be available across pages.

emseetech 2y ago

I've seen so many marketing websites written in React. It's so confusing.

nsonha 2y ago

clear boundary is good, I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense. They are just shifting complexity from a place they feel uncomfortable, to where they do, but at the cost of destroying their own nirvana. Certainly one way, but hardly the only one.

JodieBenitez 2y ago
> I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense. Because the tooling has been here for decades and it works damn fine. No need to trash the frontend with ever changing piles of dependency and build nonsense.
- nsonha 2y ago
  > works damn fine when? View code in the back-end always looks like crap and never able to achieve the interactivity the front-end can. People wrestling with it was the reason SPA was born. There was no dictator forcing people to move on from such "awesome" working "damn fine" pipelines to modern front-end for no reason.
  - ejflick 2y ago
    > View code in the back-end always looks like crap That's probably the fault of the people writing it. People can also write crap looking code using frameworks too. > and never able to achieve the interactivity the front-end can. That's what small sprinkles of javascript is for. You don't need incredibly beautiful interactivity in every pixel.

alex_suzuki 2y ago

It‘s a kind of collective hallucination. It‘s affected me too. I just recently decided to go back in time and wrote a web app using Flask, all rendered server side, with a minimum of JS and JSON endpoints for a bit of client-side interactivity (e.g. autocompleting an input field). Very fast, iterative work. No duplication of data classes, no weird caching issues… Felt like a breath of fresh air, sadly. Have we witnessed a full turn of the wheel?

JodieBenitez 2y ago
That's a good old case of "the right tool for the job". But let's be honest: the frontend dev rat race had the effect to make the base web technologies better. Better CSS (variables, nesting, effects, media support, etc), better JS (webcomponents), useful libs available as wasm and so on... all good things that can be used natively and allow us to make better MPAs.

foul 2y ago

Commercial-grade applications need some grade of offline operativity that classic HATEOAS can't provide, often target users who won't learn or can't really use a web browser (tabs, back button, extensions, bookmarks besides whatever they can fit in the bar, etc), often want to give a UX which abuses and deforms a web browser by design. Yeah, FE engineers may all look like dumbasses with macbooks (i don't think this of them!), but they have real problems to solve.

JodieBenitez 2y ago
Not denying that, but just because I browse the web I'm pretty sure not all websites with "modern" frontend stacks have modern frontend problems.
- foul 2y ago
  That's for sure, for example any blog software (a few SSGs included) is a failure for WWW and for itself (most of the interaction between author and reader must be mediated with third-party or big cloud to avoid spam and scam).

shortrounddev2 2y ago

I think most people choose SPAs because they also maintain the frontend state of a an application. If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell. How do you manage the transition between one view and another on the same page? How do you pass state between two pages? I think webcomponents solve some of this but there's a lot of react developers out there who don't have the requisite software engineering skills to handle this

consteval 2y ago
> How do you manage the transition between one view and another on the same page? HTMX solves this, and it's mostly automatic. You get some nice transitions. > How do you pass state between two pages? You don't. You submit some data to the server, it generates HTML dynamically, you replace HTML on the frontend or redirect all together, you're done. The state is on the server.
- shortrounddev2 2y ago
  So then you need some kind of state management on the server?
  - consteval 2y ago
    > So then you need some kind of state management on the server Yes. You might call this an application, lol. You will require this no matter what, unless you have a fully client-side application. Like photoshop or something.
JodieBenitez 2y ago
> If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell. How so ? Vanilla JS has never been easier and more powerful. > How do you pass state between two pages? Why is it even considered to be a problem ? This is basic stuff. All web frameworks since the 90s have had this concept of sessions where you can store data that will be available across pages.