
Do you really want a single-page application framework? - Immortalin
https://mmikowski.github.io/no-frameworks/
======
ricardobeat
I apologize in advance, but I, an ES5 / lean modules / no-build / vanilla
javascript guy, find this article to be terrible advice. The arguments against
frameworks are backed by generalizations like

    
    
        frameworks tend to intermingle display and business logic
        testing is tedious and difficult
        cycle time bs
        I once used a framework... and had to wait months
    

Then goes on to say _When we use a sound architecture and libraries instead_
\- well, guess what? Frameworks are just architecture + libraries! In fact,
your plan to release an "npm module" with architecture, diagrams and library
dependencies is _a framework_ , a _mishmash of solutions of varying quality_!

Of course they have varying levels of coupling - it's probably hard to replace
parts of Angular, but Mercury for example is just a bundle of easily swappable
libraries, like many others. React itself is not a framework.

It also completely overlooks the architectural differences that have come to
exist in modern SPAs. What he proposes in the linked slides is just MV*, which
everyone already has done for a decade. Flux-style state management + reactive
rendering is a huge improvement over that and you won't get that just by using
jQuery.

The author actually maintains a virtual-css library (PowerCSS) which benefits
from the same principles, yet fails to see the value of doing the same with
the DOM. This library + jQuery is already as large as many frameworks.

~~~
mattmanser
You're cherry picking.

One of his key points is that frameworks _aren 't_ "just architecture +
libraries". Read his 2nd point, "Frameworks and the inversion of control".

Also, MV* hasn't been done in javascript for a decade. jQuery itself only came
out a decade ago, MV* frameworks started appearing 5 or 6 years ago.

10 years ago most browsers in the wild were still IE6 which could barely
handle 100 element for loops, let alone an mvc framework.

~~~
zdragnar
There are certainly JS MV* frameworks older than 5 years... Dojo and puremvc
come to mind.

------
throwanem
I've done exactly what this author advises - that is, build a complex, real-
world single-page app using nothing but jQuery and some plugins.

I didn't do this because I wanted to make some kind of point about
architecture or overengineering. I did it because, at that time, front-end
frameworks weren't a thing, and the phrase "single-page application" hadn't
yet been invented. I didn't even know that was what I was building, because it
hadn't been formalized as a concept. I just knew I had a problem to solve, a
deadline to meet, and a contract to save.

Which I did. And it was _terrible_.

There's a point to be made about overengineering. If your app takes five
seconds to rebuild after a single-line change, maybe there's a problem. But
treating that as cause to throw the baby out with the bathwater amazes me in
its foolishness. It makes exactly as much sense as saying that, because
airplanes very occasionally fall out of the sky, they're not worth having at
all.

I've been seeing a lot of this weird nostalgia lately, this technological-
romanticist attitude that there was a better time before web frameworks
because everything was so much simpler then. Well, I was there, and it was
not. The problems were just as complex; the only real difference was that the
tooling sucked. Now it doesn't. We no longer have to build complex
applications from jQuery and bearskins. Speaking as one who has done so, that
is not something to regret, and neither is a situation in which the major
complaint we now have about our tools is that they do _too much_. As far as
problems go, that's a really nice one to have!

~~~
dismantlethesun
> If your app takes five seconds to rebuild after a single-line change, maybe
> there's a problem.

I don't see it as a problem with the app, I see it as a problem with the whole
Babel -> Browser compile chain using lots of tiny files and imports.

My Python app which is 10x the size of the javascript one has a startup of 2
seconds. The JS app, is less than 5k lines and has a start up of 10 seconds to
compile via Webpack serverside, or 18 seconds if we're doing it inline via
JSPM, and compiling client-side.

I can't wait till browsers have native imports, and support all of ES2016. If
even one does so, I'll switch to that for development and only compile for
production.

~~~
nilliams
> and has a start up of 10 seconds to compile via Webpack serverside, or 18
> seconds if we're doing it inline via JSPM, and compiling client-sid

