One thing is to generate a build and ship it once over the wire in the form of an Installer or bytecode executable. Another thing is to ship the entire package and/or parts of it with every launch event, plus the complexity of shipping transpiled code to different interpreters (different browser in this case) which adds more complexity to the model until it finally explodes.
The server side with HTML generated at the backend is a more predictable, faster and simpler approach. Bandwidth is not the issue anymore, but latency. Heavy API consumption from the client, leaves data exposed and increases the latter.
Hotwire/Turboframes/StimulusJS removed the need of generating HTML code at the client, leaving a single source of truth while still having a dynamic/friendly frontend. I consider it to be a better model for the web.
Plus, new Page Transition API and Navigation API are possibly game changers for a lot of use cases out here.
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.
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.
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 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
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.
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.
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
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.
Funny, after only 5 minutes on any website i come to the same conclusion as a user :P
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.
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 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).
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.
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.
https://vercel.com/blog/everything-about-react-server-compon...
---
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?
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
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."
Not only that, but you will substantially improve your lighthouse/pagerank score by removing GoogleTag/API/AdSense/etc.. scripts.We always responded that adding any extra "weight" to a page made it slower. We didn't give our own tools any special treatment. It was up to the site owners to decided what costs were worth their corresponding benefit.
Put another way: the fastest page is an empty one, but that's not terribly useful. Optimize for not just for speed but for utility.
(Disclosure: I still work for Google, but haven't worked on Pagespeed - or anything remotely related - in many years).
but you also didn't "Make them fast!" in response to the criticism. i know because i've profiled and purged plenty of google's JS from sites in the past. in most cases, this analytics/tag-manager JS far outweighed the site's own JS, to the tune of 5:1.
always found it odd how a company that makes V8, Blink, Chrome's DevTools, LightHouse, Closure Compiler, then evangelizes and blogs about performance but in the end doesnt take its own medicine.
The analytics team - get the best data possible The page speed team - get an objective analysis of the speed of a page
Even if it's in Google's interest to give their own stuff preference that would probably require some director or VP to coordinate that collusion and it's hard to say whether it would be worth the liability of having done that.
It's easy to say "make it fast!". Yeah go ahead, make angular fast! Do it now! Its easier said than done...
(I used to work in this area when I was at Google)
Turn off ads? Disable third-party scripts site-wide? Don't send over any audio? How about webfonts? Tracking? Webgl? Webgl2?
Would it not make more sense to ask the user (or their agent) what features they want to use, before trying to figure out which dependencies are needed to make them work?
Could we optimize not just for speed and utility but also user feedback?
[] Do you want a Million Dollars? [] Free Massage? . . or when they are booking an airline ticket [] Gigabit Internet [] Sleeper Couch
The amount of entitlement HNers have is mind-boggling.
Here's economics 101.
Users pay with attention/money for a list of goods/services from the provider. If you don't like it, switch your provider. Unlike some physical monopolies, you aren't bound to any provider.
If you think there is a market for your utopian content provider, how about you start your own company (with your fellow entitled HNers and provide all these features)?
What confuses me though is how much space these libraries take.
321kb for a router? 3.4mb for material ui? 1mb for jquery?
I was under the impression that production builds often include tree-shaking/dead-code-elimination as one of the steps?
This is a decent article that discusses the basic strategies:
https://www.smashingmagazine.com/2021/05/tree-shaking-refere...
But basically tree shaking and dead code elimination can only be effective as the code you write. If you make it hard to parse with ASTs, it's going to hard to tree shake.
the bundle size of my Nuxt 3 app + server is only 1.2mb and bundled node_modules for the server are 9.6mb, while my dev node_modules are about 100mb
probably because Vue tools handle tree-shaking incredibly well
Tree shaking is a big win for bundle size. One of my big takeaways from looking at these visualizations is that we badly need an equivalent for type declaration files.
You seem to be confusing that with the build output, aka object code or target.
> would you rather have TypeScript build your code 20% faster?
> did this make my build faster?
> You might be surprised what's making it into your build!
which are clearly talking about the build process and inputs, not its output.
A trick I've used to shave bundle sizes: re-mapping `babel-runtime/*` to `@babe/runtime` and proper core-js imports and `core-js` imports from V2 to V3 latest imports ones. This shaved tons off of my bundles (unfortunately have some libraries we rely on that are both substantial but old)
Another one is library deduping. I've re-mapped all of the `lodash.*` to be direct default imports, e.g. `lodash.merge` to `lodash/merge`. Also shaved a ton off my bundle sizes.
You just undid 3 months worth of work that will take 6 to replicate. Congratulations. We're all really impressed down here.
people slather a bunch of 3rd party APIs on at deployment time
Giant dependencies and time to interactive have been battling each other for decades. It's not just how much code you run on first paint, that's a discipline in its own right. But until the javascript and CSS load you don't really control much of anything in the browser lifecycle.
So you work and work on those, and you've gotten through a bunch of performance-as-feature gates, but then someone throws three analytics packages on that together are proportional to the code you sweated to carve out of the initial payloads. You can usually defer those, but how easy that was depends on which generation of web browser you're talking about.
What you can't control is how much work those libraries due on the page while they bootstrap. As recently as the last project I worked on in my current job, I discovered that something like 60% of the event loop blocking was coming from some analytics library that was stuck in a reflow loop that was taking longer than we had saved on code that a couple of my poor coworkers had been working on for ages, to the point you could hear the exhaustion in their voices in standup.
That one was mostly tripping up due to a performance bug in an old version of jquery (mutation on read), but other examples in this problem domain are often not so simple to fix.
Ultimately this is a social problem, but I've seen it way too many times.Someone high in the org chart didn't insist that we run the application exactly as it would run in production. In a Saas situation a customer may say "I want to be able to add stuff to my pages, can you do that?" and nobody catches on that they want to run analytics, and not just for one dashboard, but for the old one they can't let go of and the new one that is cooler but only answers 80% of their questions. And then they want a third party live chat which is somehow as slow as the two analytics libraries combined.
It's not mentioned in the article, but we also added an eslint rule to ban importing `googleapis` so that this won't happen again in the future.
In my understanding, it skips type-checking any d.ts files (which most packages include by now) which dramatically lowers compile time. In the authors case it looks like their project is about 400kb of their own code and then 30mb of node_modules libraries.
I think it also skips your own d.ts files (it isn't limited to node_modules), so this might just be a way to dramatically speed up your footgun. I have literally never written my own d.ts file though so it works for my purposes
In general you should only load things you need
Ie opt out is the default.
So that's what I ended up doing: using esbuild. It should only be including what is in use, and the result was fine, even though this service was the largest of the services. But I'm still going to install the separate package and see how much that brings the bundle size down.
This way.. I can see you having a code dependency that needs Drive, but b/c you've cleaned out everything except YouTube it's going to fail - and that's sort of breaking the way Composer is supposed to work.
[0] https://github.com/microsoft/TypeScript/wiki/Performance#per... [1] https://user-images.githubusercontent.com/2109932/176479729-...
edit: It removed 85mb and saves 8 seconds of build time (about 17%). Less impact in build time than I thought but still the easiest win I got lately.
