What I realized a while back is web development has split into two "routes": building websites and building webapps and I think part of the problem is those two often get conflated.

With a website, the idea is a visitor might only visit a single page. Under this model you want to ship as little JS as possible, and ensure that if the user just tries to read a blog post, the entire site isn't getting downloaded.

Contrast that with a webapp. I'm currently building a real estate investment calculator/dashboard and the mental model is diametrically different than building a website. Unlike a site, I want the entire app to be loaded upfront because the user is using the "entire" app, not just viewing a page.

The problem I see is when one is trying to design a "site" but uses the "app" model, or vice versa. Attempt to use an SSR framework like NextJS for an "app" and you are going to have a bad time, likewise try setting up a site like you would a webapp and you are going to have some pretty serious limitations.

I don't think this model actually works in practice, because mobile traffic vastly eclipses web traffic for almost every kind of web application.

Tricks that work on desktop - where a web application might stay open in a browser tab for weeks at a time - don't apply on mobile. On mobile, I'm much more likely to drop into your app for a few minutes to achieve a single goal, then navigate away and un-load it again.

So assuming that I'm going to pay that loading price once and then keep interacting with your application doesn't actually work - most of my interactions with your app will be a cold start, often with an empty cache too since browser caches on mobile devices (especially cheaper Android phones) are much smaller.

I think that for many real applications, either mobile is relevant and then only mobile is relevant, or mobile is irrelevant.

Not many applications are intended to be used on both.

In particular I think most applications for professionals assume you are on a normal computer, not a phone. Consumers, OK.

I don't think that holds in 2022.

There's an entire class of professionals out there these days who don't use laptops. It's possible to run quite a sophisticated business entirely from a phone these days, and a lot of people who are doing exactly that.

Sure, there are professions for which this doesn't work - but even as a software engineer I find myself increasingly frustrated when I can't do things like review a simple pull request on my phone if I'm away from my desk rather than pulling out my laptop.

> In particular I think most applications for professionals assume you are on a normal computer, not a phone. Consumers, OK.

In 2012 sure, but with so much professional work being done asynchronously and mobile phones/browsers being so capable now mobile availability is table stakes.

A few features may be disabled, but if I log in and see a messed up layout or a "please log in from your desktop" screen it's a big red flag for quality/execution shortcomings that will bite me on desktop soon enough.

Many corporations make it prohibitively difficult to get a phone or iPad on the VPN to access on prem services or federated authentication to external services.

So I only have to build for laptop sizes and up. For what I do, anyway.

I would love a [control]+click combo on opening a link from my desktop into the mobile viewer of my choice...

I should be able to go to HN and "View as safari on ios 15. | View as Chrome/brave/ as Device Type [X]" and assign it to ctrl+middle+shift+click... or some such...

I should, be able to see the view, on my machine between the three: Desktop, iOS, Android for the same URL view and see the interactions on desktop....

Is there a reason why one cant just cycle through these views on a single tab of a single browser?

Click the button and it just cycles through the view

The chrome inspector makes it easy to switch between device sizes/user agents.

Rendering with a specific OS/browser combo is not something you can do accurately without actually running that combo. There are services like Browserstack that will do this for you, but I don’t think it’s something that could realistically be built into a browser.

This is it. Another thing with a webapp that someone might use regularly is that the JavaScript bundle that's sent down is cached and you likely won't have that same load time every single time.

However, if you have a landing page that someone might only visit once, then you want to optimize for as little JavaScript as possible, and in that case, just a pure server-side render might be best for that job.

Your example describe two different extremes, in that case is easy to chose, most of us have to work somewhere in the middle and that's were it gets hairy.

What country are you from ? I've been doing exactly this in the past year so maybe we could compare / chat about our stuff.

Even in that model, it's the developer deciding what is an app and what is a site.

There's no inherent need for a real estate investment dashboard to act like an app instead of a plain old website. It might serve many of the developers needs, and maybe some of the customers, too - but such a feature could just as easily be served as a plain old webpage as it could a heavy front loaded application.

> There's no inherent need for a real estate investment dashboard to act like an app instead of a plain old website.

How so? This assertion might be conflating your idea of what an investment dashboard should be like and how it should behave with what some team or company has concluded a customer wants. It is inherently a product decision. Actually, claiming server side rendered app suffices for any real estate investment dashboard sounds like the ”developer deciding” angle.

Unless you truly are claiming that there never is need for anything except server side rendered payloads in the internet. In which case it’s hard to explain why companies don’t do that. It’s almost as if there are product oriented reasons to have webapps. I think the original comment’s logic stands correct

