
The Baseline Costs of JavaScript Frameworks - GeneralMaximus
https://blog.uncommon.is/the-baseline-costs-of-javascript-frameworks-f768e2865d4a
======
StillBored
As a US based user of an A53 based phone, where I use firefox. I'm here to
tell you more than 50% of the sites I visit with it (HN being one that
actually works well) are completely unusable. There was a saying back in the
1990's that developers should be forced to use obsolete hardware to assure
that their software was usable for the regular user, and its even more true
today. Developers running around with the latest iphones does nothing to
actually represent what the average user actually sees.

Picking on amazon, I generally don't even bother going to their site unless
i'm on my desktop, where I can physically watch them frequently spike my 4+
Ghz CPU for a few seconds when I type in the search bar, or click a page.
Doing the same on my phone or cheap tablet frequently results in a 10+ second
waits. The other day I was typing on my tablet and the amazon search
completion was literally taking 20+ seconds to display each _character_ and a
completion list for it.

~~~
paraditedc
And this is the first time I heard someone complain Amazon UI being slow. And
Amazon sales or stock are not dropping.

Probably you are not part of the 99% of users that Amazon is targeting.

~~~
franciscop
Amazon is succeeding _despite_ of this. Imagine where it could be it if was
also fast!

As a workaround, now when I want to search something in amazon I just google
for "amazon [what I want]"

------
superkuh
>Or consider not using a framework at all. For websites that primarily display
content, it’s more efficient and cost-effective to just send some server-
rendered HTML down the wire. If there are areas of your website that require
interactivity, you can always use JavaScript to build those specific parts.

This should be the takeaway from the article. There's absolutely no need for
javascript on most websites that use javascript. I understand if you're forced
into it by the time and economic contingencies of your work but if you bring
JS frameworks home to your personal sites you're doing it wrong.

~~~
StreamBright
Exactly. I avoid JS as much as possible. Unfortunately most of web developers
want to develop SPAs regardless of the actual need of the projects.

~~~
hahamrfunnyguy
I prefer the MPA (multi-page application) approach for most projects. If
interactivty is needed, I use REST services and a data-binding framework on
the front end.

~~~
jessaustin
Can you recommend any such frameworks?

~~~
the_gastropod
Stimulus is is a pretty good example of a simple JS framework that binds via
data attributes. It, coupled with Turbolinks or Pjax, should let you do nearly
anything you'd typically use a more popular front-end framework for, for much
cheaper. Check it out: [https://stimulusjs.org/](https://stimulusjs.org/)

~~~
jessaustin
Thanks, that looks really cool.

------
maxfurman
I'm not surprised that Angular ships a larger bundle than React and Vue, it
intentionally covers a much larger surface area of functionality. But Angular
also includes build tools meant to reduce the size of the final bundle - can
anyone tell if those were used in this comparison?

~~~
jamamp
Yes, his Angular page [0] uses AoT compilation which results in the bundle,
instead of individual files by default (meant for development only).

Also I agree with you. It's a bit unfair to be comparing a barebones Angular
app to a barebones React/Vue app (even with a router library for each of
those). Angular also has a forms and validation library already installed, and
its dependency injection framework, etc. The baseline React/Vue apps don't
have those pre-installed, which you would typically install when building an
actual app.

[0] [https://angular-ngrx-router.netlify.com/](https://angular-ngrx-
router.netlify.com/)

~~~
Drdrdrq
That's kind of the point though, right? If you don't need forms, can you
remove them in Angular?

While we're on the subject, does anyone know a good forms and validation
library for React? :-)

~~~
davnicwil
If you're using redux, I can't recommend redux-form enough. It's genuinely one
of the best designed libraries I've ever used, including other
languages/stacks etc. I think a little hard to grok at first but once it
clicks you realise that it's such an elegant way to manage all form state you
could ever have a need for, and it just works out the box.

Comes with an inbuilt validation mechanism in the form of a function with
errors piped through to fields etc, if that's what you meant? The actual
validations you have to write yourself though. I typically do this by
hand/regex rather than use a library for that on the client, to be honest, as
it's usually pretty simple.

~~~
dimnsionofsound
The author of redux-form created another library, final-form, that doesn’t
need redux or react and has most of the features of redux form and has built
in lessons he learned from writing redux-form. There’s a separate React-final-
form package with easy React bindings as well if you’re using them together.
It’s worth a look as well (I’ve used both).

