
Putting Devs Before Users: How Frameworks Destroyed Web Performance - CM30
https://medium.com/@CM30/putting-devs-before-users-how-frameworks-destroyed-web-performance-6b2c2a506aab
======
karaterobot
I don't think engineers use frameworks because they think it makes them look
cool. They may choose between multiple, competing frameworks based on
community perception, but not between using a framework and not using one.

It's usually an argument from business needs that leads to application bloat.
For example, what PM on a startup would sign off on spending two weeks to
implement a custom date library and date picker component when there are
excellent, if sizable options available to install _right now_? What small- or
medium-sized company is going to create an in-house application framework when
React is very good, and there are thousands of people you can hire who already
know how to use it? A major reason applications get bloated is because
development time costs the company more than client bandwidth and CPU do.

So, in that sense, it's not a matter of convenience either: It's a selection
made based on weighing the constraints and options and selecting the best one.
If poor application performance started costing companies a lot of revenue,
I'm sure the result of the calculation would change.

~~~
flomo
> I don't think engineers use frameworks because they think it makes them look
> cool.

I've been in this line of work for a long time, and I'll admit its a huge
factor. Webdev is a very fad-driven business, and I've seen numerous
technologies come-and-go where they were hot, but not they are now super not.
And to some degree this is logical, because you want people who can adapt to
whatever is latest-and-greatest and not just a particular platform. But when
recruiting it certainly helps.

Plus the old chestnut that 50%-80% of software projects are failures, and
looking out for number one means resume-oriented development for the next job.
You are probably better off with a failed project on a 'cool' framework than a
successful project on an uncool one.

~~~
thinkingemote
I've talked to several really enthusiastic developer advocates about
technology in the corridor and when it comes to describing the actual product
or use of the technology they tend to mumble, or wave hands, or state some
product that HN would argue about (e.g. advertising). All the developer
advocates I've met who promote latest tech really don't seem to like their
companys product.

I would say that developers try to make it a fad to keep themselves interested
and engaged in an otherwise boring, soul destroying or socially harmful job.

~~~
gdev20
Don't forget that a dev may need another job in the future. And it doesn't
help finding one when spending the last 2 years building an app with some
"oldschool" tech stack that performs well. Most companies are looking for
dev's who worked with the cool fancy stuff like react because that's already
the tech stack they are using.

And what is so bad trying to make my job interesting? If it's boring I
wouldn't care much about the end result. Just another 9 to 5 job then.

~~~
thinkingemote
Nothing bad about making something interesting. You would be interested in the
end result - but for developers who do this the end result is the technology
they produce and not the product that the tech is being used for.

I think it would be one of the reasons why "putting devs before users"
happens.

Also - look at the HN Who's Hiring threads. Almost all postings don't talk
about the product or their users. They talk about the technology.

~~~
gdev20
That's true, in most of the company's I worked (includes the current one) I'm
not interested in the product at all. I work there because I can decide which
tech stack we use, try and learn the fancy stuff and have some fun building
it. Why? Because I can - I am one of the few "good" dev's out there. So many
companies are hiring and they take what they can get. And I as a dev can
choose where I want to work. And of course I choose the interesting one. In
conclusion there are much more companies hiring then good dev's looking for a
job. So the company has to make itself interesting for dev's.

But I don't think that's bad at all. With modern devices and Browsers you
can't tell the difference between using a framework or not.

~~~
6510
That was a funny bit of honesty. You should have stuck with it till then end
and tell it like it is: It doesn't work on slightly older devices. Or
something like: You really notice things don't work when using a slightly
older device.

Jokes aside, I cant seem to find data on the age distribution of interneted
computers.

~~~
gdev20
You are the kind of person who believes that every app should support ie8 and
even before that, right? Don't forget to limit your 500ps car to drive only
25mph...

~~~
6510
It isn't your fault they hire people who don't care about the product. That
you pick a tech stack that inspires you is a logical [and predictable] follow
up.