That's crazy, you should check you're not running more stuff through babel
than necessary. (Edit: also why are you compiling via Webpack serverside at
all, that sounds like a bad idea)?

> I can't wait till browsers have native imports, and support all of ES2016
> ...

Same except once we have native imports, I'd happily stop with what Chrome has
now/then, give up the rest of ES2016 for not having to have a build step for
local dev.

~~~
dismantlethesun
> why are you compiling via Webpack serverside at all, that sounds like a bad
> idea?

Because it turned out to be faster to handle the compile serverside, then use
hot-reloading.

Why are we using Webpack? Well because we use ES2016 for everything. I tried
cutting down on the # of Babel transforms used, but some Babel plugins rely on
the transform output of others (e.g. decorators/static members relies on
ES2015 class transform), and so I ended up having to use 80% of all the
'standard' plugins anyways, plus everything up to stage 0.

The alternative was to go down to 3-4 second compile times, by eschewing
everything that isn't implemented natively in Chrome. I rejected it as
workable because our codebase was already pretty heavily leveraging
decorators, but it's something to think about for other projects.

If you only use Chrome implemented features of ES2015, then all you need to
make a build is a linker like Webpack/JSPM.

> That's crazy, you should check you're not running more stuff through babel
> than necessary.

Ah, I think you're saying this because of my 5k line of code figure for the JS
project. I'm not counting dependencies... and some of those dependencies are
really heavy, made worse because they load incompatible versions of things
(e.g. Fbjs 0.13 vs fbjs 0.15).

The same is true for the Python project though, but Python is simply faster at
linking pre-compiled files than Babel is. JSPM-client side is worse because it
has to load each file individually in the browser and _then_ check to compile
it. Loading Babel itself in the browser via JSPM takes like 2 seconds.

~~~
drewgross
> I'm not counting dependencies... and some of those dependencies are really
> heavy, made worse because they load incompatible versions of things (e.g.
> Fbjs 0.13 vs fbjs 0.15).

I think you misunderstood. You aren't supposed to run your dependencies
through Babel.

------
cdmckay
I find that when you start rolling your own framework, you just end up making
crappier versions of what's in Angular, Ember, etc.

What's worse, a custom framework won't be known by any new developers, so
you'll have to spend more resources onboarding them than, say, if you just had
to show them how you're using Angular in your company (i.e. they'll already
understand things like directives, components, etc.)

Finally, you lose the advantages of having an ecosystem of plugins, support,
etc.

It just doesn't make any sense to me to roll your own. Any initial speed you
gain you end up paying for later on. To me, using something like Angular means
I can harness the experience and expertise of dozens of superstar coders at
Google whose only job is to think about the best way to write SPA frameworks.

Why would I not take advantage of that?

~~~
jasonkester
_I find that when you start rolling your own framework, you just end up making
crappier versions of what 's in Angular, Ember, etc._

And that's a good thing.

The distinction is that you're making a crappy _general purpose_ framework,
but you're making a really good _problem specific_ framework that exactly fits
the thing you're building.

The reason those frameworks you list are so "bloated" is that their developers
have spent so much time polishing them up and general-purpose-izing them so
that Everybody can use them for Everything.

Your thing is only for You to do Your Thing, so it can be much lighter and to
the point.

~~~
Cthulhu_
> but you're making a really good problem specific framework that exactly fits
> the thing you're building.

Except when you don't. A lot of people, when they realize they're building a
framework, start over-engineering (YAGNI). Another issue is that they, for
example, build a template renderer but miss a lot of edge cases, opening their
application up for script injection and other such nasty things.

Ten or so years ago, PHP had the same disease - people thinking they're hot
shit, building their own frameworks, writing wrong tutorials on how to e.g.
connect to a database because they thought they knew how that worked. This
resulted in a huge amount of SQL injection issues, millions if not billions of
hacked accounts, and billions in damages.

TL;DR don't write your own framework, please.

~~~
dreistdreist
PHP did not have a useful package manager back then. It has now.

Custom solution built on top of stable components > general purpose framework

------
cm2187
To me the question is more "do you really need a SPA" rather than "do you
really need a framework for your SPA".

