8 ms·

You Really Don’t Need All That JavaScript [video]

112 points by tambourine_man 6y ago

deleted 6y ago
[deleted]
ebiester 6y ago
I saw this earlier today (Edit: instead of the first 10 minutes, I ended up watching the whole thing.) After going into the problems of client side rendering, he does get into the benefits (9:00), but then argues that these are after-the-fact rationalizations. He then argues that the real problem designers and devs are trying to solve is the loss of control - that the browser controls loading, and the blank screen is "bad." He then says that the solution is using an iframe (called a portal.) which looks to be a proposed API. https://web.dev/hands-on-portals/ https://web.dev/hands-on-portals/ - this is available as an origin trial in Chrome 85. So, he's saying that SPAs are bad and we should invest in a Chrome-only feature or future feature that might make it through standards? This makes no sense to me. There are multiple uses for SPAs. One is building a genuine web application, such as Gmail or a SAAS. SPAs are also used in places they shouldn't, such as news sites, because of the page load problem as mentioned above. Portals would be useful here. But it gets to the real problem: client side rendering in the past decade has had a lot more thought and effort in tooling, tutorials, and patterns on the client side than server side, especially with mixed mode. (Mixed mode: adding javascript on top of server-side rendering.) The problem is that server-side rendering and mixed mode is not a good development experience. The back button was never a fully solved problem and POST-redirect-GET is essentially an insufficient hack. If someone wants to talk about making server side rendering for web applications a viable experience, we are likely going to need changes to the standards and we will need to build up a great set of tooling to solve the problem. (Oh, and since it's server-side rather than javascript, each framework or language will have to replicate it just like React, Angular, Vue, and others have done.)
- Aldo_MX 6y ago
  > So, he's saying that SPAs are bad and we should invest in a Chrome-only feature or future feature that might make it through standards? This makes no sense to me. That was my own conclusion, at first I thought "whoa, <portal>? never heard about it but looks cool", I proceeded to search for `HTMLPortalElement` and then I got to a W3C page saying "Draft" and I was like "what? a yet to be standardized feature? thanks, but no thanks, I'll might check it back in 2 years".
  - OzzyB 6y ago
    This presentation is essentially Dev Advocacy, he's describing where we want to go, not necessarily where we are now. I hear you though; I thought this was gonna be another "you don't need React, here's the Vanilla JS that does the same thing" kinda presentation, but was actually intrigued to learn about this <portal> tag. I does seem to address the (main?!) bugbear we have with interactive webpages and the fight between the server and client. Although I am surprised there's little to no support for it right now - thought at least Chrome would. https://caniuse.com/?search=portal https://caniuse.com/?search=portal Edit: Ofc it can be tried out w/ Chrome if Dev Enabled, but it's not user supported at this time.
- krzepah 6y ago
  Thank you for the summary