I think a lot of people still think things are/should be something like: First
the product, 2nd the customer, 3rd the company, 4th the investors and the
employees last.

But the reality is often more like: First the investors, 2nd the employees,
3rd the company, 4th the customer, and oh we need some kind of product too!

You get the open floor plan so that the investor can see lots of people
working. A nice ping pong table to illustrate the lack of employee equity. A
fun tech stack to attract and keep the employees happy. Large expensive chunks
of plastic with the company name on it. Great customer service to help the
customer with _their_ problems and lastly a product that doesn't work.

Again, I'm not suggesting any of this is your fault. On the contrary, one cant
teach passion. You either care about the product or you don't.

------
taurath
Frameworks allow websites to be built faster, maintained with less expertise,
and changed faster over time. That is the benefit to the user. That things are
slower than they could be doesn't matter to most users. Most companies can't
afford to pay people to maintain a "good + fast + quick to make changes" site.

There's an argument to be made that if business would just simplify their
needs and desires to make sure everything is simple and fast, isn't that in
and of itself putting devs before users? This works both ways.

Also, if you don't want to pare down your features to barebones, and you're
not going to use a framework, someone's inventing one. If you have someone
who's going to build you a superfast framework and be a cool hacker, then you
probably can't afford them, or you can't afford to keep them. Then we get a
post on HN about how bad this one coyboy coders's framework was and all the
effort that was spent to modernize using %modern_framework%.

~~~
jblow
If this is true, then why does it take so many engineers to make web sites
today?

People keep claiming these things increase productivity, yet there seems to be
very little evidence of productivity increase.

~~~
csande17
+1. For example, according to one of their job listings[1], Twitter currently
has 25 people working on the main twitter.com experience.

Twenty-five people! For a Twitter client! And they're still trying to hire
more! (Important to keep in mind: this doesn't include any of the people
working on the database, or the advertising algorithm, or the server
architecture, or any of the other hard problems Twitter faces. This is just
the team that writes the JavaScript code that takes the Tweets from the JSON
API response and puts them onto the screen.)

[1] [https://careers.twitter.com/en/work-for-
twitter/201910/twitt...](https://careers.twitter.com/en/work-for-
twitter/201910/twitter-com-senior-javascript-engineer.html)

~~~
jogjayr
I'm shocked it's only 25. I would have expected an order of magnitude more
given the number of features and sheer reach of Twitter. That can't possibly
be right.

Not sarcasm btw. I think you're underestimating how much work there is.

First, there are a ton of features: lazy-loading tweets, retweet, favorite,
lists, all the stuff related to analytics, settings. Simply maintaining that
stuff with security updates and bugfixes is a significant commitment.

Then there's accessibility and localization to consider.

Next there's fix and feature experimentation. They probably don't release new
features and fixes to everyone at once. Instead they roll them out slowly, or
show different versions to different users, compare, analyze and iterate.

Browsers update approximately every 6 weeks, so that's something to keep
abreast of. At Twitter's scale, a CSS rendering bug that affects 0.1% of
sessions will be seen by hundreds of thousands of users.

And it's not just "a Twitter client". It's THE Twitter client - the canonical
one. It has to have higher standards of performance, quality, and reliability
than a random Twitter Android or iPhone app.

~~~
Izkata
> Then there's accessibility and localization to consider.

For anyone unaware, Twitter's whole UI changes to support right-to-left
languages, not just the text.

------
xg15
I find this development incredibly sad. Originally, SPAs looked promising from
a technical perspective because they could potentially eliminate lots of
redundant server-side HTML rendering and duplicate transmission of data
(because templates, code and data items could be cached on the client and
assembled as needed).

Today, we somehow seem to have gotten the worst of both worlds: We got the
additional overhead of client-side rendering but we can still not reliably
cache data, so not a lot of processing or bandwidth can be saved.

