
The case for vanilla front-end development - rlonn
https://pushdata.io/blog/1
======
smacktoward
_> When on a 1Mbit/s WiFi connection in Greece, my vanilla app loaded in 4
seconds and started rendering after ~2 seconds, while the React/Redux app took
50 seconds to first render!_

This is the thing that baffles me about the SPA/framework trend, regardless of
connection speed. The whole pitch for React/Vue/etc. is that they're supposed
to make for more responsive interfaces. And yet, whenever I actually _use_ an
app written in React/Vue/etc., I find myself marveling at how _slow_ it feels.
Even on a desktop PC with a fast connection, I spend so much time staring at
progress bars and loading spinners as all the various bits and bobs of the
interface get pulled down and rendered. I don't know whether pages that are
rendered server-side are empirically faster, but they sure _feel_ faster,
because after a brief (usually < 1s) wait the whole page just, you know,
_appears_ , fully rendered and ready to go.

As another developer who's old enough to remember the CENTER tag, I'm open to
the idea that this is just incipient old-fogeydom on my part. But whenever I
hear people start talking about how much more responsive SPAs are, it sounds a
lot like the old gag: "who are you going to believe, me or your lying eyes?"

~~~
bouncing
> Even on a desktop PC with a fast connection, I spend so much time staring at
> progress bars and loading spinners as all the various bits and bobs of the
> interface get pulled down and rendered.

A lot of that is likely because of the way most REST APIs are laid out.

Suppose you're looking at a page that displays an invoice for an accounting
system. With a traditional non-SPA app, you'd do a bunch of SQL queries and
build a page from an HTML template.

With a REST API, you're doing one HTTP call per entity, at least, and then
subsequent HTTP calls for aggregate entities.

When I've made SPAs before, I've often eschewed REST and just made a single
Ajax call for "everything I need to display X to the user," not just out of
efficiency, but also out of laziness -- it's easy to build. As long as you
internally use your API only and don't publish keys for third parties, it's
easy to maintain too.

There are some solutions to address the whole problem on a grander scale
(GraphQL comes to mind), but overall, that's the cause of slow SPAs in my
experience.

~~~
Svenskunganka
If that's the case, shouldn't HTTP/2 have solved that issue? HTTP/2 is
multiplexed, so if you make something like 10 HTTP calls, only a single TCP
connection would be established. Additionally, according to section 9.1 of the
HTTP/2 spec[0], connections are persistent so unless the server closed the
connection, an already established connection will be available from when you
first loaded the page.

