4 ms·

> Well done, modern devs! A plain .html file does that And then if you want to take that rendered data and do anything interactive with it you have some js sou

by cyral 4y ago

> Well done, modern devs! A plain .html file does that And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloaded once (and we can send the initial data with it), and then it can become interactive from there. e.g. if the data needs to be reloaded we can make a small JSON request instead of reloading the whole page and re-rendering it.

marcosdumay 4y ago
There is nothing wrong with parseInt(document.getQuerySelector(".item > .item__quantity"), except for it not being parseInt(document.getElementById("uniqueAutogeneratedId")). Developers just shouldn't write that kind of fragile code by hand. But there's nothing wrong at all with the code being there.
- bmikaili 4y ago
  That is literally fragile code. You contradict yourself. I really want to see any of the people that hate on modern frameworks build any complex web app in a reasonable amount of time with the same level of stability as using i.e. SvelteKit
  - marcosdumay 4y ago
    As a rule, every code that people actually run is fragile. A small change could break anything, and there are almost no safety checks. Things only work because it's not people that create it.
  - revskill 4y ago
    Two way binding is the future ?
unity1001 4y ago
> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place And that's what most of the web needs - few use cases require having to manipulate every bit of the dom to send constant updates to the end-user. Social networks, financial sites, banks, betting sites etc. The rest do not need these heavy frameworks and the extensive dom manipulating capability. The last thing you want in an ecommerce checkout process is to distract the user by manipulating the dom to give him 'updates'. So nobody does anything like updating the user with info like 'latest prices', 'your friend just bought this' etc right in the middle of the checkout process. Same goes for blogs, most of publishing.
- cyral 4y ago
  I love nothing more than clicking “remove from cart” and having the whole page refresh and lose the info that was already typed
  - unity1001 4y ago
    That can be sorted by a single jQuery or JS function. 2-3 functions in that cart page handles everything without any complication whatsoever.
    - tiagod 4y ago
      I don't understand how jQuery and direct DOM manipulation is in any way better than something like Svelte for a modern Web app, especially something like a store.
      - unity1001 4y ago
        Because what most websites, ecommerce stores need per any given view/page are a few unique, isolated jQuery functions to manipulate what is strictly necessary. Be it listing a category listing of products, be it adding to cart by clicking a button, be it updating quantities in cart, address or payment. The 'modern' frontend frameworks take way too much after frameworks like React that were born from social networks in the inception of the social network age a decade ago. Facebook needed to have people poke each other, like posts and comment under them, while at the same time incrementing like, poke counters, as well as listing and updating a crap ton of friends, page and group listings on the sidebars, notifications and inboxes at the top and in the bottom bars and a whole lot of other stuff. So while, say, for example React solved a major problem with there not being a major templating system or logic in the front end up until then, it also brought it with the baggage of the mentality which assumes that we need that kind of dom manipulation at any given time. True, one can indeed use something like React and keep it minimal like in the shopping cart example above. But it rarely happens so and instead even the business logic starts seeping into the front end. The time when social networks exploded and such extensive DOM manipulation became 'cool' as a result, was a time in which the frontend was stuck in between Flash and the emerging jQuery/JS mess that some preferred instead of Flash to make websites 'modern/cool'. It was 'professional' for sites and apps to interact with users back in the early internet. Flash was used for it, then it became uncool as the web moved to jQuery, JS etc. Social networks exploded right in the middle of this transition, amplifying this trend. You wanted a 'modern' website that had moving parts. Not a plain HTML + simple CSS + JS website even if it loaded fast. Every widget and form had to be active, interactive and do stuff. Facebook was !all! the rage in that period, and everyone literally imitated them in everything they do, including tech stack and practices. Then Twitter also amplified the trend. Everything added up on it, and we ended up with the frontend mess where we tend to shove everything and then complain about complexity...
10000truths 4y ago
> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. Nothing stops a dev from providing both a server-side render and an API endpoint, for those that don't want the JS soup. In fact, such a design is not uncommon, and it's fairly straightforward to write a backend interface that both the server-side rendered endpoint handler and the API endpoint handler can use. > HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloaded once (and we can send the initial data with it), and then it can become interactive from there. e.g. if the data needs to be reloaded we can make a small JSON request instead of reloading the whole page and re-rendering it. The "smart" thing to do depends on what your requirements are. For minimal latency, server-side rendering tends to fare much better, as it requires only one round trip to fetch all the necessary information to render the page contents.

by cyral 4y ago

marcosdumay 4y ago

There is nothing wrong with parseInt(document.getQuerySelector(".item > .item__quantity"), except for it not being parseInt(document.getElementById("uniqueAutogeneratedId")). Developers just shouldn't write that kind of fragile code by hand. But there's nothing wrong at all with the code being there.

bmikaili 4y ago
That is literally fragile code. You contradict yourself. I really want to see any of the people that hate on modern frameworks build any complex web app in a reasonable amount of time with the same level of stability as using i.e. SvelteKit
- marcosdumay 4y ago
  As a rule, every code that people actually run is fragile. A small change could break anything, and there are almost no safety checks. Things only work because it's not people that create it.
- revskill 4y ago
  Two way binding is the future ?

unity1001 4y ago

> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place And that's what most of the web needs - few use cases require having to manipulate every bit of the dom to send constant updates to the end-user. Social networks, financial sites, banks, betting sites etc. The rest do not need these heavy frameworks and the extensive dom manipulating capability. The last thing you want in an ecommerce checkout process is to distract the user by manipulating the dom to give him 'updates'. So nobody does anything like updating the user with info like 'latest prices', 'your friend just bought this' etc right in the middle of the checkout process. Same goes for blogs, most of publishing.

cyral 4y ago
I love nothing more than clicking “remove from cart” and having the whole page refresh and lose the info that was already typed
- unity1001 4y ago
  That can be sorted by a single jQuery or JS function. 2-3 functions in that cart page handles everything without any complication whatsoever.
  - tiagod 4y ago
    I don't understand how jQuery and direct DOM manipulation is in any way better than something like Svelte for a modern Web app, especially something like a store.
    - unity1001 4y ago
      Because what most websites, ecommerce stores need per any given view/page are a few unique, isolated jQuery functions to manipulate what is strictly necessary. Be it listing a category listing of products, be it adding to cart by clicking a button, be it updating quantities in cart, address or payment. The 'modern' frontend frameworks take way too much after frameworks like React that were born from social networks in the inception of the social network age a decade ago. Facebook needed to have people poke each other, like posts and comment under them, while at the same time incrementing like, poke counters, as well as listing and updating a crap ton of friends, page and group listings on the sidebars, notifications and inboxes at the top and in the bottom bars and a whole lot of other stuff. So while, say, for example React solved a major problem with there not being a major templating system or logic in the front end up until then, it also brought it with the baggage of the mentality which assumes that we need that kind of dom manipulation at any given time. True, one can indeed use something like React and keep it minimal like in the shopping cart example above. But it rarely happens so and instead even the business logic starts seeping into the front end. The time when social networks exploded and such extensive DOM manipulation became 'cool' as a result, was a time in which the frontend was stuck in between Flash and the emerging jQuery/JS mess that some preferred instead of Flash to make websites 'modern/cool'. It was 'professional' for sites and apps to interact with users back in the early internet. Flash was used for it, then it became uncool as the web moved to jQuery, JS etc. Social networks exploded right in the middle of this transition, amplifying this trend. You wanted a 'modern' website that had moving parts. Not a plain HTML + simple CSS + JS website even if it loaded fast. Every widget and form had to be active, interactive and do stuff. Facebook was !all! the rage in that period, and everyone literally imitated them in everything they do, including tech stack and practices. Then Twitter also amplified the trend. Everything added up on it, and we ended up with the frontend mess where we tend to shove everything and then complain about complexity...

10000truths 4y ago

> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. Nothing stops a dev from providing both a server-side render and an API endpoint, for those that don't want the JS soup. In fact, such a design is not uncommon, and it's fairly straightforward to write a backend interface that both the server-side rendered endpoint handler and the API endpoint handler can use. > HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloaded once (and we can send the initial data with it), and then it can become interactive from there. e.g. if the data needs to be reloaded we can make a small JSON request instead of reloading the whole page and re-rendering it. The "smart" thing to do depends on what your requirements are. For minimal latency, server-side rendering tends to fare much better, as it requires only one round trip to fetch all the necessary information to render the page contents.