Way to many websites are using unecessary SPA which create more oportunities
for things breaking, being incompatible, or taking longer to load than plain
old server side html (plus with a flicker effect).

If you are really running an html application like an online trading platform
then yes. But if you are a banking website and just want to display an account
balance or the last 30 transactions, I fail to see why using a SPA makes
sense. And I am not even talking about podcast websites or blogs where using
an SPA is just absurd.

But as I noticed where I work, developpers are too often choosing technologies
not based on the problem they are trying to solve, but based on the sort of
keyword they want to see on their CVs. So I end up having to use hadoop for
accessing 10MB csv files and dealing with similar moronic design decisions.

~~~
tboyd47
Bingo.

SPA is what I like to call "non-existent technology," meaning a buzzword that
is neither a real technology people can download and use, nor a specification
people can refer to. Other examples: "Cloud computing," "NoSQL," "SOA." It
only really exists on people's resumes and on blog posts. Non-technical people
have no way of knowing that it is not real.

There are good reasons why web applications have backends. There are also good
reasons why you would use that backend to serve pre-rendered HTML. There are
also good reasons why you would use page transitions to take the user from one
screen to another. These concepts are lost on many developers nowadays. I'm
not saying you _never_ want an SPA, but it's really freaking hard to do
because you're going against the grain on a platform with 20 years of progress
in another direction.

What happens when non-existent technology makes up the greater part of the
beginner's stack? When instead of the LAMP stack or Ruby on Rails, people
graduate coding bootcamps with a specialty in building functional SPAs using
NoSQL and cloud-based BFFs?

~~~
paulddraper
For cloud computing not being real, there is a lot of money being spent/made
on it.

"Cloud computing," "NoSQL," "SOA" are concepts/ideas. They aren't
"technologies" per say. There are, however, technologies that implement these
ideas (AWS, CouchDB, Ostrich).

~~~
tboyd47
I am only making a point that concepts/ideas are not the same as technologies,
and shouldn't be treated as if they are. It's gotten so out of hand now that I
half-expect people to start attaching version numbers to them, like "NoSQL
2.0". It's as if the phenomenon of a "technology buzzword" has been totally
divorced from the technical product the buzzword is supposed to refer to,
which is frustrating.

If I have a resume full of concepts/ideas and no actual technologies, then the
fact is that I can't be trusted to extend or repair any real system. The
beauty of open source is that I do have skills I can take from company to
company. I can use my Rails experience at one company to hit the ground
running at another. If we start replacing actual technologies with mere
concepts in our trade, then we still have a shared language but no shared
skills. So the end result is eventually the same as if open source never
happened and every programming environment was proprietary. End rant.

~~~
paulddraper
Sure, put down details on your resume.

But calling SPA a "non-existent technology" is like calling SUV a "non-
existent sandwich".

No one claims SPA is a "technology" any more than they claim REST is a
technology. It's a paradigm.

------
DigitalSea
I think many of the arguments in this article might have been applicable back
in 2012 when single page application frameworks were the new and popular
thing. We can all agree that Angular 1 served us well at the time, but
introduced added complexity and issues of its own (digest cycle being the main
one). Some of the frameworks/libraries out there right now are stellar.

I have been using Aurelia for 1.5 years now and honestly, I could never go
back to jQuery and other libraries again. I've worked with React, Vue, Angular
2 and dipped my feet into Ember. Of all of those, I would say Angular 2 was by
far the most non developer friendly framework of them all. Ember is the most
opinionated and some developers like that, but for me, I have settled on
Aurelia and I do not plan on switching anytime soon.

Having said all of that, sometimes you don't need a SPA framework, sometimes
jQuery or even Lodash will serve your needs. When it comes to needing support
for routing, data-binding between view and some kind of view-model, I'll pick
a SPA over jQuery and having to hack together something that is far less
efficient than existing SPA solutions any day of the week.

Assess your needs and choose whatever works for you.

~~~
gumoro
Did you mean "non-developer friendly" or "non developer-friendly"?