[0]:
[https://httpwg.org/specs/rfc7540.html#rfc.section.9.1](https://httpwg.org/specs/rfc7540.html#rfc.section.9.1)

~~~
bouncing
Well, no.

For one, the most major http client library (Axios) doesn't have support for
that kind of pipelining.

But also, you don't necessarily know what to pipeline until you get the first
request through. Most web apps will make a REST request, look at the contents
of the response, then make another REST request. Maybe you could keep the
socket open through that, or you could even use websockets to bypass HTTP
altogether and use jsonrpc, but still, you don't know what you need to fetch
in the second round until you finish the first one, so either way you're
looking at a waterfall of requests, one after another. Pipelining them would
scarcely help.

What would help is having one API request that basically says, "here's who I
am and here's the page the user wants. Give me everything for it." Then you're
moving the controller back to the server, and leaving only the view on the
client.

~~~
Svenskunganka
Axios doesn't control what protocol is used, the browser and the server will
negotitate a suitable protocol and version, which the browser will
transparently use for XHR (which Axios use under the hood). Don't confuse
multiplexing with pipelining which was introduced in HTTP/1.1. Multiplexing is
a much better solution than pipelining to counter head-of-line blocking, since
large or slow responses will delay subsequent requests while multiplexing
allows parallel response/request communication.

I do agree that waterfall-style requests are more prominent with a REST
structure, and that something like GraphQL could solve that - but GraphQL
seems largely incompatible with how many develop web apps today; smaller
components that request their own data. I'm also unsure how compatible a
dynamic query language like GraphQL is with denormalized databases like
Cassandra or ScyllaDB where you can't model your data before you've
established what queries your site/app will perform. I've yet to see a
codebase where the REST waterfall problem is a huge problem though.

Note that I too dislike how slow websites are these days, and much prefer to
both build and use an entirely server-side rendered one. None of the SPAs that
I know of has been a success in terms of performance; Facebook, Google Mail,
Reddit's redesign, Youtube, Twitch - most of them are dreadfully slow and
sluggish.

------
Zelphyr
"...while a framework will let you create standard solutions to standard
problems very quickly, you always then have to add that little special sauce
that makes your app unique, and that is where the frameworks can slow you down
instead of speeding you up. Vanilla coding, on the other hand, is just as fast
whether you're doing something "normal" or something unique to your particular
app."

I've been saying this for years and always get heavy push-back by the
framework proponents. I've also encouraged them to look at history. Ten years
ago, it was ALL about Backbone. Then Angular came around and it was ALL about
Angular. Then React came around and it's currently ALL about that. But, wait!
Now Vue is starting to gain some traction. In 3-5 years it'll be ALL about
Vue.

My point is this: if the frameworks are so great and all-encompassing (I've
literally heard, "you can build anything with [FRAMEWORK]. You don't need
anything else!"), why doesn't one of them stand out so solidly that nobody
would think to create another one? Why do we, like toddlers grown tall, keep
rushing to the next latest and greatest shiny object that catches our eyes?

~~~
jpmoyn
I agree with your point, but having worked extensively with React, it really
does make development easier for me. While it feels like there is always a new
shiny front-end framework out there, the ones that stick out like Angular,
React, Vue, etc. all have real value that developers like! So I don't really
see it as a bad thing.

~~~
Zelphyr
I don't deny that they make things easier. But there's a cost to that,
sometimes a significant cost. In my experience (and confirmed by others I know
--including the author of the post), frameworks get you to 80% of where you
need to go in a project _really_ fast. The next 10% takes a little effort but
it's not impossible. But that last 10% is like pulling teeth from a lion.
That's because inevitably the project has requirements that the framework
designers didn't and couldn't think of.

I submit that that last 10% is the reason why OP got more done faster with
Vanilla than he could with React.

~~~
ng12
I'm not sure what you imagine that 10% to be but this has not been my
experience at all.

------
jim-jim-jim
>When on a 1Mbit/s WiFi connection in Greece, my vanilla app loaded in 4
seconds and started rendering after ~2 seconds, while the React/Redux app took
50 seconds to first render!

This never ceases to puzzle me. I thought yuppie framework jockeys love to
travel. Don't they ever find themselves at some remote locale, try to check in
on things, and realize that their site runs like pure ass outside of costal
North America? Do they just not care?

Simplicity really can be a class issue. Lots of developers seem to write code
with their own demographic in mind, rather than the real people who have to
put up with their bullshit.

~~~
ng12
I haven't written a line of code that ran outside of a corporate network in
years. Comments like this show how ignorant HN is about what "framework
jockeys" actually do.

~~~
joshstrange
Amen, my code mainly runs outside my company but this 1000000x over. SOOO many
people on HN seem to think the entire world works exactly like they do on the
same kinds of things. It seems outside of most people's understanding that,
maybe, just maybe, the business conditions where someone else works are....
different _GASP_.

It's not the same thing but it's a pet peeve for me when people make comments
like "How could a developer skip X or not do Y?!?" Well not all of use can
pick 100% what we work on and are sometimes forced to cut corners. We aren't
happy about it but we are more happy with taking home a paycheck that being
right 100% of the time. My go-to is "Is this this hill I want to die on?" when
this stuff comes up.

------
gambler
It's downright hilarious that now, when IE is dead at last and browsers
_finally_ have APIs and CSS support to do things cleanly, developers are
completely abandoning "vanilla" JS development in favor of frameworks and per-
processors. Feels like a job security thing.

~~~
pier25
Well, the fact that the JS standard library is crap doesn't help much.

~~~
austincheney
How do you mean?

~~~
pier25
There are a number of problems that vanilla/standard library doesn't solve, so
developers need to rely on libraries or spend an enormous amount of time
developing those from scratch.

Date and time manipulation, reactive programming, data binding, etc. Those are
bread and butter stuff that the standard library should solve but doesn't.

------
arcticwombat
This was a very interesting read, and I agree with Ragnars conclusions.

I'm amazed sometimes of how complicated and heavy some people, especially new
developers, make things.

While I usually pull in JQuery for small applications, sometimes all you need
is.. well, nothing, just the core language(s).

~~~
rlonn
Thanks. Sometimes I feel very old and lonely when I complain about overuse of
components, in any situation. But for me, it is the way so many people today
just seem to use npm to pull in millions of dependencies, that themselves pull
in millions of dependencies, ending up with ridiculous amount of data having
to be downloaded and ridiculous amounts of code being executed, for what may
be just to compile a "hello world" app. I'm actually very frugal on the back-
end side also: the Go API server for pushdata only uses a handful external
packages (like Stripe's Go SDK, a GetOpt package, Gorilla/mux - a URL router,
A PostgreSQL connector and an AWS package for talking to AWS SES)

~~~
arcticwombat
I think a lot of it stems from bootcamps and whatnot, focusing on letting
people check off a number of boxes by the end of the course/system/whatever.

Node - Check

React - Check

Angular - Check

NPM - Check

"See how much you've learned in just two weeks! You'll easily get a job with
that!"

And so on.

Rather than learning how some of this stuff actually works, many new
developers are falsely led down a path where they think they can't create cool
useful stuff without relying on a massive number of libraries and build
processes.

See the whole leftpad disaster for example (Yes, I know, they fixed it, but it
happened to begin with).

No seasoned or even moderately experienced developer should be using a package
for something as simple as padding something. If I saw leftpad during a code
review I'd send it back to the dev to fix.

Right now I'm creating a website using pretty basic tools, no frontend builds,
and a backend using FPC, Postgresql for DB and done, no mass of libraries, no
cascade of dependencies.. Just good performance, simple builds (Single FPC
compile to executable), and easy for anyone to wrap their head around the
entire process.

~~~
collyw
Just look at your average job ad. Its basically a checklist of tech exactly
like this.

~~~
arcticwombat
Yup, and that's a problem.

It makes perfect sense for the bootcamps to exist to fill that niche, it's
just horribly unfortunate for both the companies hiring people with less skill
than they think, and the new developers being led down bad paths.

Another part of the problem is that job ads only show part of the image.

If you can show that you're a good developer with a solid track record, those
HR checklists largely become null and void.

Just look at how many job ads include "Must have Bachelors in CS", which most
of us know is complete bull.

------
emerongi
Of course there isn't much benefit to using React/Angular/Whatever (and other
tools in those ecosystems) if your site is mostly a static thing and maybe
only needs some interactive content here and there.

If you have a stateful application (or even just a single stateful part on a
static site), React will simplify life a lot.

Figure out your requirements and develop based on those. That's pretty much
it. There can also be external requirements (e.g. we want to be able to hire
easily, so opting for a well-known framework is better) and those should be
taken into account as well.

------
onion2k
_When on a 1Mbit /s WiFi connection in Greece, my vanilla app loaded in 4
seconds and started rendering after ~2 seconds, while the React/Redux app took
50 seconds to first render!_

react + react-dom is 33.4Kb gzipped. That's not _completely_ trivial
obviously, and if your app isn't doing much DOM work it's probably
unnecessary, but nor is it the reason why any app would take 50s to download
on a 1Mbit/s connection. The problem was clearly something else.

I have nothing against people who choose to hate on frameworks, but if your
maths is that far off it really undermines your argument.

~~~
tenaciousDaniel
Agreed.

I didn't use a framework until 2016. I use React now and love it, and yet I
still find myself using all of my knowledge of the DOM when writing React, to
ensure that it behaves smoothly.

I personally think there are simply a higher number of devs who can code fine
in React/Vue/Angular/whatever but don't fully understand the intricacies of
the DOM. So the result is that these SPAs often feel slower. But it isn't the
fault of the frameworks necessarily.

~~~
tflinton
But the reason to use a framework is to have a fast path for devs to write
SPA's that feel fast without having to know the intricacies of the DOM. I'm
honestly not trying to be argumentative, I really though that was the reason
for using react/vue.

~~~
tenaciousDaniel
I think that's a good argument. Although, React is much lighter on the DOM
than Angular 1 was, so you could say there is improvement to some degree.

But still, that's a completely fair point.

------
phtrivier
> It's just that a framework can help you adopt good habits if you're lazy,
> ignorant or just have a dev team that is >1 person :)