The distinction between app and site is one that is done by the business for the business. Customers don't ask for web apps instead of web sites. You can absolutely serve a real estate investment dashboard as a webpage that serves customer needs, depending on what those needs are.

Maybe customers truly are served better by an app experience based on their needs, but all the times I've been involved in that discussion the impetus for moving to an SPA has more to do with internal business needs such cleaner division of code, improved click/ad tracking, third party javascript integrations, and often much more hand-wavey ones that never seem to play out as expected like the myth that SPA's are inherently faster than page loads.

This post isn't about a Javascript frontend, though. The author works very clearly on a Node.js server, and nothing from that gets shipped to a client/browser.

The more I work with advanced JS frameworks, the more I think I could also have done it with just vanilla javascript (with some jquery). Webapps I made 10 years ago where no less responsive than the webapps I make now. Nor do they take more time to create. The only difference is the size of the applications. They significantly increase with all overhead of frameworks. I wouldn't be surprised when webapp development will return partly to what it was a decade ago, where small (stand-alone) libraries are preferred to these huge, batteries-included, frameworks.

edit: With some exceptions. Some webapps are huge. They are near impossible to program without a solid framework. But this is no more than 5% of all the webapps I create.

React and react-dom are < 100kb compressed, which is pretty much how big jquery is. Preact is even smaller. Which framework are you talking about that’s huge and batteries-included? if you want to drop react in a script tag and write JS that’s compatible with all browsers, you can do that too.

I got curious and looked it up, looks like Jquery is about 30kb compressed & minified nowadays: https://mathiasbynens.be/demo/jquery-size

If you are running a client side app generally you’ll need many other libraries as well. Just to name a few: GraphQL, i18n, Google Firebase, Date parser/formatter, Numbers, etc.

> GraphQL

What libraries does this require? I'm just issuing fetch requests and getting back JSON. Apollo is absolutely NOT EVEN CLOSE TO required to do GQL...

Honestly, both GraphQL and everything else listed seems pretty orthogonal to the original discussion of frameworks... Whether you used VanillaJS or React or a server-rendering platform, your choices of internationalization & datastores & auth & functionality require code...

If you bring HTML rendering to the client you will need a ton of other libraries as well.

There are several GraphQL libraries supporting different features, of different sizes.

> If you bring HTML rendering to the client

The client being the browser? Isn't HTML rendering what it does? What kind of HTML rendering are you talking about?

You render HTML with React or PHP.

The browser renders a webpage using the rendered HTML, CSS and sometimes Javascript.

Ah, I see. I don't see why you need tons of libraries, or any libraries at all, for that though. (And you don't even need to render any intermediary HTML if you use the DOM API.)

I don't really follow your overall point. The discussion was around how "frameworks are huge", and now you're saying... You need other libraries than the framework for HTML rendering?

> There are several GraphQL libraries

And some of them are tiny, which is antithetical to your previous point...

No discussion is about the architectural model, not only frameworks.

Do client side rendering of HTML and you’ll need libraries, just like you do on the backend.

The frameworks ARE the HTML rendering. We're really running in circles about nothing in particular here, I think it's ok to leave.

I agree. Every time I try out a framework, it always turns out to be easier to create vanilla Js for the few functions that I actually need. The one exception being JQuery. That was useful.

I feel comments like this must come from an individual who should actually be using SSR (Server Side Rendering) and just spitting out HTML. There is no world that composition of components - the #1 reason to use frameworks - can be solved by a "few functions", and anyone who is building serious UIs will tell you you're pretty boned without composition.

My UI is almost certainly more “serious” than yours. But it was started in 2004, long before frameworks were invented….. Just saying vanilla is not nearly as difficult as people think.

> After years of testing different JS frameworks and build systems, I became convinced that heavy Javascript frontends are generally a bad model for the web

Funny, after only 5 minutes on any website i come to the same conclusion as a user :P

It should all be down the applications need for client side interactions. Even with hotwire/turboframes, phoenix liveview or other websocket / real time server driven update patterns, it can be suboptimal for many catagories of applications as these rely on (albeit smart) whole replacement of DOM nodes. In heavy applications, or applications that have a lot of represented state, its not the panacea it might seem at first glance.

I always tell people, "mileage may vary, there's no silver bullets in this industry". I think it holds true especially when talking about stuff like this.

One thing is to have JS for client-side interactivity, and another thing is to generate the entire HTML using javascript by sending both the data and javascript bundles to the client.

