4 ms·

The article started with showing how complex the frontend is. And then moves the complexity to the backend, with tools that aren’t well supported and putting ex

by edwinjm 5mo ago

The article started with showing how complex the frontend is. And then moves the complexity to the backend, with tools that aren’t well supported and putting extra load on the server. For some applications, this is a good solution, for most, however, it’s not.

jacques_chester 5mo ago
> with tools that aren’t well supported This is an odd thing to say about the backend choices. Spring is ... well let's just say there are a few folks in and around that area.
- YmiYugy 5mo ago
  I think it's totally fair, but I would assume that most Spring projects make significant DX tradeoffs compared to a full JS stack or serve an API rather than html. 1. Spring + Handlebars: You can either write the html template in a string loosing syntax highlighting and other LSP stuff, load it from a file loosing colocation. 2. Handlebars + webcomponents. They simply bundle all the web components into a single file, which breaks down when they get large and you don't need every component on every route. 3. Tailwind: Looking online you can get it working with spring boot, but the route chosen here is a script to run the cli, which again means every route ships every tailwind class used anywhere.
runako 5mo ago
> putting extra load on the server This is precisely where the publisher has the most control over the user experience. Putting load on the browser makes a user's experience dependent on their hardware & software stack.
- YmiYugy 5mo ago
  Part of what makes a good user experience is is working nicely with the users hardware and software stack and that's much easier on the client. The user would like the website to have native scroll physics, respect their system preferences, react to changing window sizes and with different input methods, screen readers and so on. If the key to a good user experience was server side control, than the hallmark of a good website would be being an RDP stream and prefers-color-scheme wouldn't be a CSS feature but a HTTP header.
  - runako 5mo ago
    > The user would like the website to have native scroll physics, respect their system preferences, react to changing window sizes and with different input methods, screen readers and so on. Yes, these are features implemented by every popular browser via HTML & CSS. Fancy front-end work frequently breaks these features. > key to a good user experience was server side control I think you're reading my comment from an extremely front-end perspective. I simply mean that where possible it's better to render pages and do logic on the server side versus on the client side. The same HTML + CSS is generated either way, the only question is what % of the work is done by the user's device vs what % is done in a data center.

by edwinjm 5mo ago

jacques_chester 5mo ago

> with tools that aren’t well supported This is an odd thing to say about the backend choices. Spring is ... well let's just say there are a few folks in and around that area.

YmiYugy 5mo ago
I think it's totally fair, but I would assume that most Spring projects make significant DX tradeoffs compared to a full JS stack or serve an API rather than html. 1. Spring + Handlebars: You can either write the html template in a string loosing syntax highlighting and other LSP stuff, load it from a file loosing colocation. 2. Handlebars + webcomponents. They simply bundle all the web components into a single file, which breaks down when they get large and you don't need every component on every route. 3. Tailwind: Looking online you can get it working with spring boot, but the route chosen here is a script to run the cli, which again means every route ships every tailwind class used anywhere.

runako 5mo ago

> putting extra load on the server This is precisely where the publisher has the most control over the user experience. Putting load on the browser makes a user's experience dependent on their hardware & software stack.

YmiYugy 5mo ago
Part of what makes a good user experience is is working nicely with the users hardware and software stack and that's much easier on the client. The user would like the website to have native scroll physics, respect their system preferences, react to changing window sizes and with different input methods, screen readers and so on. If the key to a good user experience was server side control, than the hallmark of a good website would be being an RDP stream and prefers-color-scheme wouldn't be a CSS feature but a HTTP header.
- runako 5mo ago
  > The user would like the website to have native scroll physics, respect their system preferences, react to changing window sizes and with different input methods, screen readers and so on. Yes, these are features implemented by every popular browser via HTML & CSS. Fancy front-end work frequently breaks these features. > key to a good user experience was server side control I think you're reading my comment from an extremely front-end perspective. I simply mean that where possible it's better to render pages and do logic on the server side versus on the client side. The same HTML + CSS is generated either way, the only question is what % of the work is done by the user's device vs what % is done in a data center.