I had to read that three times to convince myself that the author was not
_stricly_ equating "having a dev team of more than 1" with "being lazy and
ignorant".

Anyway. If I'm never going to see and maintain your code, sure, go ahead and
write it the way you want.

------
hnruss
“Who knows if React will be used 5 years from now?”

It will be. I work on an application that still uses JS libraries from 5-10
years ago, simply because refactoring to use a new library is usually
unnecessary (or even counterproductive). There will always be a need to keep
applications like that running.

------
pier25
I've been writing SPAs for a number of years, and while I've become competent
at it, I now use Jekyll for most of my projects.

There are some exception where a SPA is certainly justified, but for the most
part a static site with some dynamic parts in JS is so much easier to produce
and maintain. Also a lot faster to load.

It's easy to still use Webpack/Babel/etc with Jekyll. Here is a starter kit I
made some time ago for some coworkers. It's for Vue but the same idea can be
used for React, etc.

[https://github.com/PierBover/jekyll-vue-webpack-starter-
kit](https://github.com/PierBover/jekyll-vue-webpack-starter-kit)

------
projectileboy
I feel like I've been ranting about this for years. Way more the 50% of the
web is simply content - text and images. Pages that serve up content should be
HTML and CSS, period. Why do I sit around waiting for pages to render on
magazine websites? Because the developers built what should have been a very
simple website as a single-page app with a fat framework and 9000 supporting
libraries. Development tell the business and tell themselves that it's about
creating a great user experience, but it's really just fashion, and what
sounds like fun to build.

------
cheschire
I've been quite happy using plain typescript lately, and focusing on
progressive enhancement vs graceful degradation. I just don't see many
framework-based sites being 508 compliant these days.

------
jyriand
It’s kind of ironic that I can’t read this article on my mobile screen. Have
to scroll left and right.

~~~
rlonn
Well, I can fill you in on the fact that a fair bit of the contents described
how useless my front-end coding skills are! Also, the whole blog section, with
comments etc, was done in the past couple of days so I haven't tried to fix
responsiveness there....will get on it!

------
rinchik
> my vanilla app loaded in 4 seconds and started rendering after ~2 seconds,
> while the React/Redux app took 50 seconds to first render

I'm all hands up for vanilla JS development, but I really don't think this
drastic load/render time difference is caused by React but rather by the poor
coding.

React is tiny, and you can see performance degradation like that only if you
don't use it right, don't understand the life-cycle or over-engineer

~~~
bouncing
If it's consistently poor coding on behalf of react apps, perhaps the
documentation or culture around react isn't explaining the pitfalls or
encouraging good design.

~~~
rinchik
It’s not consistent at all, that’s my point. Being small and fast library is a
React’s major selling point

------
rlonn
Probably going to be torn to pieces for this (if someone sees it) but at least
it will be entertaining :)