~~~
e12e
[https://github.com/final-form](https://github.com/final-form) ?

------
Bahamut
One thing it should be noted with Angular is that there is currently work on a
new renderer that should allow framework bundle size to be optimized with the
whole framework being tree-shakeable.

I wonder how Angular would compare once that is done, as this has long been
known as probably the main negative with Angular performance-wise, the initial
load (but it should be faster than most of the rest once it does load).

~~~
coding123
Really faster than react? Having a hard time with that one...

~~~
Bahamut
For all numbers excepting initial load, everything I've seen shows Angular is
significantly faster than the rest - the difference is more pronounced with
more DOM nodes. Angular also has the advantage of incremental update, although
React will also gain that benefit within a year as well.

Note: I used to work primarily with Angular, but I currently use React since
the coding style encouraged with React works better with the team I'm on &
React is fast enough to us.

~~~
ralfn
>everything I've seen shows Angular is significantly faster than the rest

That contradicts every published test.

It is also hard to imagine. Angular is both reading and writing the DOM.

And i haven't touched it after they switched to a new version, but in the old
version they noticed state changes by contiously comparing all of your state.
(so more state meant it would be slower).

I'm assuming they switched to a more native implementation of the observable
pattern in the newer version, rather than that pathetic hack.

Of course neither React or Angular are as fast as hand written code. Since,
what both take responsibility away from the developer. In the case of React:
don't worry about what you need to update, just re-render the whole thing
again. Simpler code, and the performance price you pay for it is somewhat
limited because it then diffes a virtual dom.

Angular's approach, annotating HTML however, simply reinforces what we learned
later: that is was written by someone with absolute no experience as a front-
end developer. Because performance wise it's about the dumbest thing you could
do. Every time you switch from writing to the DOM, to reading the DOM you
force the browser to do another layout&paint and for all of that to happen
synchronously, instead of the concurrent model that modern browsers actually
offer.

What has happened is that these frameworks have become the new platforms.
People don't realize that everything from online chess games to google maps
isn't written using these frameworks and it's questionable any of them could
do that with good enough performance.

At our company when recruiting we now distinguish actual front-end developers
from angular or react developers. They may know these frameworks, that does
not imply they could write them or understand enough of front-end development
in general to debug actual cross browser issues, performance issues or
rendering issues. And we give them a test that requires building something
complicated in pure html/css/js.

~~~
Bahamut
> And i haven't touched it after they switched to a new version, but in the
> old version they noticed state changes by contiously comparing all of your
> state. (so more state meant it would be slower).

Are you confusing AngularJS and current Angular? AngularJS is certainly wholly
slower than React, but not Angular 2+.

------
55555
I used to write all my static sites using Hugo, until I saw a site that was
built using Gatsby. Gatsby has a larger overhead on the initial page load but
feels much faster and subsequent page loads have less overhead (or maybe more,
if it's prefetching a lot of adjacent pages which you'll never navigate to).

It seems to me that the next logical step is a site that ships the initial
page request in vanilla JS, then async loads react and then async fetches the
overhead and then runs Gatsby. This would be the ideal if we're optimizing for
_perceived_ latency. So the first page load is fast, then as long as you stay
on that page for a second or two before clicking elsewhere, everything after
that point will be snappy too.

Ofcourse, many other devs are optimizing for network usage, etc, so to each
their own.

~~~
prophesi
You can attain Gatsby's SPA feel/speed with Hugo, via Turbolinks[0]. A much
smaller overhead on initial page load, and you can hook up a service worker to
do any prefetching/caching.

[0]
[https://github.com/turbolinks/turbolinks](https://github.com/turbolinks/turbolinks)

~~~
55555
Awesome, thank you. I dislike working with Gatsby and much preferred Hugo.

But what about prefetching?

~~~
prophesi
From my experience, it seems like you'd have to jump through a few hoops to
get prefetching working with Turbolinks. I just relied on having my service
worker do all of the prefetching/caching of the site's important pages +
static assets.

------
nikkwong
Tangental, but it's frustrating creating a website and optimizing it for
performance down to the bone; and then having 'mission critical' plugins
totally rip the potential performance gains to shreds.

My ecommerce site [0] (built on a custom stack, not shopify; making it orders
of magnitude faster). I got it down to 600kb with 27 network requests total
(with it being heavily media/image based). Now find me any other ecommerce
site which can boast a comparable network payload.

Unfortunately, after throwing google analytics + fb ad trackers + a chat
widget + a youtube video, the network requests have ballooned to 100+. It's
very ironic how these companies promote the development a performance driven
web, but the tools they want us to embed do quite the contrary. They do,
however, offer a lot of value. What to do?

[0] — www.getfractals.com

~~~
spullara
Your site is still really fast compared with almost all ecommerce sites. I
built the backend for a friend of mine's blog and I always use it as an
example of how fast the web could be but yours might be a more impressive
example:

[https://www.lukew.com](https://www.lukew.com)

~~~
nikkwong
Thank you kindly! The site you have attached is also rocket speed!

CMS's like shopify offer great value, and are a great starting place even for
technical folks. However I think the lack of prioritization they've placed on
the performance of sites on their platform has overall been a net negative for
e-commerce at large. The mobile experience of most shopify stores is usually
atrocious and the inclination to bounce before page load is all too real.

I understand they are working with an old stack, and changing course may be
nigh impossible at this point. However, I built my stack in 2014, and the
dividends of doing something custom vs the status quo have more than paid off.

------
fold_left
Damn, Svelte is not on there. I'd be curious what the author thinks to it as
an approach [https://svelte.technology/](https://svelte.technology/)

~~~
nailer
I was about to say, this is precisely the reason Svelte exists. I rewrote my
personal site in it a year ago [1], and the development experience was similar
to a Vue or Ractive app, but with compilation (ie, the resulting webpage
doesn't have Svelte included - it's just _my app_ specifically compiled) the
result was tiny.

[1] [https://mikemaccana.com](https://mikemaccana.com), probably has a lot of
small bugs since I spent my time working on more important things.

~~~
KaoruAoiShiho
Couldn't SSR with later JS hydration be just as effective at getting instant
startup?

~~~
nailer
Svelte also does SSR (if you set it up, which I haven't bothered), but you
don't have to pull down a whole framework, so the hydration step is much
faster.

~~~
KaoruAoiShiho
Right, but with SSR the other frameworks basically have no downside. Their
loading is also instant. A 1 second long hydration is not a big deal.

~~~
nailer
1000ms hydration may be a big deal, hydration may also take more than 1000ms.

~~~
KaoruAoiShiho
What matters to people is the content loading and being able to see the page.
For the majority of apps the hydration is almost irrelevant because the time
it takes to read the page and decide to interact with it takes vastly more
than 1000ms, though there could be exceptions. It's certainly the case for all
the apps I've worked on.

~~~
untog
It can still cause things like janky scrolling while the JS is parsed. Less JS
is never ever going to be a bad thing

------
monsieurbanana
> your React application will never load faster than about 1.1 seconds on an
> average phone in India, no matter how much you optimize it

What about cache? In that 1.1s figure, 0.9s are for the download of react.

Is it reasonable to assume that for most subsequent loads the website would
load in 0.2s?

~~~
pjmlp
HTTPS everywhere kills caches, in the sense that only end devices can provide
them, but other network nodes not.

Check Eric Meyer's complaints.

~~~
iaml
Does it also affect caching via service workers? Pretty standard practice in
PWAs.

~~~
pjmlp
No, but it impacts the initial download as it needs to be end to end, instead
of the closest access point.

Also a very good way to waste traffic quota, e.g. a school network connection
vs students computers.

~~~
pythonaut_16
Which interestingly is a problem IPFS would solve, right? But IPFS potentially
introduces other drawbacks.

It would be cool to able to build dual-distribution applications, where
publicly available assets and content blobs (e.g. app.js) could be distributed
in an immutable, cache-able manner, and server interactions and private assets
could still be handled in a more traditional client/server way.

Perhaps then we might even be able to realize the original intent of including
dependencies from a CDN, being able to share a cached version of React across
websites.

(I'm not and IPFS advocate or detractor)

------
yuribit
A nice way to improve the time-to-interactive is to prefetch the framework
after you load an initial basic page.

Here's Addy Osmani explaining how it works: [https://medium.com/dev-
channel/a-netflix-web-performance-cas...](https://medium.com/dev-
channel/a-netflix-web-performance-case-study-c0bcde26a9d9)

~~~
hinkley
Used that on my first Ajax app. It was authenticated so we pruned the JS on
the login page like crazy and added a script that injected the main bundle
into the page after page ready.

Worked great for everybody not using a password manager...

------
hayksaakian
That's assuming you don't do any server side rendering right?

I can send completely readable html over the wire that becomes interactive
once the JS finishes loading.

What am I missing.

~~~
dancek
The days of work needed to set up server-side rendering?

I realize I must look stupid saying this, because when you know your tech
stack inside out the setup might be 15 minutes instead of days. But a large
proportion of developers only learn to do things when they have to, and so you
learn server side rendering the first time you have a customer willing to pay
for the time it takes you to learn.

~~~
tboyd47
"SSR" is the default behavior of most pre-2016 web frameworks. Only when
ReactJS became hip did it appear on lists of nice-to-haves that people weigh
the pros and cons of.

~~~
dancek
Yes, I'm talking in the context of SPA frameworks (which the article referred
to).

------
astockwell
I'm the only person on my current team (an internally-focused engineering
team) who has experience building websites/apps for __external paying clients
__(e.g. people who will freak out if anything fails to load faster than they
can blink, on their phone 's 3G connection).

I was taken aback by how many times I had to argue with my team, our sister
teams, our consultants/contractors, and even our (non-technical) leadership
about NOT building a SPA when we came across 1 form in our large codebase that
required some extra interactivity.

For some reason many developers seem to be fine turning a blind eye to the
actual page-rendering time, maybe because it's hard to benchmark with tools?
(although I'm skeptical of that). I find an overlap however in that those same
developers seem to not understand why multiple database query roundtrips are
worse than 1 query followed by some in-memory munging.

I'm sure I'm biased by my background, where we were profiling like mad, doing
crazy things like purposely modifying images/hand-building sprites to pack
better, minifying CSS before SASS/LESS existed, and every millisecond to
finish rendering mattered. Good times.

~~~
paraditedc
Really depends on what is your product and how users use it.

If the user just visit a few pages every time, you probably don't need SPA.

However, if your website has hundreds of pages and users need to navigate
around a lot, SPA would actually reduce load time by cutting down the amount
of data being transferred over network every time users goes to a different
page. It also makes the experience navigating between pages smoother.

~~~
gondo
browser cache solves this problem

~~~
paraditedc
Curious what's the strategy you use to invalidate browser cache for non-SPA?
When deploying new changes.

~~~
gondo
versioned url

~~~
paraditedc
Sorry if it is not clear, I was referring to html files returned by servers
when user visits old-fashioned server-rendered web pages (non-SPA pages) like
`/page1` or `/page2`.

How do you version urls like those?

Something like `/page1?t=201811292359`? That seems ugly to the users.

~~~
gondo
rules i use:

\- content under certain url should never change

\- if it has to change then use ESI or/and smaller cache expiration times

\- if it has to change very often/realtime, then use static html as skeleton
and load only required information via javascript. f.e.: info about currently
signed in user, eshop basket

------
lioeters
This is why I'm a happy user of Preact - the core feature set of React minus
the bloat. Especially with some recent additions to React (context, hooks)
which I don't have any need for, I'm glad to stay with the smaller surface
area of Preact instead.

~~~
brlewis
Preact is the most React-like small framework, probably the best for your
resume and for hiring people who want a good resume.

Mithril is the small framework that most directly addresses the issues brought
up in this article. It has routing built in and comes with a small streams
library that, for apps I work on, is all the state management I need.

For those who really love JSX, Inferno is a really clean, small React-like
framework. Its advantage over Mithril is that JSX expressions evaluate to
components, not vnodes, so your HOC code will be slightly cleaner.

------
underwater
> If you want your application to become interactive on your users’ devices in
> under 5 seconds, can you afford to spend a fifth of that time just booting
> up React?

If you care about load time you should pick a framework because of the value
it brings, rather than what it costs. That one second overhead might make your
application code twice as efficient.

For example Next.js and React will give you route based bundle splitting and
navigation preloading for free. Yes, a vanilla JS app could implement the
same, but requires a lot more boilerplate to achieve. So in practice most devs
are more likely to skip that part and their lightweight no-framework app
becomes a bloated mess.

~~~
conanbatt
I switched a classical html stack to a next.js app and although the first page
load is definitely lagging, the speed gains of inter-page navigation is
incredible. People navigate 70 pages within a couple of minutes.

Definitely worth it for many modern-day usages.

------
arendtio
I wonder how much bootup time Ember.js takes nowadays. I mean, a few years
back Ember was probably the worst when it came to initial loading times (it
has other strengths), but I heard it got better over the years.

------
commandlinefan
> Frameworks exist for a reason.

People keep saying that...

------
austincheney
> Truth is, when you build your application on top of a modern JavaScript
> framework, you agree to pay a certain baseline performance cost that can
> never be optimized away. In exchange for paying this cost, you gain
> maintainability, developer efficiency, and (hopefully) better performance
> during runtime.

All of that is completely subjective except for that final bit about runtime
performance. I bet nobody can prove runtime performance improves in
correlation with layers of abstraction.

~~~
snaky
It depends. ML or ATS code can perform faster than hand-written C code,
despite the fact both MLton and ATS compilers actually generate C code,
effectively adding the layers of abstractions.

And you can have the verification for free also.

> We introduce a new approach for implementing cryptographic arithmetic in
> short high-level code with machine-checked proofs of functional correctness.
> We further demonstrate that simple partial evaluation is sufficient to
> transform into the fastest-known C code, breaking the decades-old pattern
> that the only fast implementations are those whose instruction-level steps
> were written out by hand.

[http://adam.chlipala.net/papers/FiatCryptoSP19/FiatCryptoSP1...](http://adam.chlipala.net/papers/FiatCryptoSP19/FiatCryptoSP19.pdf)

~~~
austincheney
Compiler output isn't an abstraction. It's what is ultimately executed where
the compiler's source sample is not. For an apples to apples comparison I am
claiming the code compiled from a framework is going to be slower than well
written code without a framework. I am also claiming you well be painfully
challenged to prove otherwise.

Frameworks don't exist to make code faster. They exist to provide an
abstraction layer.

------
neya
It's simple. Don't use frameworks for content consumption. It adds no value to
the end user. No, I don't need your full fledged my-data-sucking SPA just to
read an article on your site. Keep it simple.

The best example?

[https://www.react.rocks](https://www.react.rocks) is a site built on react to
advocate people to use React.

This is how it looks like without JS.

[https://webcache.googleusercontent.com/search?q=cache:WRll6h...](https://webcache.googleusercontent.com/search?q=cache:WRll6h8NQc8J:https://react.rocks/example/react-
chrome-redux+&cd=6&hl=en&ct=clnk)

A site built on React to advocate React doesn't serve its primary purpose. The
irony.

~~~
enlyth
I don't understand your complaint here. Your issue is that a site written with
a JS framework doesn't load without JS? The HN anti-JS brigade will never
cease to amaze me.

You think the 0.001% of people who browse with JS disabled are the primary
target for such a website?

~~~
ebcode
>You think the 0.001% of people who browse with JS disabled are the primary
target for such a website?

Because you obviously grabbed this number out of thin air, I would like the HN
community to know that the actual percentage of users without JS is much
closer to 1%[0].

[0] [https://gds.blog.gov.uk/2013/10/21/how-many-people-are-
missi...](https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-
on-javascript-enhancement/)

~~~
wafflesraccoon
Do you have any updated sources? This data is from 2013.

~~~
ebcode
No I don't, unfortunately. But I imagine that this figure will be fairly
stable for the foreseeable future. There are always going to be people with
disabilities who turn off JavaScript for accessibility reasons, and privacy-
conscious individuals and corporations that have it disabled.

I think the parent comment's exaggeration of the number is bad form for web
developers, and goes against the spirit of the web, which I believe is based
on the principles of universal access and inclusiveness.

~~~
wafflesraccoon
I have no data here, I would guess that number would be lower today than in
2013. My reasoning being the proliferation of smart phones in second and third
world countries and the general trend of more web 2.0 users, though I fully
accept that this is just an educated guess.

As a web developer, for me the problem is that writing anything modern without
JavaScript is a much harder task that only really benefits a small minority of
users. I'm unfamiliar with any disabilities that would require JavaScript to
be turned off but I could see this being a valid usecase.

~~~
ebcode
Just found this from 2016: [https://blockmetry.com/blog/javascript-
disabled](https://blockmetry.com/blog/javascript-disabled)

That post also implies that the figure is stable.

Your second paragraph is a perfect example of the kind of attitude that I
think is problematic. Yes it's more work to accommodate non-JS users. But so
is building ramps for people in wheelchairs. The discrimination gets "baked
in" to your/our development processes, and you/we justify the discrimination
based on the idea that the only ones who will suffer from it are a "small
minority".

It's like assuming that everyone uses a mouse. Clearly some don't, and if we
develop the web based on that assumption, we're going to leave a lot of folks
in the lurch. We should hold ourselves to a higher standard[0].

[0][https://webaim.org/standards/wcag/checklist](https://webaim.org/standards/wcag/checklist)

------
mLuby
This isn't about JS frameworks, it's about rendering data on page load.

Whether the server renders the data into HTML it responds with or there's some
XHR request made by a client library (including VanillaJS) or framework,
you're always incurring some cost. But data-on-load what users generally want
and expect from modern web apps.

Having recently built an almost 100% HTML-based web app, I can tell you the
user interactions feel unpleasant. Removing JS from web apps is silly at this
point.

------
monkeynotes
Comparing a barebones view layer libraries (Vue, React etc.) with full
frameworks (Angular, Ember etc.) is not comparing apples to apples.

~~~
ilovecaching
I'm assuming you didn't read the article? He was comparing react + redux +
react-router using create-react-app compared to Angular. So it is an apples to
apples comparison.

~~~
monkeynotes
Even if you add redux and react-router you still don't have feature parity.
The comparison is inherently arbitrary. All I really know from his experiment
is if I load up a feature rich framework vs. a bare-bones view+route+state
combo the framework is going to be heavier. Is that really news?

------
paraditedc
I am surprised by the fact that author completely ignores client side caching
using browser and service worker, as well as SSR.

One key point of PWA is that it works offline and loads faster after after
first load (even after you deploy new changes, with basic service worker
configs from sw-precache). So you need 1 second for _first load only_.
Subsequent loads are much faster.

------
rinchik
Why would you compare React/Vue vs Angular??? I don't think the author
understands the difference between frameworks and libraries.

React vs Vue can be a valid analysis, same as Angular vs Ember. It's silly to
benchmark React/Vue vs Angular/Ember.

Lets create a benchmark of ponies vs zebras/horses!

~~~
wuliwong
Seems pretty clear they understand the difference judging by what was written
in the article.

~~~
rinchik
Do they though? have you read the article? Medium says its a 5min read. 5min
of a completely wasted time. Btw its says right here that react is not a
framework [https://reactjs.org/](https://reactjs.org/).

Always amazed how people calling themselves "engineers" while being unable to
grasp such simple, basic nuances.

------
spankalee
This is why obsoleting frameworks by expanding the native component model of
the web is good for the world.

~~~
zanny
I'm really loving just casually writing websites for Rust web frameworks
because I get to try out all these new tricks in html / css / ecma7 to avoid
pulling in any third party libraries. Then you get goodies like compile time
templates and regexes while having only 30ms from initial request to tls
handshake to routing, request handling, response and rendering all done (on
the same network).

------
btbuildem
Including megabytes of unrelated .gifs in the blog post kind of undermines the
point here...

~~~
wuliwong
I don't agree. Those gifs are explicitly added. The author's point is about
load times that are relatively unavoidable.

------
vdnkh
Please stop using gzip size for these sorts of comparisons. One, gzip affects
download speed, but _not_ JS evaluation and compilation. Two, it makes the
libraries seem much smaller than they actually are.

~~~
jefftk
_> One, gzip affects download speed, but not JS evaluation and compilation_

They measured scripting time directly, which is a much better measurement than
uncompressed bytes.

 _> Two, it makes the libraries seem much smaller than they actually are_

Would you prefer they gave unminified sizes as well? The gzipped size of a
library lets us predict how long it will take to download, and how much that
will cost for users.

------
innocentoldguy
Of all the client-side JavaScript libraries available for making responsive
web applications, I've found that Elm suits me best. I haven't done any
benchmarks, but it feels faster than React and Angular to me and the Elm
compiler eliminates virtually all runtime issues before I ever deploy my code.

Another alternative to large client-side libraries I've been looking at lately
is Phoenix's LiveView. It is a server-side rendering library that uses web
sockets. I've only just started using LiveView, but so far my pages seem to
perform better than React or Angular.

~~~
RobertKerans
Given Live View was only announced two months ago, is in development, and
hasn't been released in any form whatsoever, I'm curious as to how you've
managed to use it to make that comparison?

~~~
innocentoldguy
Duh! Sorry, I meant Drab. I had LiveView on the brain. You can check it out
here: [https://tg.pl/drab](https://tg.pl/drab)

------
KaoruAoiShiho
He's not using SSR which is wrong in 2018. Vue's startup performance will also
supposedly double in the next version. Looking forward to that.

~~~
wishinghand
Do you mean halve? That's what I took away from the twitter post by the
creator Evan You.

~~~
KaoruAoiShiho
Performance double, time halve. I think my comment was fine.

------
ivanhoe
To better make sense of this data it needs to be compared against the time
needed to build a non-trivial interface using each of the frameworks.

~~~
10-6
This is exactly right. A lot of posts regarding loading times or bundle sizes
for frameworks/libraries forget that there are trade-offs when it comes to
building an application.

The correct way to frame this is: use a _slow /clunky/large/etc_ framework vs.
build everything from scratch (which comes with its own costs).

Sure, you can optimize parts of your application to speed up the JS portion or
even remote it completely [1], but it's not always as simple as "your
framework is making your application slow so you should think about ditching
it."

This article actually ends with a very reasonable conclusion in the section
"Are Frameworks Evil?" but I've seen plenty of articles where the author
doesn't offer an alternative to some library/framework [2].

[1]
[https://twitter.com/netflixuie/status/923374215041912833?lan...](https://twitter.com/netflixuie/status/923374215041912833?lang=en)

[2] [https://dev.to/gypsydave5/why-you-shouldnt-use-a-web-
framewo...](https://dev.to/gypsydave5/why-you-shouldnt-use-a-web-
framework-3g24)

------
hn_throwaway_99
The main conclusion from this article isn't accurate. This is one reason to
load common libraries from a known CDN so that if any website has downloaded
that library version previously, and the user's cache has not been cleared or
expired, the next time that library can just be loaded from cache, even if
from a different website.

~~~
robin_reala
Historically that was a major security issue. It’s less of an issue now that
SRI exists (you’re using SRI, right?), but it’s still a problem when you have
a broken pathway to the CDN but your site loads OK. Well, assuming you’re not
building with progressive enhancement. You’re building with progressive
enhancement right?

~~~
hleszek
sorry what is SRI ?

~~~
robin_reala
Subresource Integrity. It’s designed specifically for this scenario: a
resource included into your page from a seperate server that could potentially
be compromised. Your hash the known good resource and include that hash in
your script or link tags as an integrity attribute. When the user’s browser
downloads the resource it’ll hash it again and check for a match. Only if the
two match will it parse and execute the contents.

[https://developer.mozilla.org/en-
US/docs/Web/Security/Subres...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity)

------
kmitz
It doesn't mention framework versions..

------
jorblumesea
Not using server side rendering, not using a cdn or some form of caching. Not
sure this is a good test of anything other than how to fail at implementing
SPAs.

------
Battochon
This person doesn't know a thing about Angular and he is benchmarking it?!
Angular is not loading the whole RxJS and I doubt AOT was setted properly.

This is a misleading paper again. I would like that 3 experts on each
framework do their best to provide the same app and then we could compare.

~~~
copperx
This isn't a research paper.

------
agentPrefect
> in exchange for paying this cost, you gain maintainability, developer
> efficiency, and (hopefully) better performance during runtime.

You also gain responsiveness to user interactions, a programmatic way to
reason about your application/website & and some animation-sugar if you want.
Don't throw the baby out with the bath water simply because people follow
trends instead of good design practices.

~~~
Roboprog
And in my case, less Java I have to read or write on the back end :-)

I agree, though - it’s much easier to reason about the data integrity and
security when there is a smaller code base on the back end, by virtue of
splitting user interface concerns off to a front end code base.

I’ve been programming since the 80s, but I’d rather write FP code in JS than
OOP code in Java - so long as I’m not doing anything to make the app work
badly for people. So I’ve gravitated towards front end work the last 3 years
or so.

Another rant for another time...

------
shaunpersad
> your React application will never load faster than about 1.1 seconds on an
> average phone in India, no matter how much you optimize it

Weren't your assets deployed on Netlify's CDN? Shouldn't that make location
roughly irrelevant (assuming enough PoPs)?

~~~
ht85
He's referring to the typical phone performance (parse and execute) and
network bandwidth for an Indian user, not the network latency.