- Justsignedup 6y ago
  He also doesn't cover the high interaction problems of server-side rendering. If you have a website that isn't a SPA but has a really complex form (for let's say a good reason). Making that server side can be incredibly complex for only fractions of a second in gains.
- DreamOther 6y ago
  Video feels like clickbait. Appeals to people who are: 1. Frustrated with the complexity/brittleness of javascript tooling 2. Still learning (oooo, shortcut?) 3. Pining for the good ol' days (conveniently forget ie6) A better, more realistic talk might have been "how to make a fast, responsive, mobile-friendly site without javascript and here are some new browser features to look forward to" but I'm sure that would have got a lot less clicks.
- azangru 6y ago
  I have exactly the same feelings after watching the video. I can understand the assumption that your audience is a bunch of bootcamp graduates who put React in anything they build. But at a Goto conference, shouldn't you be targeting a more sophisticated audience? What if your product is more like gmail, or Google Docs, or Facebook, or Google Earth, or Youtube? What would you think then of someone who tells you to let go of your desire to control the behavior of the anchor tag?
- rpdillon 6y ago
  > So, he's saying that SPAs are bad and we should invest in a Chrome-only feature or future feature that might make it through standards? I don't think so. The video takes a couple of interesting turns for me. I thought it was "JavaScript...bad!", but then he converted to a discussion of <portal>, which I thought is where he would end. But the last few minutes he spends on a much higher level point, which makes me think the portal discussion is just an example. In the spirit of your summary, here's my own: The web platform is evolving. While some of our work exceeds the capabilities of least powerful part of that platform (HTML/CSS) and therefore requires JavaScript, much of it does not. Notably, as the web platform evolves, features that used to require JavaScript no longer will. This suggests a "principle of least power" argument: make an effort to learn about the new advances in HTML/CSS so you can leverage them for as many features as you can, and push the rest into JavaScript. He contrasts this approach with the "just use JavaScript for everything" approach, which carries with it all the risks he outlines in the first part of the video.
hardwaresofton 6y ago
I am definitely one that loves a good "get off my lawn" moment, but it seems like we rehash this point every few weeks (and I don't even read frontend twitter). There is a reason we are where we are in the front end world -- most every useful tool/wave of engineering came to be for a reason. A (very spotty) timeline[0] was even submitted in the not too distant past to HN, and I won't go into it here, but from jquery to mootools to snowpack/vite, people built tools to solve problems (some of which don't exist anymore or won't in the near future) -- a strong grasp of fundamentals and knowledge of why a thing exists and you will feel a lot less like you're being thrown around by the waves of frontend development zeitgeist. All that said -- SSR is the best of both worlds. To the untrained eye, it looks like a step backwards, but there's more to it than that -- it gives separation (if you want it) for your frontend code that usually moves at a different pace than the backend code, server-side rendering for performance (obviously), and complex client side functionality for building rich experiences. If you can withstand the increase in complexity, you can mostly have your cake and eat it too -- server-side rendered robust client applications. Even for the most stalwart monolith enthusiast, isn't it nice to make it relatively difficult for your View code to call some Model/Controller/util method/function that it shouldn't be calling? If you go through the trouble of committing to separating your "API" and your "frontend server" (there's a trendy name for this which I have forgotten -- "companion" server? BFF?[1]), you get better focused and hopefully more manageable domains. All that said, portals are a pretty cool new feature, but I'm not going to hold my breath for them to be ready to use any time soon. [0]: https://bestofjs.org/timeline https://bestofjs.org/timeline [1]: https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends https://docs.microsoft.com/en-us/azure/architecture/patterns...
- austincheney 6y ago
  > There is a reason we are where we are in the front end world Insecurity resulting from a lack of proper training.
  - hardwaresofton 6y ago
    Well yeah, but that's everywhere. More realistically I think it's because browsers are the biggest software delivery platform every created (and likely that ever will be created until we get some sort of neural/in-body interface), and they change faster than regular desktop software ever could. The browser is so popular as a software distribution method, it now competes with GTK/QT/Cocoa/etc for (large amounts of) "RAMshare" on your neighborhood desktop.
whoisjuan 6y ago
Let's say you're updating your UI through Ajax requests, something like Laravel Livewire. For example filtering a list. If you do a web request, although is going to be fast that request and the re-rendering could take up to 300ms. That's very noticeable when you're browsing. It makes the website feel slow. It's very hard to beat that latency if you're going to update everything from the server. So you really do need JavaScript to create that snappiness. If you're filtering in the browser with the data that you already received, it's going to feel instant. I purposefully chose the filtering example because it's something that you can do server-side or client-side. But the server side is always going to feel slower if you're sending all the data in each request and simply changing the rendering. So where do you draw the line? I think you should only let the server re-render the UI if there's new data being queried and sent. I'm of the opinion that JavaScript should only manage the interactivity of what receives and should be fetching very few data. Of course this only makes sense if you're using something like Laravel or Rails. But even if you are building a SPA and working against a series of endpoints I think you should make an effort to write those endpoints in such way that you're sending as much data as you can in each request and let the client handle it without requesting again just to re-paint the UI.
- 3np 6y ago
  You make a good distinction with “can the working set be preloaded or not”. There are still some cases where I don’t think there’s an obvious answer in the general case. Photo gallery? Product list in webshop?
- vbezhenar 6y ago
  I've yet to encounter client-side filtering. Usually there are many pages of items. Server returns selected page according to filter criteria. Client just does not have all the items, so he'll be able to filter only already visible items which is not useful.
uses 6y ago
More than anything this reminds me of the fact that HTML has failed on a basic level, to keep up with the ways that users want to experience content, and that designers want to present content. The browser has no real concept of "page navigation" or "site navigation" with any kind of state, or the "current" navigation item, or of hierarchy, breadcrumbs, menus, or other core navigational concepts involving site and page structure. With a few built-in "site structure" features in the html standard, the browser could do a large part of what developers end up reimplementing over and over again - both with and without JS. A large part of "knowing about usability" is just knowing how to execute these basic navigation features without goofing up on the many pitfalls available to you. For example, imagine if there was some kind of Site Structure standard, or Page Structure standard. The browser could then generate standardized navigation elements with perfect UX on every platform, and sure, you can style them, but the basic functionality just works everywhere without having to make advanced javascript/html/css menus that take into account concepts like responsiveness, touch interface, or accessibility.
- feoren 6y ago
  No thanks. Good languages start small and stay small. HTML is already bloated with tons of elements of questionable usefulness. It's a document presentation format, and that's all it should ever be. Does Markdown need knowledge of state and navigation and breadcrumbs and menus?
  - williamdclt 6y ago
    > It's a document presentation format Not it's not. That's what it was created for, but clearly it's not anymore. People are not publishing just documents anymore, it's a fact that HTML is used for all sorts of things from simple sites to complex applications. We agree it's not great, for all of these purposes but this ship has sailed, we need to deal with it. Either we create something different and good enough to not die in the water, either we improve HTML so that it supports what people are already using it for.
    - rumanator 6y ago
fetbaffe 6y ago
"Blank page" problem is usually only a problem if your site is really slow, but if it is fast (because of server side rendering) it is less of a problem. As the presenter in the video said, browsers can render HTML documents really fast, this leads to some interesting conclusions. Assume that you need to render a modal as popup for each item in a grid. Frontend solution would be to reuse the same modal for every item and just swap in the on-the-fly rendered content for that item. Or maybe even on-the-fly create & render the entire modal when needed. Backend solution would be to render one modal per item. This is actually easier, just loop & have unique ids (you can even reuse the same loop that you build the grid with) & no need for dynamic loading, rendering, etc. So even if you send more HTML down the line, the page acts smother.
- ebiester 6y ago
  Let's say you have a query that takes 3 seconds, and about half second to manipulate that into something that makes sense and start sending the data over. With the single page solution, you can have a spinner that is allowing the user to know that something is happening. What does it look like if you click that link?
  - seba_dos1 6y ago
    The browser is instantly showing a spinner to let user know that something is happening, and after 3 seconds the page switches to a new one. That's exactly how this very site we're on right now works, for instance.
  - fanf2 6y ago
    You know browsers have built-in loading spinners? https://media.giphy.com/media/anjRJ4nv9WJzO/source.gif https://media.giphy.com/media/anjRJ4nv9WJzO/source.gif In my experience, any time a web site reimplements basic browser functionality in JavaScript (e.g. loading spinners, scrolling, navigation) it is slow, buggy, and annoying.
PaulDavisThe1st 6y ago
His example of using portals to solve "a real problem" is really interesting to me, because it seems to point to a much more fundamental problem with UI development via HTML and browsers. The example involves a common page design: left hand table of contents, right hand (typically most of the width) with current contents (chosen via ToC). Jump to a new section, and the scroll position in the ToC is lost. He describes how to use a portal to fix this. Compare with desktop GUI toolkits. The ToC would be its own element (GtkListView or QtWhateverList or NSThisNThat). The contents would be their own element (GtkTextView or QtCanvas or whatever). Both are drawn independently of the other. You can call for an invalidation of part of the window. You do not need to consider them part of a single window rectangle that will always be redrawn in-toto for a page load. Now, my (weak) understanding of why we've ended up with things like React is that in part they are an attempt to solve this by effectively creating the equivalent of a widget heirarchy inside the browser. When a React implementation of his example gets new content, it doesn't invalidate or even necessarily "redraw" the ToC, and it tells the browser what to do by invalidating certain DOM elements (or even just one DOM element). I think he misses this as a key reason for the movement towards frameworks. But ... notice that the browser will probably (I'm not 100% sure about this, would appreciate comment from someone who knows), re-render the entire rectangle the contains the page. Desktop applications don't work this way. If you turn on Quartz debugging on macOS you can actually see the rects on screen that are re-rendered to reflect invalidation by the application (e.g. after new content needs to be displayed). Maybe I have this wrong, and React and similar frameworks have leveraged a subtle capability in the browser to invalidate a DOM element as a way to only re-render part of the on-screen rect. But assuming that I've have this roughly correct, this model in which the "atomic, indivisible rendering unit" for browser apps is the page rect seems fundamentally disadvantaged and mis-designed compared to desktop apps.
- acemarke 6y ago
  I don't have technical references to point to atm, but as far as I know, browsers _do_ go to great lengths to only actually repaint portions of the page that have changed. There's lots of layer compositing on GPUs, checks to see what DOM nodes were mutated, etc. Nothing framework-specific here at all - this is how all modern browsers are implemented. React in turn does work to let you, the developer, divide your UI code into discrete components that control the layout of some subset of the page, and lets you declare what the UI should look like at any given point in time based on our data. React then tries to minimize the number of DOM updates that have to be modified to make the previous DOM structure look like the structure you said you want now.
holoduke 6y ago
A proper fully clientside rendered website gives a much better user experience. Yes you need a strong clientside framework able to render components, maintain state, history etc. Once the application is loaded, the only data communication between server and client is JSON or some other format. Much more efficient in bandwidth and speed. Another plus is that you can actually have multi platform versions of the application with the look and feel of the target platform. Good luck to get that feeling with a 800ms delay serverside rendered page. The main reason why you shouldn't do it, is because of SEO. Dynamic sites are considered weak in SEO. Very challenging to get them properly indexed by Google etc. You also got still a lot of engineers who somehow favour the serverside rendering. For inhouse internal apps or b2b apps I would always prefer a clientside app.
- satyrnein 6y ago
  For internal and b2b apps, what matters most is development velocity to be able to churn through a million unmet needs the fastest way possible, much more do than shaving off a few hundred milliseconds off the response time. On this metric, I don't think SPAs win.
- Spivak 6y ago
  The problem with this take is that browsers are really good and downloading and displaying static (to the browser) content which is the basis of server-side hydration. SSR is almost always going to be faster but it will beat the crap out of your servers depending on how dynamic the pages are.
- rcxdude 6y ago
  I agree in theory but in practice SPAs chug on initial loading and they chug on loading new content (and they often even chug when scrolling this content!). the experience of using many websites increased drastically with javascript disabled. Something is clearly wrong with current SPA practice if this is the consistent result that users see.
karmakaze 6y ago
Until convinced otherwise, I'll continue using Vue and if necessary server-side rendering of it. This post didn't change my opinion.

deleted 6y ago

[deleted]

I saw this earlier today (Edit: instead of the first 10 minutes, I ended up watching the whole thing.) After going into the problems of client side rendering, he does get into the benefits (9:00), but then argues that these are after-the-fact rationalizations. He then argues that the real problem designers and devs are trying to solve is the loss of control - that the browser controls loading, and the blank screen is "bad." He then says that the solution is using an iframe (called a portal.) which looks to be a proposed API. https://web.dev/hands-on-portals/ https://web.dev/hands-on-portals/ - this is available as an origin trial in Chrome 85. So, he's saying that SPAs are bad and we should invest in a Chrome-only feature or future feature that might make it through standards? This makes no sense to me. There are multiple uses for SPAs. One is building a genuine web application, such as Gmail or a SAAS. SPAs are also used in places they shouldn't, such as news sites, because of the page load problem as mentioned above. Portals would be useful here. But it gets to the real problem: client side rendering in the past decade has had a lot more thought and effort in tooling, tutorials, and patterns on the client side than server side, especially with mixed mode. (Mixed mode: adding javascript on top of server-side rendering.) The problem is that server-side rendering and mixed mode is not a good development experience. The back button was never a fully solved problem and POST-redirect-GET is essentially an insufficient hack. If someone wants to talk about making server side rendering for web applications a viable experience, we are likely going to need changes to the standards and we will need to build up a great set of tooling to solve the problem. (Oh, and since it's server-side rather than javascript, each framework or language will have to replicate it just like React, Angular, Vue, and others have done.)

Aldo_MX 6y ago
> So, he's saying that SPAs are bad and we should invest in a Chrome-only feature or future feature that might make it through standards? This makes no sense to me. That was my own conclusion, at first I thought "whoa, <portal>? never heard about it but looks cool", I proceeded to search for `HTMLPortalElement` and then I got to a W3C page saying "Draft" and I was like "what? a yet to be standardized feature? thanks, but no thanks, I'll might check it back in 2 years".
- OzzyB 6y ago
  This presentation is essentially Dev Advocacy, he's describing where we want to go, not necessarily where we are now. I hear you though; I thought this was gonna be another "you don't need React, here's the Vanilla JS that does the same thing" kinda presentation, but was actually intrigued to learn about this <portal> tag. I does seem to address the (main?!) bugbear we have with interactive webpages and the fight between the server and client. Although I am surprised there's little to no support for it right now - thought at least Chrome would. https://caniuse.com/?search=portal https://caniuse.com/?search=portal Edit: Ofc it can be tried out w/ Chrome if Dev Enabled, but it's not user supported at this time.
krzepah 6y ago
Thank you for the summary
Justsignedup 6y ago
He also doesn't cover the high interaction problems of server-side rendering. If you have a website that isn't a SPA but has a really complex form (for let's say a good reason). Making that server side can be incredibly complex for only fractions of a second in gains.
DreamOther 6y ago
Video feels like clickbait. Appeals to people who are: 1. Frustrated with the complexity/brittleness of javascript tooling 2. Still learning (oooo, shortcut?) 3. Pining for the good ol' days (conveniently forget ie6) A better, more realistic talk might have been "how to make a fast, responsive, mobile-friendly site without javascript and here are some new browser features to look forward to" but I'm sure that would have got a lot less clicks.
azangru 6y ago
I have exactly the same feelings after watching the video. I can understand the assumption that your audience is a bunch of bootcamp graduates who put React in anything they build. But at a Goto conference, shouldn't you be targeting a more sophisticated audience? What if your product is more like gmail, or Google Docs, or Facebook, or Google Earth, or Youtube? What would you think then of someone who tells you to let go of your desire to control the behavior of the anchor tag?
rpdillon 6y ago
> So, he's saying that SPAs are bad and we should invest in a Chrome-only feature or future feature that might make it through standards? I don't think so. The video takes a couple of interesting turns for me. I thought it was "JavaScript...bad!", but then he converted to a discussion of <portal>, which I thought is where he would end. But the last few minutes he spends on a much higher level point, which makes me think the portal discussion is just an example. In the spirit of your summary, here's my own: The web platform is evolving. While some of our work exceeds the capabilities of least powerful part of that platform (HTML/CSS) and therefore requires JavaScript, much of it does not. Notably, as the web platform evolves, features that used to require JavaScript no longer will. This suggests a "principle of least power" argument: make an effort to learn about the new advances in HTML/CSS so you can leverage them for as many features as you can, and push the rest into JavaScript. He contrasts this approach with the "just use JavaScript for everything" approach, which carries with it all the risks he outlines in the first part of the video.

hardwaresofton 6y ago

I am definitely one that loves a good "get off my lawn" moment, but it seems like we rehash this point every few weeks (and I don't even read frontend twitter). There is a reason we are where we are in the front end world -- most every useful tool/wave of engineering came to be for a reason. A (very spotty) timeline[0] was even submitted in the not too distant past to HN, and I won't go into it here, but from jquery to mootools to snowpack/vite, people built tools to solve problems (some of which don't exist anymore or won't in the near future) -- a strong grasp of fundamentals and knowledge of why a thing exists and you will feel a lot less like you're being thrown around by the waves of frontend development zeitgeist. All that said -- SSR is the best of both worlds. To the untrained eye, it looks like a step backwards, but there's more to it than that -- it gives separation (if you want it) for your frontend code that usually moves at a different pace than the backend code, server-side rendering for performance (obviously), and complex client side functionality for building rich experiences. If you can withstand the increase in complexity, you can mostly have your cake and eat it too -- server-side rendered robust client applications. Even for the most stalwart monolith enthusiast, isn't it nice to make it relatively difficult for your View code to call some Model/Controller/util method/function that it shouldn't be calling? If you go through the trouble of committing to separating your "API" and your "frontend server" (there's a trendy name for this which I have forgotten -- "companion" server? BFF?[1]), you get better focused and hopefully more manageable domains. All that said, portals are a pretty cool new feature, but I'm not going to hold my breath for them to be ready to use any time soon. [0]: https://bestofjs.org/timeline https://bestofjs.org/timeline [1]: https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends https://docs.microsoft.com/en-us/azure/architecture/patterns...

austincheney 6y ago
> There is a reason we are where we are in the front end world Insecurity resulting from a lack of proper training.
- hardwaresofton 6y ago
  Well yeah, but that's everywhere. More realistically I think it's because browsers are the biggest software delivery platform every created (and likely that ever will be created until we get some sort of neural/in-body interface), and they change faster than regular desktop software ever could. The browser is so popular as a software distribution method, it now competes with GTK/QT/Cocoa/etc for (large amounts of) "RAMshare" on your neighborhood desktop.

whoisjuan 6y ago

Let's say you're updating your UI through Ajax requests, something like Laravel Livewire. For example filtering a list. If you do a web request, although is going to be fast that request and the re-rendering could take up to 300ms. That's very noticeable when you're browsing. It makes the website feel slow. It's very hard to beat that latency if you're going to update everything from the server. So you really do need JavaScript to create that snappiness. If you're filtering in the browser with the data that you already received, it's going to feel instant. I purposefully chose the filtering example because it's something that you can do server-side or client-side. But the server side is always going to feel slower if you're sending all the data in each request and simply changing the rendering. So where do you draw the line? I think you should only let the server re-render the UI if there's new data being queried and sent. I'm of the opinion that JavaScript should only manage the interactivity of what receives and should be fetching very few data. Of course this only makes sense if you're using something like Laravel or Rails. But even if you are building a SPA and working against a series of endpoints I think you should make an effort to write those endpoints in such way that you're sending as much data as you can in each request and let the client handle it without requesting again just to re-paint the UI.

3np 6y ago
You make a good distinction with “can the working set be preloaded or not”. There are still some cases where I don’t think there’s an obvious answer in the general case. Photo gallery? Product list in webshop?
vbezhenar 6y ago
I've yet to encounter client-side filtering. Usually there are many pages of items. Server returns selected page according to filter criteria. Client just does not have all the items, so he'll be able to filter only already visible items which is not useful.

uses 6y ago

More than anything this reminds me of the fact that HTML has failed on a basic level, to keep up with the ways that users want to experience content, and that designers want to present content. The browser has no real concept of "page navigation" or "site navigation" with any kind of state, or the "current" navigation item, or of hierarchy, breadcrumbs, menus, or other core navigational concepts involving site and page structure. With a few built-in "site structure" features in the html standard, the browser could do a large part of what developers end up reimplementing over and over again - both with and without JS. A large part of "knowing about usability" is just knowing how to execute these basic navigation features without goofing up on the many pitfalls available to you. For example, imagine if there was some kind of Site Structure standard, or Page Structure standard. The browser could then generate standardized navigation elements with perfect UX on every platform, and sure, you can style them, but the basic functionality just works everywhere without having to make advanced javascript/html/css menus that take into account concepts like responsiveness, touch interface, or accessibility.

feoren 6y ago
No thanks. Good languages start small and stay small. HTML is already bloated with tons of elements of questionable usefulness. It's a document presentation format, and that's all it should ever be. Does Markdown need knowledge of state and navigation and breadcrumbs and menus?
- williamdclt 6y ago
  > It's a document presentation format Not it's not. That's what it was created for, but clearly it's not anymore. People are not publishing just documents anymore, it's a fact that HTML is used for all sorts of things from simple sites to complex applications. We agree it's not great, for all of these purposes but this ship has sailed, we need to deal with it. Either we create something different and good enough to not die in the water, either we improve HTML so that it supports what people are already using it for.
  - rumanator 6y ago

fetbaffe 6y ago

"Blank page" problem is usually only a problem if your site is really slow, but if it is fast (because of server side rendering) it is less of a problem. As the presenter in the video said, browsers can render HTML documents really fast, this leads to some interesting conclusions. Assume that you need to render a modal as popup for each item in a grid. Frontend solution would be to reuse the same modal for every item and just swap in the on-the-fly rendered content for that item. Or maybe even on-the-fly create & render the entire modal when needed. Backend solution would be to render one modal per item. This is actually easier, just loop & have unique ids (you can even reuse the same loop that you build the grid with) & no need for dynamic loading, rendering, etc. So even if you send more HTML down the line, the page acts smother.

ebiester 6y ago
Let's say you have a query that takes 3 seconds, and about half second to manipulate that into something that makes sense and start sending the data over. With the single page solution, you can have a spinner that is allowing the user to know that something is happening. What does it look like if you click that link?
- seba_dos1 6y ago
  The browser is instantly showing a spinner to let user know that something is happening, and after 3 seconds the page switches to a new one. That's exactly how this very site we're on right now works, for instance.
- fanf2 6y ago
  You know browsers have built-in loading spinners? https://media.giphy.com/media/anjRJ4nv9WJzO/source.gif https://media.giphy.com/media/anjRJ4nv9WJzO/source.gif In my experience, any time a web site reimplements basic browser functionality in JavaScript (e.g. loading spinners, scrolling, navigation) it is slow, buggy, and annoying.

PaulDavisThe1st 6y ago

His example of using portals to solve "a real problem" is really interesting to me, because it seems to point to a much more fundamental problem with UI development via HTML and browsers. The example involves a common page design: left hand table of contents, right hand (typically most of the width) with current contents (chosen via ToC). Jump to a new section, and the scroll position in the ToC is lost. He describes how to use a portal to fix this. Compare with desktop GUI toolkits. The ToC would be its own element (GtkListView or QtWhateverList or NSThisNThat). The contents would be their own element (GtkTextView or QtCanvas or whatever). Both are drawn independently of the other. You can call for an invalidation of part of the window. You do not need to consider them part of a single window rectangle that will always be redrawn in-toto for a page load. Now, my (weak) understanding of why we've ended up with things like React is that in part they are an attempt to solve this by effectively creating the equivalent of a widget heirarchy inside the browser. When a React implementation of his example gets new content, it doesn't invalidate or even necessarily "redraw" the ToC, and it tells the browser what to do by invalidating certain DOM elements (or even just one DOM element). I think he misses this as a key reason for the movement towards frameworks. But ... notice that the browser will probably (I'm not 100% sure about this, would appreciate comment from someone who knows), re-render the entire rectangle the contains the page. Desktop applications don't work this way. If you turn on Quartz debugging on macOS you can actually see the rects on screen that are re-rendered to reflect invalidation by the application (e.g. after new content needs to be displayed). Maybe I have this wrong, and React and similar frameworks have leveraged a subtle capability in the browser to invalidate a DOM element as a way to only re-render part of the on-screen rect. But assuming that I've have this roughly correct, this model in which the "atomic, indivisible rendering unit" for browser apps is the page rect seems fundamentally disadvantaged and mis-designed compared to desktop apps.

acemarke 6y ago
I don't have technical references to point to atm, but as far as I know, browsers _do_ go to great lengths to only actually repaint portions of the page that have changed. There's lots of layer compositing on GPUs, checks to see what DOM nodes were mutated, etc. Nothing framework-specific here at all - this is how all modern browsers are implemented. React in turn does work to let you, the developer, divide your UI code into discrete components that control the layout of some subset of the page, and lets you declare what the UI should look like at any given point in time based on our data. React then tries to minimize the number of DOM updates that have to be modified to make the previous DOM structure look like the structure you said you want now.

holoduke 6y ago

A proper fully clientside rendered website gives a much better user experience. Yes you need a strong clientside framework able to render components, maintain state, history etc. Once the application is loaded, the only data communication between server and client is JSON or some other format. Much more efficient in bandwidth and speed. Another plus is that you can actually have multi platform versions of the application with the look and feel of the target platform. Good luck to get that feeling with a 800ms delay serverside rendered page. The main reason why you shouldn't do it, is because of SEO. Dynamic sites are considered weak in SEO. Very challenging to get them properly indexed by Google etc. You also got still a lot of engineers who somehow favour the serverside rendering. For inhouse internal apps or b2b apps I would always prefer a clientside app.

satyrnein 6y ago
For internal and b2b apps, what matters most is development velocity to be able to churn through a million unmet needs the fastest way possible, much more do than shaving off a few hundred milliseconds off the response time. On this metric, I don't think SPAs win.
Spivak 6y ago
The problem with this take is that browsers are really good and downloading and displaying static (to the browser) content which is the basis of server-side hydration. SSR is almost always going to be faster but it will beat the crap out of your servers depending on how dynamic the pages are.
rcxdude 6y ago
I agree in theory but in practice SPAs chug on initial loading and they chug on loading new content (and they often even chug when scrolling this content!). the experience of using many websites increased drastically with javascript disabled. Something is clearly wrong with current SPA practice if this is the consistent result that users see.

karmakaze 6y ago

Until convinced otherwise, I'll continue using Vue and if necessary server-side rendering of it. This post didn't change my opinion.