3 ms·

> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found int

> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload every time that there's a non-trivial state change (usually triggered by user interaction). When the inherent complexity of the application means that there are state changes pretty often, doing a page reload so often would just kill the user experience, and using jQuery or similar libraries would lead to a spaghetti. Is that the reason for client-side rendering being the "default" in the realm of modern javascript? If that's the actual reason, then that seems reasonable, but I think that Javascript culture (frameworks, tutorials, articles) usually erroneously assumes that every application is a complex one with tons of state changes, thus assuming that client-side rendering is the only right way to develop an application (without counting "isomorphic" SSR which is just another way to create a spaghetti). Sure, if I don't like it I can just move over to Django, Laravel, etc. but it feels like I never get an actual explanation of why client-side rendering is the default in these js frameworks, it's just accepted as a fact of life.

dinkleberg 5y ago
I can’t speak to the decisions on the parts of whoever is building the frameworks. But I will say the dev experience working on a frontend app using React, Vue, etc. is substantially greater than using something like Django templates. And I say that as someone who has written a great deal of both. I really wish I could be as productive in Django templates as I am with React, but alas. Once you go to component based UI development it is hard to go back. Especially when you get used to the high quality UI libraries.
- fuzzy2 5y ago
  But then maybe Django templates are not so great? You can also have UI components in the backend. Interactivity can be a little tricky though.
- christophilus 5y ago
  100%. Also, every web app I’ve worked on has accreted UI interactivity with time, and I often end up crossing the threshold where I wish I had started with a decent client-side framework.
- pjmlp 5y ago
  JSF and WebForms were already component based UIs 20 years ago, with page designers at development time, and 3rd party component vendors!
  - ryathal 5y ago
    Honestly I wouldn't be surprised if web forms could also provide a faster and more user friendly experience even with all the page loads than some SPAs.
    - pjmlp 5y ago
      It can indeed, and now there is Blazor as its replacement.
      - chrisweekly 4y ago
        Or https://Remix.run https://Remix.run