~~~
joshstrange
To each his own. You are developing this by yourself (AFAICT) and are the only
one working on it. Don't let people tell you the right/wrong way to do it, do
what works FOR YOU.

Me? I like frameworks, I use them daily at work, I'm familiar with them, and
I'm comfortable with the tradeoffs. I think in a multiple-developer
environment you need to standardize things and a framework is ONE approach to
that. I think it's the best approach in a shared environment but I'm not going
to be so cocky as to tell you what the best approach is for you.

I mean reading about your experience with modals made me cringe a little (at
how long it took) but hey, you didn't have to lean Angular/React/etc so you
probably came out ahead so who am I to judge? Focus on what makes your
business successful, for you that is clearly NOT the web UI (not meant as a
dig) so don't waste your time using the New Hotness (tm). Instead work on
making your API servers rock solid and adding features.

A User is NEVER going to come to you and say "I'd use your product but you
used vanilla JS so I went somewhere else" they will say "your site doesn't
work in X browser", "Your site is ugly/inconsistent" (I don't think this about
your site), "Your API is slow", "I need to be able to filter my time series on
X but you only allow for Y". NONE of these problems are fixed with a framework
alone and fixing them with a framework brings it's own set of issues.

You do what works for you and clearly this seems to work. Keep it up!

PS: I'll have to keep Pushdata in mind for future side projects, looks pretty
cool, this is the first I've heard of it.