~~~
mikekchar
For me the main appeal to SPAs are testing oriented. Assuming I need some kind
of interactive functionality that can't be done using a form, testing across
the browser interface is difficult when doing HTML view production on the
server side. If you are doing HTML view production on the client side,
suddenly it's much easier. I test that the server produces the correct data
given a request and I test that the client renders the correct views given the
data. In Michael Feather's parlance, I've got a viable "seam" for testing
against.

~~~
cousin_it
But if something can be done with links and forms, SPA makes it harder to
test. So I prefer using JS only for islands of interactivity within specific
pages, not making the whole application one big island.

------
fyfy18
I originally started my career as a Rails developer, and for the last few
years have been doing more frontend JavaScript (React), as that's where the
€€€ is. For all of the projects I've worked on, server-side rendered Rails
would have been a much better stack choice. It would have been quicker to
develop for, easier to hire for, and more performant to the end user.

Now I'm not trying to say this works for everyone, maybe when you get to
unicorn scale it makes sense to do something different, but these are small
projects with no more than a handful of developers. Hiring React developers is
easy, hiring Rails developers is easy, but hiring developers who know both
well is much harder.

Most of the projects have been for pre-revenue startups, so what's important
at that stage is speed of development. You really can't beat Rails for
development speed of CRUD applications (which let's be honest, most apps are),
and then you can add a sprinkling of JavaScript on top for some modern
features (and with something like react-rails you can easily integrate React).
If at a later stage you need an API for mobile applications, Rails makes that
easy (you can even share the same code for API endpoints and regular HTML
views).

In terms of performance, at this stage of a company you can get pretty far by
horizontal scaling. Rails is a fairly mature framework, so it's easy to
maintain and isn't going to introduce any breaking changes anytime soon -
compare this to one of the projects I worked on, which is stuck on React 15
with vanilla JS and probably will never be upgraded.

Now just to repeat I'm not saying this works for everyone. Another project I
recently worked on was a React + Typescript app. There was already an existing
GraphQL endpoint and it needed a lot of interactivity, so Rails wouldn't have
been a good choice here. But for a lot of projects I'd say that server-side
rendered Rails is a better choice. it may not be sexy anymore, but if you are
a startup and want to get something done fast and for it to be maintainable,
it's probably the right choice.

~~~
candiodari
I wish more people would think like this. Javascript only gains you in latency
if you handle things locally - which _nobody_ does. That means that server-
side rendering beats pretty much all SPA's, and somehow nobody cares. And if a
client action results in 5 requests, as it often does, then server-side
rendering is a _lot_ faster.

Or to put it directly: craigslist is faster than amazon.com. And, frankly,
more fun to use.

------
jkoudys
Html is a language. CSS is a language. JavaScript is a language. You can build
the Dom by loading html, and you can build the Dom by making calls from JS.
You can write style rules against a selector using CSS, or you can write some
declarative JS that looks almost the same but with more commas and fewer
semicolons. Going back to the good-old-days isn't going to save you since the
language is incidental.

Anyone who puts up their first Gatsby site is going to be amazed by how fast
the performance feels. They certainly won't be wishing they'd burned their JS
stickers.

My biggest problem with the article is that it ignores the cost of "putting
users before devs". Writing the simplest, most performant iteration of a site
that matches the minimum requirements as you perceive them for today's users
isn't that expensive. But that approach crumbled quickly as parameters change
slightly. You're one bad focus group or new CEO away from needing to
completely rebuild from scratch, except you'll probably need to keep
maintaining the old site forever. Then the new site when it becomes the new
old site. Then the next one. Repeat until your increasingly-expensive business
is completely unviable.

~~~
TheOtherHobbes
CSS is a dystopian nightmare from a Lovecraftian dimension of metaphysical
horror.

I had to do a teeny-tiny bit of CSS work before Christmas and I literally had
to look up the edge cases and exceptions for all of the five common CSS
statements I ended up using, because they were all context-dependent in insane
ways - endless "This only works if XXXX is also applied here, but does
nothing/fails silently if it isn't, even though you might expect it to work,
and this mode is only documented on StackExchange etc because the official CSS
docs are incomprehensible and no one ever reads them anyway. And by the way,
you'll also need a file of resets for many of the most common options."

[https://www.w3.org/Style/CSS/current-
work](https://www.w3.org/Style/CSS/current-work)

~~~
jkoudys
Well... yeah.

I'm much happier using some css-in-ts solution, because then I can use
stricter types against what I define. No need to track down why my
`background-colour` isn't doing anything somewhere, or setting up some
separate tool to validate it.

While we're looking at cultural problems, this view of style-work as somehow
being easier/lighter/less-important/etc. vs the "real" code is at the root of
so many of these problems. It's very fashionable to praise functional
programming and all the virtues of being declarative, yet we can't connect
that with good practices for style.

------
JDiculous
The author makes a very weak argument, not even listing any examples. There is
no modern framework that is 2-3MB, that is absurd. The whole point of SPAs is
to increase performance. Sure there are sites with horrible implementations of
SPAs where loading the page triggers a second refresh ( _cough_ spectrum.chat
_cough_ ) or that are just outrageously slow (eg. gmail), but those are
certainly not the majority, and are caused by poor engineering, not the
framework. Poor performance is more often caused by ads (ever surf the
internet without adblock?), tracking, unoptimized images, poor client-side
rendering, etc.

Although web performance is certainly a problem, the bigger problem with the
web in my opinion is actually poor UX. Often when I'm on a website it's very
confusing how to figure out how to do basic tasks like finding the search bar.
Medium has the most appalling comment system I've ever seen, requiring 3+
clicks/refreshes to read a comment on an article.

Although I agree the web performance is a serious problem, this is a very weak
article, and I'm surprised it's on the front page. I guess people will upvote
anything that complains about web performance, no matter how poorly reasoned
and misplaced the blame is.

~~~
abraham
The median desktop site is almost 2MB. [https://httparchive.org/reports/page-
weight](https://httparchive.org/reports/page-weight)

~~~
threeseed
That includes resources like images, videos etc.

Javascript is 1/5 i.e. 420KB

~~~
Cyykratahk
The linked Medium article is over 3MB, almost 2MB of that being JS.

~~~
viklove
It's not the UI framework that's adding the bloat, it's a bunch of tracking
and fingerprinting scripts. They would still be there even if the UI was
server-rendered HTML, because that's Medium's business model!

------
peteforde
People are not using frameworks because they are fun. That is because _using
frameworks is in no reasonable way fun_.

I would argue that developers who aren't having fun are going to create bad
products. They certainly are not going to push themselves or be particularly
creative. I further don't believe for a second that the utility of libraries
like moment.js (and the many improved children it inspired) has anything to do
with maximizing "fun". Depending on your objective and perspective, they make
the job tolerable and/or possible with far fewer bugs than would exist if you
tried to build something from scratch.

I do have good news for everyone, however: you can use tools like Stimlus
Reflex (Rails) or LiveView (Phoenix) to build reactive UIs that require none
of the heavy client libraries slowing down your pages. Using these tools is
simpler, faster and indeed more fun because you're managing state changes on
the server and only delivering the bytes that have changed.

Here's a reactive tabular data navigator that supports sorting, filtering and
paging without any app-specific JS code required, period. Total JS payload is
54k over the wire, and to be clear... that's for every example on the site.

[http://expo.stimulusreflex.com/demos/tabular](http://expo.stimulusreflex.com/demos/tabular)

~~~
eftokay83
Maybe it's because I'm at work, but wherever I click on the site, it won't
work - neither on Firefox, nor on Chrome.

(No TODO items are added, no sorting will be invoked, no chat message is
submitted and no tabs can be changed).

~~~
peteforde
That is _very_ strange.

Do you have websockets disabled at the firewall level or something? Do you see
any errors in the console?

I am strongly invested in helping you get this working, so consider me willing
to help and highly appreciative.

~~~
eftokay83
Yeah seems you are right. Can't connect via websockets. Console output:

Firefox can’t establish a connection to the server at
ws://expo.stimulusreflex.com/cable. action_cable.js:241:25

~~~
peteforde
I don't like to punt, but this seems like perhaps it's on your end.
Thankfully, we haven't had other complaints of this nature and it sounds like
perhaps you have a security layer (firewall, browser plugin perhaps) that is
not giving you a neutral testbed.

One surefire way to tell is to try the site in Incognito Mode. You could also
try on your phone, although admittedly most of the demos are still slanted
towards desktop interaction. That's 100% on us and not the tech itself.

------
softwaredoug
Is it just me, or has anyone else sensed a shift _back_ from thick SPAs to
Server-side rendering precisely because of performance?

~~~
monoideism
So much of the backlash is due to the simple (but very significant) confusion
between web pages and web apps.

No one should build a web _page_ as an SPA with JS. Most web pages are ideally
suited for static site generators. Just abiding by this simple rule would make
life vastly better for users.

By the same token, it would be relative folly to try to build a chat client
using server-side rendering. It _can_ be done, but a chat client, like a
spreadsheet or email client, are all proper _applications_ , and so are
ideally suited to being built as SPAs.

There are some projects that lie in between, and in my experience, these
usually work out best if coded using a server-side framework with a tiny
amount of client JS for UI tweaks. Reddit is a good example of this. Reddit
has become significantly worse once re-coded as an SPA.

As for the whole idea of building web apps _without_ using frameworks: I lived
in the era and did just that. Usually, the result was a total nightmare, with
a rat’s nest of jQuery and various other crap. If you were lucky, you worked
for a company that knew the value of abstracting out common features and using
a pattern such as MVC or MVP. In that case, you end up with what’s more or
less a framework by the end, and indeed, most large companies and
consultancies had their own in-house client-side frameworks. If you’re doing
that, it makes sense to open source the framework to share the burden with
other companies.

The real complaint seems to be the _misuse_ of client-side frameworks. But
this is a function of junior devs and poorly-trained devs misusing a
framework, not the framework’s fault. Such developers would make even slower
apps without a framework, believe me. Only it would be be a rat’s nest of
unorganized spaghetti code.

~~~
theyak
You have pretty much nailed it.

------
Animats
The page mentions the "re-imagining of Hacker News", which was actually
built.[1] Were they serious?

[1] [https://interface.fh-potsdam.de/future-retro/HN/](https://interface.fh-
potsdam.de/future-retro/HN/)

~~~
throwaway286
Do they have to be serious? To me, this is the playful sort of thing you would
see on the "old internet" that people miss.

------
baron816
I wish the author had included an example instead of just going after a straw
man.

There are lots of devs out there that don't know what they're doing or aren't
permitted time to optimize their apps. Frameworks are a tool that can be used
and misused.

------
rkagerer
_I fully believe a lot of developers and software enginers put their job
satisfaction above their users or customers._

I agree wholeheartedly the web on average is getting more bloated.

But as a counter point: My own job satisfaction derives from delivering an
amazing and snappy experience to end users. And I'm sure there are others like
me out there!

------
connectsnk
I have heard this rant too many times. Other comments in this thread are also
just adding to the rant or trying to justify SPAs.

Can someone please suggest some alternatives.

~~~
friedman23
Don't worry about the fud these people are spreading and use the tool you know
to get the job done. If that is ruby on rails using templates with plain html
and css do that, if it's react do that. None of this worrying about "bloat"
matters, just get it done.

The two most successful chat apps in the world today are slack and discord and
they use react and electron on the desktop.

~~~
scarface74
Slack is not “successful”. Slack is a for profit business bleeding money is
slow and still not seeing adoption by many major corporations.

How many Slack users are on the free plan?

~~~
friedman23
An app can be successful on many metrics, profitability is not the only one.
Slack is successful in that it has 10 million daus, 85000 paid users, and it
managed to have the company valued at 12.4 billion dollars.

Ignoring the valuation of the company I would consider any program with 10
million daus to be successful.

And funny enough 10 million people choose to use slack and 14 million choose
to use discord over irc every day despite the supposed "bloat" of the
software.

If you are a developer building an mvp and the thing you are worrying about is
"bloat" I will put money on you not being successful.

~~~
scarface74
There is no definition of success for a for profit company accept
profitability. Anyone can sell a bunch of dollars for 95 cents.

And as far valuation, Uber and Lyft both have multi billion dollar valuations
and are both losing billions a quarter.

~~~
friedman23
Regardless of your quibbling, if the creators of slack and discord decided to
not use modern web frameworks to build their software they wouldn't exist.

~~~
scarface74
You think Slack was ever undercapitalized to a point where they couldn’t hire
both Mac and Windows developers?

Companies have been producing both native Mac and Windows software for over 35
years.

------
thosakwe
I don't agree with this, really in any sense at all. Firstly, you could argue
that using battle-tested projects with thousands of hours behind them can
yield you better performance, as well as reducing training time because more
new employees will already have the necessary skills. It also tends to be
better for accessibility than roll-your-own.

Secondly, the article completely forgets to mention what really causes slow
down: loading sources from multiple third party domains, especially bulky ads,
tracking, and popover scripts.

------
dagaci
The reality is we (web and other developers) tend to waste end-users time way
before raw performance is perceieved as an issue. Take for instance medium.com
where you are expected accept complicated terms and conditions, and then give
away your facebook account or google account, after which you are prompted
with some kind of survey and then there a good chance you will be asked for
money ;) all of this is the norm for the web.

------
epicgiga
Comes down to incentives. Why would the agency or SME dev care about the end
user? Will they get rewarded if they do? Nope. Dev salarymen are concerned,
rightly, with their careers. This is why they do stuff like make a
brochureware website that should be dead-simple into some demented chimera of
5 different "best practice" frameworks, submerged in 10 feet of technical debt
to boot. They do so because they can put that stuff on their resume, which
will (for management and recruiting incompetency reasons) get them into a
better job next year or month. To hell with the devs who follow them, and to
hell with the client, customer, or end users in general - they ain't me. But
the solution is to modify incentives, not to indulge in the sperg-outs our
profession is infamous for, since those are only "I'm cleverer than you all"
rants, which are again, "me first".

------
rellekio
I understand the pressure on js frameworks and the like. Even Microsoft
attacked the same problem with Blazor. But the original goal of these
frameworks is and still is portable code. I might be the rare engineer whose
work flow is accelerated by these frameworks, but I also carry an approach to
creating well patterned interchangeable components. And by and far I believe
that is the real issue in the industry.

However if we are talking about speed. I do agree. But that is because to me
it is madness to have these frameworks sitting on the main thread. And should
be concurrently offloaded to a worker. Reactor's concurrent mode is also a
great stab at this problem. Howver I believe the point is missed.

Being the only bindings a framework should have on the main thread is it's
interactions with the dom. Everything else, including the virtual dom should
be on a different thread.

So while I understand the push back, I believe people are missing the point.
These frameworks have been implemented in the easiest fashion and have
matured. But now that we can rely on multiple cores and ht. There should be a
response.

Not to mention Web Apps vs Web Sites. We need to make that distinction,
especially in line with wasm now being matured.

Edit: As for serverside rendering. If your backend engineer can't figure out
how to cache this. I question the hire.

~~~
speakwithalisp
The reason frameworks usually don't run in a worker thread is because it is
difficult to efficiently cross the barrier between workers and the main
thread. Either you need a shared array buffer or the contents of your messages
have to be copied on write. Even web assembly has similar issues as it runs in
the same thread as any JavaScript you have.

I do agree about making the distinction between sites and apps though. A lot
of the contortion frameworks do is to avoid triggering layout excessively. You
can't even get the position of a DOM element without layout rerunning to
figure out where it should be. I suspect a lot of these quirks are legacy web
behaviors more applicable to sites than applications.

~~~
rellekio
I've done some experiments in regards to a message service. And though a lot
of this work isn't ready for production I have seen a lot of success. Long
story short SSR to rebind via webworker. Unfortunately it's just one of many
experiments that are way back in my todo list now.

------
systematical
I'm glad I'm not alone. Burn your JavaScript stickers.

------
mamon
Building online blog for the millionth time is boring and using a new
framework makes it less boring - that’s the main reason there is a new cool JS
framework every six months

------
deltron3030
What most JS frameworks like React and Vue got and get wrong is their
runtimes, meaning that a good designer/developer experience scales with the
amount of code that is shipped, an anti pattern because that it can be done
better as demonstrated by Svelte, which by being a "web compiler" basically
decouples the DX and production code. It's the real deal for webdev, going
back to React or Vue feels awkward after using Svelte.

------
rado
From the article's detractors I learned that while things are bad, they get
the job done and we get paid, no problem. Yet faster loading does increase
conversion and profit. Not to mention users will love a product that feels
good. A good work organization is more beneficial than finding your way around
someone else's organization (the mega frameworks). Can any manager who also
loves quality chime in? Thanks.

------
lambdasquirrel
The counterpoint is, who are we to say that "performance" matters. Certainly
for things like search, yes. But much of the time, features matter more.
Frameworks happened because they allowed engineers to iterate more quickly,
which allowed PMs to find the set of features that work for users. We are,
after all, still using JIRA.

------
gridlockd
A blog post talking about performance but showing no numbers to prove the
point? Questionable.

HTML, CSS and DOM manipulation all by itself is already a performance
trainwreck. CSS layouting is ridiculously expensive.

The actual framework overhead is usually negligible, especially when
considering that writing "optimal" vanilla code is not something that people
actually do, or when they do it is a security risk (setting innerHTML without
sanitation).

The point about 2-3MB bundle sizes isn't valid either, no framework that is
any good has more than a few dozen of kilobytes extra payload.

------
luord
Rule 0 should always be the one from Tron: Fight for the users.

In this case, "if the user isn't gonna need it, don't bother."

------
exabrial
Speed is the number one feature. SPOs are the antithesis of fast.

[https://twitter.com/gravislizard/status/927593460642615296](https://twitter.com/gravislizard/status/927593460642615296)

~~~
BoiledCabbage
Actually, features are the #1 feature, and the slow performance of the web
proves it.

------
testtest143
test

------
redis_mlc
I wanted to call out Patreon for one of the slowest web applications today.
Guys: click on developer tools and watch the paint dry.

------
seventhtiger
As a developer I'm much less comfortable working with JS frameworks. It seems
like each one tries to hijack the JS experience and create its own.

Does anyone have experience writing SPA/PWA without frameworks? I'm interested
in the idea of minimal JS even at the cost of productivity.

------
friedman23
This article contradicts itself and it doesn't actually describe how
frameworks destroy web performance.

I can easily make websites that will rank 100 on google pagespeed insights
using React.

The bloat and slowness of modern websites is not from javascript and any
frameworks.

------
ecmascript
While I completely agree with most of this article. I think some of it is
untrue. A lot of the new functionality is needed for a increasing amount of
apps.

For example, I work on an app which wouldn't be possible on the web 5-10 years
ago. It's a single page app because it needs to be. It uses a lot of
javascript making many requests because we have to and the customers requires
it. We could probably make it a lot faster, the issue is that the amount of
functionality that we are trying to include in a short amount of time leaves
us no other choice than to include yet another library etc.

I know this case maybe isn't the kind of app the article is targeting. But I
think even "simple" apps today often include some part of complexity that
would be hard(er) to do in a "old style" multi page app.

That being said, I use a lot of old style apps. I use the old reddit instead
of the horrible new one. I use HN, I use fastmail so I do think speed is very
important.

~~~
xg15
> _A lot of the new functionality is needed for a increasing amount of apps._

Could you make a few examples?

> _It uses a lot of javascript making many requests because we have to and the
> customers requires it._

Why couldn't the requests be done by the back-end?

> _But I think even "simple" apps today often include some part of complexity
> that would be hard(er) to do in a "old style" multi page app._

Absolutely, but isn't that exactly the point of the article? Working with a
framework can make development massively easier - however, the benefits of
this only go to developers, while users have to bear the costs.

~~~
ecmascript
> Could you make a few examples?

Sure, not in any particular order (and there's a lot more)

1\. Users can use drag and drop functionality on areas, making updates to the
backend as they are moving stuff around. To have the webpage reload would not
be an acceptable experience.

2\. File management. Users can upload files and create folders, refreshing the
page after every update wouldn't be nice.

3\. Users can retrieve data on many objects. Open specific objects and see
it's data in popups. Edit the data, add comments, upload images etc. Wouldn't
work very well with a refresh.

> Why couldn't the requests be done by the back-end?

When the backend can do the requests, it does. I meant doing requests to our
backend and to static resources.

> Absolutely, but isn't that exactly the point of the article? Working with a
> framework can make development massively easier - however, the benefits of
> this only go to developers, while users have to bear the costs.

Not really. I am saying that many new apps aren't simple crud apps anymore.

~~~
plorkyeran
What part of that do you think wasn't possible on the web 5-10 years ago? The
term "ajax" is 15 years old now.

~~~
true_religion
It’s not that it wasn’t possible, but it was really fiddly keeping the HTML up
to date with all state changes, and having the rendered template match up with
what the JavaScript wanted to do.

I ended up having to cut a lot of features to make projects happen on time,
and adding a new complex feature to an existing site coded with unobstrusive
JavaScript was always felt like a full rewrite.

Doing it with React though is like being back to working with desktop GUIs.
Anything you want we can do.

In the older days, anything that had to be a complex webapp would be easier
done as a java applet, or a flash app.

------
_bxg1
This is all over the place and doesn't really present a coherent argument.

The author complains about developers who "want to show off" and then derides
the use of frameworks. But showing off would mean _not_ using off-the-shelf
solutions, and instead trying to hand-craft everything.

The author complains about how frameworks bloat the page, but react + react-
dom, as of version 16 (the most recent measurement I could quickly Google),
weighed in at 109 kb (34.8 kb gzipped). Sure, client-side rendering means you
wait for the JS to bootstrap before you get to see content, but React also has
good support for doing initial renders server-side.

It feels like the author just spilled out his or her assumptions and
prejudices without examining or researching them at all.

~~~
maxymajzr
The author is right. It just sucks to read what's true. He's not entirely
right but he's on the right track.

You'll find a lot of tiny companies with dev. blogs where they explain in-
depth the scaling strategy of their unknown, sporadically-used product.

Yes, react and vue are a few hundred kb gzipped. But are we seriously going to
pretend that projects built with react are in a few hundred kb range? You
can't even predict how big a project will be. It's not react's or vue's fault,
it's simply how it is - add assets, add css, add additional libraries for
<insert reason here> and it's not unrealistic to get 2-3 MB that you need to
download.

A lot of people are designing their products to show off to their peers or for
google (SEO). Users get left out. And we (users) are starting to feel it. Heed
the warning or turn the blind eye.

~~~
true_religion
In the good old days, there were plenty of terrible user experiences built
with traditional technology. All of those apps failed to make a mark in
people’s memories and have been forgotten.

I do remember stuff built in Frontpage breaking terribly if you resized your
browser. I remember Joomla outputting reams of html that the browser would
choke on the nodes. I remember doing chat apps via iframes and long polling.
It was all there.

Better technology has only lead to better outcomes on both the low and the
high end, and it’s a lot easier to debug and fix the low quality outcomes.