6510 5y ago
> The main reason for client-side rendering is that some web applications don't want to do a full page reload every time that there's a non-trivial state change (usually triggered by user interaction). If that is the reason (I don't know) some element other than <iframe> would be a much simpler solution. I had a few ideas just now. It seemed the most fascinating to tie part of the query string to a div. <humpalumpa cowabunga="foo" dartvader="foobariusmaximus"/> Then you have your usual <div id="foobariusmaximus"></div> And your url example.com/?foo=demo.html And from thereon <a href="?foo=second-demo.html"> shall only update that part of the url and that part of the document. If demo.html contains a <doctype><head><script> or <style> it is ignored if the target is a div. But something like <a href="?mycss=banana.css&myjavascript=kiwi.js"> with appropriate targets seems fine(?) Alternatively the querystring tie can be defined on the element. <div id="foobariusmaximus" cowabunga="foo"></div> Older browsers when hitting <a href="?foo=second-demo.html"> will load example.com/?foo=second-demo.html
- tored 5y ago
  Basically what turbolinks did.
  - 6510 5y ago
    Or what 99% of ajax did. What I really want to see is for html to work toward what people are actually doing with web pages. I basically want a lawnmower not a bag of parts that allows me to build my own. I know how to sort tables but I don't want to. I know how to dynamically xhr, display and insert auto complete values but I don't want to write it and I don't want the chunk of js on the page. I definitely don't want to load a library for it.
    - tored 5y ago
      Old <frameset> pages had its charm. You can still use it with HTML5! If I remember correctly was that screen readers sometimes had some difficulty handling a <frameset> page, especially if the were multiple <frame>s. <iframe> is also great, but hard to layout horizontally. And resizing can be tricky. And nowadays you don't even need your own event layer to talk between frames, you can use postMessage. But yes, agree, continue evolve <iframe> and such to become more usable.
tored 5y ago
One explanation could be that if you are a hammer everything looks like nail. One problem with web dev in general is that we have multiple backend technologies, thus creating a complete client and server rendering framework requires you to integrate it against multiple backend technologies. But if you assume that the best API is JSON over HTTP then you can completely ignore what makes sense from the perspective of the chosen backend technology.
fuzzy2 5y ago
IMHO, this isn’t about “Modern JavaScript” or “JavaScript Culture” at all. It’s just $CURRENT_THING and the Cargo Cult is happy to oblige. Futhermore, dev shops (like my employer) profit from selling overcomplicated solutions. So in the end it’s just group dynamics that drive the usual hype cycle. Remember MVVM?
- pjmlp 5y ago
  MVVM is pretty much alive in native frameworks, as it makes easy to write tests and share behaviours.
  - fuzzy2 5y ago
    I’m not saying it’s bad. You just have to know when to use it. But that’s how it is with any technology/library/framework/whatever. IIRC there was a “MVVM craze” back then, but that could’ve been my bubble.

dinkleberg 5y ago

I can’t speak to the decisions on the parts of whoever is building the frameworks. But I will say the dev experience working on a frontend app using React, Vue, etc. is substantially greater than using something like Django templates. And I say that as someone who has written a great deal of both. I really wish I could be as productive in Django templates as I am with React, but alas. Once you go to component based UI development it is hard to go back. Especially when you get used to the high quality UI libraries.

fuzzy2 5y ago
But then maybe Django templates are not so great? You can also have UI components in the backend. Interactivity can be a little tricky though.
christophilus 5y ago
100%. Also, every web app I’ve worked on has accreted UI interactivity with time, and I often end up crossing the threshold where I wish I had started with a decent client-side framework.
pjmlp 5y ago
JSF and WebForms were already component based UIs 20 years ago, with page designers at development time, and 3rd party component vendors!
- ryathal 5y ago
  Honestly I wouldn't be surprised if web forms could also provide a faster and more user friendly experience even with all the page loads than some SPAs.
  - pjmlp 5y ago
    It can indeed, and now there is Blazor as its replacement.
    - chrisweekly 4y ago
      Or https://Remix.run https://Remix.run

6510 5y ago

> The main reason for client-side rendering is that some web applications don't want to do a full page reload every time that there's a non-trivial state change (usually triggered by user interaction). If that is the reason (I don't know) some element other than <iframe> would be a much simpler solution. I had a few ideas just now. It seemed the most fascinating to tie part of the query string to a div. <humpalumpa cowabunga="foo" dartvader="foobariusmaximus"/> Then you have your usual <div id="foobariusmaximus"></div> And your url example.com/?foo=demo.html And from thereon <a href="?foo=second-demo.html"> shall only update that part of the url and that part of the document. If demo.html contains a <doctype><head><script> or <style> it is ignored if the target is a div. But something like <a href="?mycss=banana.css&myjavascript=kiwi.js"> with appropriate targets seems fine(?) Alternatively the querystring tie can be defined on the element. <div id="foobariusmaximus" cowabunga="foo"></div> Older browsers when hitting <a href="?foo=second-demo.html"> will load example.com/?foo=second-demo.html

tored 5y ago
Basically what turbolinks did.
- 6510 5y ago
  Or what 99% of ajax did. What I really want to see is for html to work toward what people are actually doing with web pages. I basically want a lawnmower not a bag of parts that allows me to build my own. I know how to sort tables but I don't want to. I know how to dynamically xhr, display and insert auto complete values but I don't want to write it and I don't want the chunk of js on the page. I definitely don't want to load a library for it.
  - tored 5y ago
    Old <frameset> pages had its charm. You can still use it with HTML5! If I remember correctly was that screen readers sometimes had some difficulty handling a <frameset> page, especially if the were multiple <frame>s. <iframe> is also great, but hard to layout horizontally. And resizing can be tricky. And nowadays you don't even need your own event layer to talk between frames, you can use postMessage. But yes, agree, continue evolve <iframe> and such to become more usable.

tored 5y ago

One explanation could be that if you are a hammer everything looks like nail. One problem with web dev in general is that we have multiple backend technologies, thus creating a complete client and server rendering framework requires you to integrate it against multiple backend technologies. But if you assume that the best API is JSON over HTTP then you can completely ignore what makes sense from the perspective of the chosen backend technology.

fuzzy2 5y ago

IMHO, this isn’t about “Modern JavaScript” or “JavaScript Culture” at all. It’s just $CURRENT_THING and the Cargo Cult is happy to oblige. Futhermore, dev shops (like my employer) profit from selling overcomplicated solutions. So in the end it’s just group dynamics that drive the usual hype cycle. Remember MVVM?

pjmlp 5y ago
MVVM is pretty much alive in native frameworks, as it makes easy to write tests and share behaviours.
- fuzzy2 5y ago
  I’m not saying it’s bad. You just have to know when to use it. But that’s how it is with any technology/library/framework/whatever. IIRC there was a “MVVM craze” back then, but that could’ve been my bubble.