Incremental rehydration techniques make this much much less of an issue (React 18 supports this now, IIRC, for instance). The tl;dr is that if you employ SSG or SSR you won't endup up with immediate re-hydrating once the client loads up, but only when something triggers the need for re-hydration, like a button click.

That to me seems like the sweet spot for highly interactive applications that are very stateful, however like I said previously, your mileage may vary.

> Bandwidth is not the issue anymore, but latency.

Bandwidth is also the issue, but most web devs or website owners don't seem to realise or care that most of the world is probably struggling with their page weight.

Internet speeds are more disparate now than in the 90s, but this issue tends to be made opaque by available bandwidth statistics... There are no distribution statistics available at all. Instead bandwidth stats are always aggregated as a regional average, and worse those samples tend to be from voluntary subset (at least in my country). Even when the median is used, it conceals a significant bandwidth divide due to communication technology gaps.

The bandwidth distribution could be roughly inferred more accurately by grouping the averages by communication technology rather than region - this way a large number of very poor bandwidth users aren't concealed by a handful of super fast gigabit fiber connections or a marginal majority of fiber connections. There's a huge number of households still stuck with ADSL, 100% fiber is a very long way off (will probably never have full coverage, expecting LTE to fill this gap) and there is a huge gap between these technologies. To compound this issue households have to share connections between multiple people and increasingly hungry devices that don't respect users data usage (looking at Apple's massive inefficient update images in particular).

Streaming section by section of a frontend sounds like a troubleshooting nightmare. Users expect an interactive experience with a website. That means JavaScript. Anything else is going to be more complex.

"users expect an interactive experience with a website" - I think this is a generalization that is getting a lot of web developers into needlessly complex toolchains and frameworks.

When I'm in a browser, 99% of the time I expect the page to have what I'm looking for. I rarely care if its interactive. In fact, the more interactive it is, the less enjoyable the experience is. This holds even firmer when I'm on a desktop.

I tend to agree. It’s frustrating whenever whatever nugget of information I’m seeking is buried under multiple clicks (navigation, collapsible sections, modals, popovers, etc) and even worse when one or more of those clicks results in a loading spinner that takes longer to play its fade in transition than it would’ve taken to load an entire static page.

No, regular users definitely prefer web pages over interactive websites.

With webpages, any delays make intuitive sense and are accepted by the user. With an interactive web app, the web app gets blamed for any delays or latency because there is no full-page refresh.

I think NextJS + React server components would work pretty well for your idea of UX, while maintaining that powerful and flexible DX React has.

https://vercel.com/blog/everything-about-react-server-compon...

I think NextJS is the best frontend implementation I came across.

sERIOUS question: Is there a method for testing a site that defines how much JS heavy FEs are?

---

I have noticed a significant issue with speed on sites after upgrading my main machines, but dont know how to judge if its local or remote.

I have a flagshit HP gaming machine, with the best laptop nvidia card on the market....

windows 11 (with a sister machine of same specs with linux)

Ryzen 5K RTX 3070 blah blah...

But the load times on these "gaming centric" machines are way slower than older, les spec'd machines...

I cant tell where my bottle-neck is.

How test this specific, in your opinion?

I wonder how fast could be something that just replaces everything in the browser, HTML, CSS, JS with just webasm and some reasonable UI engine.

HTML/CSS/JS IS a pretty reasonable UI engine. What tools have you seen that are lighter and allow you to express the same capabilities??

I haven't but I have trouble with Electron haters that seem to think everything else is better.

What about with something that runs in WebAssembly, like .NET's Blazor?

if you think React is big, you'll be sad by the 2 MB mandatory runtime you have to download just to run your Blazor WASM code, which can add megabytes on top.

That said, if your application is actually complex enough to warrant this upfront download cost, might make sense.

YMMV as always

EDIT: in case it wasn't obvious, I was talking about Blazor WASM not Blazor server

There are two ways to run blazor. I don't think the WASM version of blazor is the one you're talking about.

It most certainly is. As noted in thread: https://github.com/dotnet/aspnetcore/issues/41909

This is why I am convinced part of the reason Google and Facebook create JS frameworks is so they can move computation out their data centers and onto your computer.

Eh, i think you're thinking too small here.

This whole thread is full of people saying things like, "When _I'm_ building a webapp," and "_My_ projects end up loading slowly," etc. Google is saying things like, "When 400 people are working on a web app, how can we avoid it turning into a shit show."

I think that is in the case of Facebook they were trying to solve their own use case, and in the case of Google, they saw it as a way of strengthening the strategic position of the web in general vs apps.