~~~
rlonn
Trying hard to find something to disagree with in your comment, but no luck :)
Seriously, I think I did at least mention in the blog post that the vanilla
approach is something I'd mainly advocate for small projects, with few
members. The kind of situation where I am myself, at the moment.

The thing is, I see so many reach for the big guns and over-engineer their
new, tiny app that they're developing themselves, with a friend or perhaps a
small team. And I see overuse of components in general - the tendency to just
pull in a new dependency via npm for something completely ridiculuous. This
post was not about big, in-house enterprise systems development.

And in fact, thinking about my experience from that financial company
mentioned earlier, I would greatly have preferred a standardized, external
framework before the in-house developed macro/library mess that worked but was
pretty much undocumented and whose inner workings were known to a very small
number of people.

~~~
arvinsim
> The thing is, I see so many reach for the big guns and over-engineer their
> new, tiny app that they're developing themselves, with a friend or perhaps a
> small team. And I see overuse of components in general - the tendency to
> just pull in a new dependency via npm for something completely ridiculuous.
> This post was not about big, in-house enterprise systems development.

Because it is much more reassuring having a community back you up in case you
get into the edge cases. DIY? Good luck, you are on your own. Not to mention
you have to scaffold all the things that are already taken of by the
framework.

It's also a matter of maintainability. If you can successfully predict that
the project will always be small, then fast, bespoke code might be great. But
it's usually not the case. Prototypes almost always turn permanent.

~~~
chosenbreed37
> Because it is much more reassuring having a community back you up in case
> you get into the edge cases. DIY? Good luck, you are on your own. Not to
> mention you have to scaffold all the things that are already taken of by the
> framework.

And once you're reasonably familiar with a framework it would make sense to
use it even for a prototype. Unless you're actually interested in trying out
"VanillaJS" or an alternative framework you would just use the tools you
already know and get on with the problem you're trying to solve :-)

------
franky47
I saw a talk at SnowCamp Grenoble last week about the use of vanilla JS on
both front-end and backend, only using what's available in the language /
browser APIs / Node.js core libraries.

The author published his project (a 2048 game clone) here:
[https://github.com/Swiip/vanilla-modern-js](https://github.com/Swiip/vanilla-
modern-js)

------
pcstl
Vanilla is fine for small projects (and I tend to prefer it for static
websites), but if you try to develop a large web app using vanilla JS you'll
just end up making your own half-baked framework.

A kind of variation on Greenspun's Tenth Rule might be in order:

"Any sufficiently complicated web application contains an ad-hoc, informally
specified, slow, bug-ridden version of half of React".

------
austincheney
I struggle to find somebody who can justify their favorite framework without
using a cliche. Once I hear the cliche I have stopped listening to anything
that comes after, because its all bullshit. If people just say they want
easier because they are self-conscience about writing this code (or really
don't know how) I would really value the honesty of their answer.

------
adamredwoods
I wonder how easy this code will be to maintain? If the person leaves and a
new developer is needed to come in and add new features?

~~~
falsedan
I feel like this is an issue to address when you hire your first employee/hand
off the project to another team, not when you're trying to get started.

------
131012
Hey wait. You consider AJAX plain javascript?