~~~
Noseshine
I think we can use context to easily infer what was meant: Looking at Angular,
I don't see how a non-developer could even get started :-)

I mean, what would a non-developer do when given this (and that's a very
_simple_ example)? [https://github.com/AngularShowcase/angular2-sample-
app](https://github.com/AngularShowcase/angular2-sample-app)

I'm not making a quality statement, it's just that it is a complex framework
for complex programming projects.

~~~
indolering
There are legitimate disagreements to be had here but insulting the OP isn't
one of them.

When I switched from Polymer to Angular (1) I found a pile of incoherent
design decisions which hobbled performance. It's better than writing
everything from scratch, but that's not saying much. Maybe Angular 2 is much
better, but I understand why it was a total rewrite.

~~~
Noseshine

      >  insulting the OP
    

What on earth are you talking about???

~~~
indolering
I misspoke, I mean the "original author" not the OP.

~~~
Noseshine
That doesn't make your reply to me

    
    
      >  insulting the OP
    

any more comprehensible!

~~~
indolering
Oh Christ, I totally misread your post! I took "I don't see how a non-
developer could even get started" as being in the first person. I'm sorry!

------
firasd
I was amused by this HN comment saying that React is a tax Facebook imposes on
startups
[https://news.ycombinator.com/item?id=12217170](https://news.ycombinator.com/item?id=12217170)

I do think there's a kernel of truth to it--issues raised in this article and
framework choice aside, it's good to ask whether your site needs to be an SPA
at all. Because if so you are committing to a lot of time and resources spent
on the front end.

~~~
enraged_camel
It's not React itself that consumes time. On the contrary, React reduces the
time it takes to develop UIs. Sometimes drastically.

What sucks is everything that surrounds React, or all other SPA frameworks for
that matter. For instance, every time I end up having to deal with Webpack et
al, I want to put a gun in my mouth and pull the trigger.

~~~
ehnto
Managing tooling and dependencies is the worst part of modern front end work.

I don't see why we have to weave such a complex dependency tree and asset
pipeline. Every project does it differently too, so you end up relearning the
same tool with a different name and in different configurations. Too bad if
the previous developer didn't commit the dependency manager manifests or task
runner file too, you can't reverse engineer an asset pipeline if all that's
left is CSS and raw JS.

If anything goes wrong, you end up chasing issues through half a dozen
abstractions you had never heard of. I can't keep all of this plus my actual
project requirements in my head. Let me write some darn code already!

~~~
thewhitetulip
Yes, especially the notorious npm which is hell bent on installing the entire
Internet when I do npm install. God knows what and why it installs the things
it does

~~~
eatonphil
Facebook's yarn [0] is a drop-in replacement for 'npm install' that
significantly improves install times. Really makes me wonder what npm install
is doing.

[0] [https://github.com/yarnpkg/yarn](https://github.com/yarnpkg/yarn)

~~~
dictum
> Really makes me wonder what npm install is doing

Pattern matching.

For every dependency listed in _package.json_ , npm install downloads and
tests every JSON payload publicly available on the Internet until it finds one
that produces the desired npm package.

------
stupidcar
People keep up-voting rants like this about how terrible front-end frameworks
are, but EVERY SINGLE TIME I see an ambitious, high-quality web app upvoted, I
check the source, and it's using a front-end framework. 99% of the time it's
React or Angular.

If frameworks are these terrible monoliths that stop you getting anything
done, how come the teams who are actually getting stuff done, and getting
attention for its scope and quality, are the ones using them?

~~~
Can_Not
It sounds like you saw some great apps using the right tools to solve the
problem space and then you saw some unhappy devs who didn't pick the right
tool for the job.

------
dwaltrip
At this point, I can't really imagine writing a large web app without some
sort of framework.

I've been using mithril.js a lot this year, and have found it to be
unopinionated, minimal, performant, and fairly powerful. You are definitely
not locked into some singular way of building applications.

It's a vdom framework, and its views are fairly similar to React (from what I
hear, I haven't played with React much). You create a hierarchy of components,
which each have a render function written in javascript. I've found this
incredibly liberating. I love not having an unnecessary context switch between
a limited template system and the rest of my application. Also, you can apply
any desired javascript refactoring approaches to your views, instead of
relying on pre-ordained approaches like template partials.

The only potential downside to the unopinionated-ness is that you have to
decide how to structure things and what higher order patterns you want to use.
This has slowed me down a bit, but it has also helped level up my architecture
skills, which has been quite rewarding.

I could have chosen React, and I would probably be similarly happy. My main
reason for not doing so is that things seemed a bit chaotic in the React world
during 2015, and there also seemed to be a lot of spilt milk about doing
things the "perfect way". I imagine it the ecosystem has calmed down a bit
this year.

~~~
methyl
But the point is, neither React nor Mithril are frameworks, they are just
unopinionated libraries where you write plain JavaScript code.

~~~
dwaltrip
It's much closer to a framework than jQuery. Mithril also provides a few core
things beyond just views - basic routing, an ajax helper, and a few others.

I admit the boundaries do seem to get a bit fuzzy. Do you think the article
author would consider React or Mithril as libraries he could use? Or as
frameworks to be avoided?

------
drawkbox
The answer is will a monolithic framework or a set of libraries help you build
the best product with quality and quickly. Whichever one will help you build a
better product is different depending on the context, project, scope, team and
timeline.

In the end I am not a big fan of monolithic frameworks, I prefer libraries
much like OP describes that can be swapped or changed for parts of the app
(routing, data, templating, scripts, style, etc). But sometimes you are on
teams and need a common baseline/plane to keep consistency so you go with
frameworks sometimes rather than having to educate/train on custom.

In the end, what helps you ship faster and helps you focus on your product is
always the best choice. If you are spending all day learning how to use the
framework, going to conferences to learn it, building things in it and
jimmying things so you can get it to do what you need by jumping through
hoops, then it may be a drag on a good product.

Typically frameworks get you 90% of the way fast and the final 10% or
customizing too much is painful, not to mention updates where APIs change
wholesale. Custom gets you there slower but you can finish faster at the end
as the control is immense. Custom usually allows more flexibility and changes
that are on your schedule not the new versions of frameworks that might throw
a wrench in timelines from time to time. Simplicity is the key to good custom
apps to beat the maintenance time of monolithic frameworks.

A framework is an abstraction and you have to decide if that abstraction is
worth it, the real platform is javascript, css, html in the end, how much
stack do you want on top of that is a question that changes by project.

------
dwightgunning
Solid advice for anybody who is already an experienced developer and capable
of authoring an SPA framework of their own.

For regular devs with deadlines, the need to onboard new team mates, and
produce a readable and maintainable codebase, a modern SPA framework will be
of benefit.

------
pjmlp
"Well, actually, we do. If our overhead for producing working development code
is greater than say, oh, 5 seconds, then somebody out there is definitely
kicking our ass on cycle times. That developer can fail 300 times in an hour.
If it takes 200 failures before success, it will take a miniumum of 40 minutes
to resolve an issue with a 5s cycle time. If our cycle time is 5 minutes
because of all the multi-compile overhead, our minimum time for success will
be 72 times longer, or over two full work-day. So we can pick 40 minutes or
2.1 days to resolve an issue to the same level of completeness. You make the
call."

Interacting with other people is what takes my time, not trying to break the
Guinness record of code changes per day.

------
lacampbell
I am new to front end development - javascript and html. I am dismayed at how
slow and unproductive I am trying to develop simple web apps. People advise me
not to use jquery anymore because ES6 makes it redundant. But I am not sure.

I don't know if I want a framework, but I do want a library that lets me write
less code, rather than solving boring problems that I am sure have been solved
a million times before. But I guess at the same time, I want a fast loading
web app. Where's the balance?

Interesting bit about the javascript transpilers. Some of them look cool, but
I don't know how much static typing I need in something I am constantly
refreshing and prodding. And it's another layer of complexity..

~~~
pjmlp
Developing JS + HTML + CSS applications on a stack created for interactive
documents, feels like stone age when compared to the RAD GUI tooling of the
90's.

It always feels like an whole generation was raised on the web without ever
trying out proper tooling for native development.

For me it feels like a Roman taken from the apogee of the Imperium time
traveling into the middle dark age.

EDIT: CS => CSS

~~~
rimantas

      > whole generation was raised on the web without ever
      > trying out proper tooling for native development.
    

What's worse they try to drag this into native too. I am tired of repeating:
do try and find out what native offers before bringing your crap into it.

------
codedokode
Answering the question in the title: no, probably you don't.

Many developers today do not understand what a SPA is and when one should
choose this architecture. Writing a client side and a server side code is more
complicated task that writing just a server side code so it should be
justified.

Client side code is necessary when building interactive applications like
spreadsheet or when an application has to work offline or store data locally.
When a website feels more like a desktop application than a plain web page.
There should be reasons to complicate architecture.

Most of a web sites are just a collection of pages, not applications. Using
SPA there gives no advantages. For examples, developers of this website [1]
used a megabyte of Javascript and API to display a list of 10 links. I do not
see a single benefit from using SPA here over serving a 5Kb HTML file with
those links. Everything just got worse.

And it looks like some JS frameworks authors do not understand it too. For
example, I looked at Ember documentation and saw a tutorial [2] on building a
rental site. Using Ember there gives no advantages over good old server-side
generated pages (optionally using github-style AJAX page reloading). This
over-engineered approach just makes a website load slower, comsume more CPU
and memory resources, increases complexity, complicates deployment. If they
are presenting Ember as a tool to build _applications_ they should provide an
example of application, not a plain old HTML 1.0 website.

[1] [https://whosfiring.com/](https://whosfiring.com/)

[2] [https://guides.emberjs.com/v2.9.0/tutorial/ember-
cli/](https://guides.emberjs.com/v2.9.0/tutorial/ember-cli/)

------
kensign
I suggest people check out [http://aurelia.io](http://aurelia.io)

Otherwise I have to say this is the worst advice for any engineer building a
commercial website. Maybe if someone went back in time 10 years, this might
look like a solution, but there is a reason all of this is left behind. I've
been a web developer for 20 years now and browser development has finally
graduated to real software engineering.

The author has a laundry list of grievances based on their own experiences.
It's clear that these are merely opinions though, and they can be taken at
face value.

"Frameworks and complexity === insanely long cycle times"

This is simply not true and it's purely subjective. Any developer using
Continuous Development can roll out changes to production in a matter of
hours, if not a few days. Sophisticated apps need to be modular and engineered
for a simple workflow, automated testing and a clear separation of concerns.
There is no point to setting yourself up for defeat, and if anyone followed
this advice, that's exactly what would happen.

There's a clear distinction between the FUD of naysayers compared to people
with more sophisticated levels of development experience. I am not sure
someone with this mindset could even get past a phone screen. egad.

------
shanwang
I started web development by learning Angular 1, maybe I'm the minority, but I
actually liked it in the beginning, and only grow to dislike after dived deep
into it.

I was a web newbie but experienced developer in other field. The attraction of
a framework like angular is it lets you write relatively large chunk of 'flat'
code without having to worry about the structure of your code. So for a newbie
it's easy to get started, of course you'll eventually face the dark side. But
then you have to make a choice to either abandon angular and go for something
else, or keep on going and make yourself good at angular.

Another thing is, there are plenty of good resources for learning frameworks
like angular and react. Can anyone point to me some good up to date resources
of building a functioning website from scratch by using purely jQuery?

------
agentultra
_Well, actually, we do. If our overhead for producing working development code
is greater than say, oh, 5 seconds, then somebody out there is definitely
kicking our ass on cycle times. That developer can fail 300 times in an hour.
If it takes 200 failures before success, it will take a miniumum of 40 minutes
to resolve an issue with a 5s cycle time. If our cycle time is 5 minutes
because of all the multi-compile overhead, our minimum time for success will
be 72 times longer, or over two full work-day. So we can pick 40 minutes or
2.1 days to resolve an issue to the same level of completeness. You make the
call._

I'm presently working my way through _Programming in the 1990s_. In it's
controversial premise, it states:

 _Basically we are taught to guess our programs, and then to patch up our
guesses. Our errors are given the cute name of "bugs". Fixing them becomes
puzzle-solving, as does finding tricks that exploit or avoid poorly designed
features of the programming language. The entire process is time-consuming and
expensive._

And while I appreciate short cycle-times between code and result; I find
"guessing my program into existence" is the most sure-fire way to shoot myself
in the foot.

Now I don't write a specification for every program. However one doesn't have
to these days to gain the benefits of fore-thought and reasoning. Functional
programming has revealed many patterns and algebras for programs that work
well in practice. If compiling a higher-level, soundly-typed language into
Javascript takes an excruciating 5 seconds it'd still be worth it because I
will have fewer bugs in my code, _by design_ , over the developer that
continually adds code in a hurried frenzy.

In spirit I agree that frameworks are restrictive but I don't see how
Javascript is there to help prevent you from writing errors. A framework would
at least give you the ground work to avoid egregious ones. Though better
still, use functional programming patterns or languages if you can and compile
down to Javascript if you must. Works well.

------
kevan
The author has an entire section on long cycle times (time to make a change,
compile/transpile it, and try it out) but it hasn't been nearly as bad for me.
The worst case I've experienced was a large Grails app using Babel
transpilation that could take a minute to compile all assets on first startup.
But that worst case only happened after a full clean. Incremental builds took
about 2 seconds. I've never experienced a 5 minute cycle time due to a
transpiler.

In our case the productivity gains from ES6 features easily outweighed the
compilation time.

------
royka118
Just feels like a rant tbh. I've developed spa's as well as django and rails
app. I've seen bad spa's been written as well as bad server side routing apps.
Shit code is shit code wherever/whatever language it's written in. To say you
don't need some sort of FE framework is prob a bit much. You get so much for
free and websites are getting more and more dynamic not less. Sure don't use
flavour of the month frameworks. But I'd argue ng1, ng2, react, Vue etc are
not flavour of the months.

~~~
rimantas
Shitty code is one thing. Shitty choice of the solution for the problem at
hand is on another level.

------
ioda
At [http://www.reportdash.com](http://www.reportdash.com) we use backbone with
backbone layout manager and jade. We have been able to design a pretty robust
report and dashboard builder with just a single front-end developer.

Never once did I regret the choice, nor has been limited by the choice. I
pretty much could implement everything I thought with minimal effort.

I would say backbone with backbone layout manager has the bare minimal
abstraction. It just boils down to picking the right pattern. I use a state
variable to hold everything related to the dom, and re-render the dom whenever
the dom needs to be updated. May not be as fast as 'react', but at least in my
case, it is good enough. ( Since my 'views' are nicely factored, I often has
to re-render only a small part of the dom)

Without the framework, I would have taken double the time for sure. And boy,
the code is nicely organised as well.

I did have some experience in developing spa's using jquery alone. Well, that
was in 2009. On any day, I would vouch for Backbone+ Backbone Layout Manger +
Jade over simple jquery

I used to wonder why it hasn't been as popular as react or angular.

~~~
bikamonki
> I used to wonder why it hasn't been as popular as react or angular

Mainly b/c it isn't a framework endorsed by Google/Facebook.

------
iamleppert
You don’t need any of this stuff to build a great web app. You don’t need
react, you don’t need fancy javascript syntax that requires you have a
complicated build infrastructure. Babel has over 40,000 files. Think about
that for a moment. 40k files for some shorthand syntax. Your "build" times may
only be a few seconds now (anything that is over one second imo is too long),
but just wait. They will get to 30+ seconds in no time and then you'll have to
go dive into the belly of that 40k file beast to find out how to unfuck
yourself. I've been there.

You don’t even need a framework most of the time. Most of the frameworks I’ve
used are poorly designed (I'm looking at you Ember. If there are any Ember
devs reading this, I'll meet you in the parking lot...) and represent the
design choices of a someone working on some project probably a lot different
than yours. It feels good to give up control and let someone else make some
choices for you, until you realize you’ve built an application based upon
their poor design, and then you’re stuck.

All you need is semantic HTML, the DOM, and some plain old javascript.
Organize your code, write simply, don’t overcomplicate and try to make things
too general because your problems probably are very likely concrete anyway.
Don’t buy into the hype. Just because big company X uses something, doesn’t
mean you need to use it on your projects too. Have you seen Facebook? Their
product hasn’t changed or innovated appreciably in years so you shouldn’t be
taking any lessons from them in how to build ‘scalable’ applications, whatever
that means.

Don’t dump a 500 KB framework on the page to save a few milliseconds in
incremental rendering. Or think you need to worry about performance or
complexity before you even have an app.

Is it odd to anyone that the entire battle cry of React is rooted in pre-
optimization? The myth that the DOM is somehow evil, or all pages will one day
have millions of elements to manage? This is gladly spoonfed to people who
don't understand how the browser works, and never learned the basics. Take
away their framework and they don't know how to build apps!

It violates my sense of pragmatism to save a few ms in rendering when you
delay the initial page load by 500 ms or more? I also personally find the
mixing of declarative and imperative programming styles and JSX to be
absolutely horrid and the debug experience of many of the immutable libraries
to be terrible. And, if you actually performance test the stuff you'll see
they are full of either outright lies or fabrications to make the authors look
good. Hint: if every time you call a getter on an object it causes the
framework to go 30 stacks deep you're not going to have good performance. Just
try it in your framework of choice today. You're swear we're working in java
these days with the stack traces so deep and abstracted they have lost all
touch with reality.

My favorite recently is to find all kinds of bizarre wrappers for javascript
libraries that could have been used well enough on their own. The wrappers
don't really do anything other than hard-code the original author's API and
basically act as a middle man. I guess everything needs to be wrapped in a
react component to be useful these days huh?

------
SandB0x
Since the article doesn't define the acronym and I had to look it up:

SPA means Single Page Application.

The term is written in the third paragraph, but not clearly connected to the
acronym.

------
z3t4
JQuery solved a real problem when it was created. But the problem no longer
exist, the standards has settled. But at least you can just stop using it and
use CSS and standard API's instead. But when it comes to a framework,
especially if it has a compilation step, it's not easy to just stop using it.

------
vladimir-y
A need to use frameworks is the unification matter. Unification is necessary
for serious/big projects for obvious reasons. Ie you can find people on the
market who are able to start working quickly due to the familiar
tools/structure used, not dealing with some "homemade" frameworks.

------
trey-jones
I feel this way about backend frameworks, but to me if you take the time to
learn something like Angular, it saves will reduce the bulk of the code
substantially, compared to using jQuery for example. A listener for this, a
listener for that? No, just data-bind and be done with it.

There are challenges of course. Once you are in, you are all in, and you will
be maintaining this application for its lifetime or rewriting it. Javascript
frameworks these days move at the speed of sound, so if you start writing it
today at while your framework is at v1.0, there is a good chance that your
framework will be v1.5 by the time you release, with several breaking changes.
This is probably the most aggravating part to me.

I have thought that perhaps the diversity of opinions on these sorts of
issues, and the speed at which these frameworks are written and rewritten are
symptoms of a larger problem, namely the browser as a platform.

------
snarfy
I'd rather have a good, easy to use library than a framework.

------
aikah
Developers want declarative widgets mainly. Obviously web components are
supposed to solve all that but they are still not widely supported by
browsers.

------
curried_haskell
To answer the question, yes. Yes I do.

------
dalacv
just use [http://Bubble.is](http://Bubble.is)

------
eeZah7Ux
No, not at all.

------
meitham
Yes

------
pka
This is insane.

Even keeping _two_ different views in sync in different parts of an
application without a framework is so much work it's not worth the effort, let
alone building a whole SPA.

But to each their own.

