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

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.

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/ - 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.)

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.

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

[1]: https://docs.microsoft.com/en-us/azure/architecture/patterns...

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.

"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.

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.

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