4 ms·
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, h
by 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 agoThis 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 agoThank you for the summary
- Justsignedup 6y agoHe 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 agoVideo 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 agoI 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.