
Why Is Front-End Development So Unstable? - njn
https://www.breck-mckye.com/blog/2018/05/why-is-front-end-development-so-unstable/
======
meredydd
Web frameworks are churn-y because they are incredibly leaky abstractions
covering really awkward impedance mismatches. This means that they are never
quite satisfactory - and that just to use one, you need to be capable of
building a new one yourself.

Think of a typical web app. Your data exists:

1\. As rows in a database, accessed via SQL

2\. As model objects on the server, accessed via method calls and attributes

3\. As JSON, accessed via many HTTP endpoints with a limited set of verbs
(GET/PUT/POST/DELETE)

4\. As Javascript objects, accessed via (a different set of) method calls and
attributes

5\. As HTML tags, accessed via the DOM API

6\. As pixels, styled by CSS.

\--

Each time you translate from one layer to the next, there's a nasty impedance
mismatch. This, in turn, attracts "magic": ORMs (DB<->Object); Angular
Resources (REST<->JS Object); templating engines (JS Object<->DOM); etc. Each
of these translation layers shares two characteristics:

(A) It is "magic": It abuses the semantics of one layer (eg DB model objects)
in an attempt to interface with another (eg SQL).

(B) It's a terribly leaky abstraction.

This means that (a) every translation layer is prone to unintuitive failures,
and (b) every advanced user of it _needs_ to know enough to build one
themselves. So when the impedance mismatch bites you on the ass, some fraction
of users are going to flip the table, swear _they_ could do better, and write
their own. Which, of course, can't solve the underlying mismatch, and
therefore won't be satisfactory...and so the cycle continues.

Of these nasty transitions, 4/5 are associated with the front end, so the
front end gets the rap.

(I gave a lightning talk at PyCon two weeks ago, about exactly this - stacking
this up against the "Zen of Python" and talking about some of the ways we
avoid this in Anvil: [https://anvil.works/blog/pycon18-making-the-web-more-
pythoni...](https://anvil.works/blog/pycon18-making-the-web-more-pythonic))

~~~
lkrubner
What is curious is that the tech industry has been very conservative about
rethinking these 6 things that you just listed. Why rows in a relational
database? Why objects? Why Javascript? And why HTML? We'd surely be in a
better place if we got rid of these things and rethought our approach from
first principles.

I've written about these issues many times before.

Regarding the problem with objects, I wrote "Object Oriented Programming Is An
Expensive Disaster Which Must End":

[http://www.smashcompany.com/technology/object-oriented-
progr...](http://www.smashcompany.com/technology/object-oriented-programming-
is-an-expensive-disaster-which-must-end)

Regarding the problems of HTML, I wrote "The problem with HTML":

[http://www.smashcompany.com/technology/the-problem-with-
html](http://www.smashcompany.com/technology/the-problem-with-html)

To answer the question "Why Is Front-End Development So Unstable?" the answer
is surely, in part, the fact that we refuse to build technologies that are
designed to be great front-end technologies.

~~~
Cthulhu_
There have been attempts at rethinking it though; noSQL was the buzzword of a
couple of years ago, and even nowdays there's mature tools like Firebase that
allow you to store and retrieve data much more directly than e.g. SQL. The
challenge in nosql storage is of course data migrations and whatnot. But yeah,
in theory you can just open up a MongoDB instance to your front-end and not
have to bother with SQL or much of a back-end.

And your last comment doesn't make much sense tbf; the big frameworks, most
notably Angular and React (and its ecosystem) were both designed to be great
front-end technologies.

~~~
lkrubner
Angular and React both rely on Javascript and HTML, so you can't describe them
as "designed to be great front-end technologies". HTML was designed for
document exchange, it is a descendent of SGML. Javascript was initially meant
to be a light weight scripting language that allowed dynamic elements in HTML.
It's gotten better over the years, but it is still far from what you would
expect if you were trying to build a great programming environment for the
front end. As to the limits of HTML, just consider forms. In the last 20
years, there have been very few new form elements added. Compare the form
elements available in HTML in 2018 to what VisualBasic 6 had achieved by 1999,
or what Netbeans/Swing offered by 2003.

~~~
emodendroket
> HTML was designed for document exchange, it is a descendent of SGML.
> Javascript was initially meant to be a light weight scripting language that
> allowed dynamic elements in HTML

I always see people saying this, but why does it matter? Electricity was
originally piped into homes for lighting, but we don't need an alternate way
to power all the electric devices in our home. Unix was designed for computers
that are quite different from the ones we use today. And so on.

~~~
lkrubner
I can't repeat all of my arguments in a comment on Hacker News. I would ask
that you read what I wrote in "The Problem With HTML":

[http://www.smashcompany.com/technology/the-problem-with-
html](http://www.smashcompany.com/technology/the-problem-with-html)

------
freedomben
This is a really well-written and well-thought out piece. The author touches
on a number of points but never gets polemical. This piece resonated with me
particularly well:

> _Be wary of self-promotion_

> _Over the last few years I’ve seen much more aggressive self-marketing in
> the JavaScript world, possibly due to the rise of paid online training
> materials and the employment /consulting advantage of being a Github
> ‘celebrity’. I’ve no problem with people being incentivised for good
> content, but increasingly I feel I see dishonest tactics: self-citation;
> invented, proprietary terminology (so searching takes you back to the
> author’s materials), and name-squatting (e.g. ‘Standard.js’)_

This is becoming a big problem in JS world, particularly over the last 3 to 4
years. Like the author, I have no problem with people taking credit and being
respected, but we as a community are becoming much too centered around
people/personality than technology. I've been guilty of this in the past too
(love you Pete Hunt ;-) but it's not healthy IMHO.

~~~
Karrot_Kream
I'm finding the growing celebrity culture of programming to be troubling. I
find that programming is becoming less and less about code or architecture and
more about evangelism and marketing, but I'm not sure what changed in the
incentive structure for this to happen, and I would like to find out.

Aside: This has made me reconsider being a career programmer.

~~~
nostrademons
Is this actually a new phenomena? I remember when I started programming c.
2000, the big-name programming gurus were folks like Kent Beck, Ward
Cunningham, Uncle Bob, Ron Jeffries, Dave Thomas, Joel Spolsky, Jeff Atwood,
Martin Fowler, et al. While some of them mostly knew their stuff, some were
outright hacks (Peter Norvig's vs. Ron Jeffries' attempts to create a sudoku
solver is one of my favorite examples [1]). Most of their names wouldn't be
recognized by someone just getting into programming now.

As I've gotten older, I've learned that there's often an inverse correlation
between how good a programmer is and how likely you are to have heard of them,
because the folks who get good at programming are _actually programming_ and
not writing blog articles about programming. Most of the latter are really
content marketing, trying to drum up business for consultancies, and so you
should treat them as advertisement rather than advice.

[1] [http://ravimohan.blogspot.com/2007/04/learning-from-
sudoku-s...](http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-
solvers.html)

~~~
nallerooth
I think this is a very good point. But it's also important to remember that
not all programmers/tinkerers that are creating blog posts/videos are looking
for fame - some of them are just proud of something they built, and that's
fine.

Inspiration is a great enabler, and taking a few shortcuts to make something
work may be just the thing that allows someone to actually finish one of their
projects. The problem is that if you lack the knowledge to see that something
is a hack - you learn things the wrong way. Still, without this inspiration -
some people wouldn't start to learning at all.

------
underwater
Calling out Vue.js as a possible solution is hilarious. Selling a trending
technology as a silver bullet is exactly the problem he complains about in the
article.

Comparing the development methodology of Facebook - the company behind React -
and this mindset is illuminating. Facebook famously rewrote PHP and added
extensions like XHP rather than start their codebase from scratch. React
follows a similar philosphy. It can be incrementally introduced into a
codebase without radical rewrites.

These lessons are largely ignored in the open source community, where everyone
will gladly tell you how your tech is all wrong. This is actually really easy
to avoid. Just focus on solving the problems you have and only adopt
technology that is relevant to you.

~~~
_bxg1
In my experience, Vue is much easier to integrate gradually than React. You
can't knock it just because it's relatively "trendy". Do your research.

~~~
oulu2006
That's been our experience as well.

I much prefer the more holistic approach to development that Vue.js provides
over React.

And we did spend a year working with React, so it's not just something we did
off the cuff.

------
_bxg1
At some point, when modules get "micro" enough, the effort of managing them
and learning their usage outweighs the effort of implementing the thing
yourself. Most JavaScript projects seem to walk that line quite closely.

I'm a React developer at work, but I recently gave Vue a try at home. This is
one of the things that most stood out to me about it. React makes a selling
point out of the fact that it's "just rendering". It doesn't try to do
everything for you, it tries to do one thing really well. That sounds great,
but it leaves out a factor. Having your primary framework be "simple" and
"lean" doesn't translate to your project being simple and lean, because your
project still needs all that other stuff. You just now have to get it from
somewhere else, which often adds more complexity than it's worth.

When I downloaded Vue all I had to do was add a script tag to my HTML document
and start writing a modern reactive UI. No other modules or frameworks. No
build system. No special JS-targeted languages. Vue does everything you need,
and it does it all pretty well, and sometimes that's more valuable.

~~~
philliphaydon
I learned React at home, then learned Vue. I fell in love with Vue because i
clicked on the getting started, threw a bit of code in a html file, and ran
it, and it worked, then I played around and changed things, the moment i ran
into something like "oh how do i do this?" the documentation is second to none
for client side frameworks, I found what I was looking for quickly.

Then I started to find other stuff like vetur, the vue cli, and I felt like I
was just building stuff, and it worked, and I wasn't pulling in other plugins
just to get stuff done.

The barrier to entry was much lower IMO.

Just wish I could switch from Angular X to Vue at work :(

~~~
_bxg1
Vue gave me that wonderful jQuery bootstrapping experience, but with a modern
data-driven DOM. It's so pleasant.

------
ggregoire
Sorry but I find font-end development pretty stable.

Having to learn a new library every 3-4 years (because of a new job,
generally) is it really a big deal?

In my career I also had to learn Java, PHP, C#, Node.js, bash, batch, Python…
Build apps with Spring, CakePHP, Symfony 1 & 2, ASP.NET MVC 3 & 4… Query
database with Hibernate, Entity Framework, Linq SQL… Handle dependencies with
Maven, Nugget… Store data in Postgres, MySQL, SQL Server, Mongo, Redis,
Redshift… Host on OVH, Digital Ocean, Heroku, AWS… Learn REST and GraphQL, SVN
and Git, Linux and Windows Server, Vagrant and Docker… And according to HN,
what's really hype right now is Rust, Go, FoundationDB, Kubernetes, and so on…

Any idea why back-end development is so unstable? :)

~~~
Doctor_Fegg
> Having to learn a new library every 3-4 years (because of a new job,
> generally) is it really a big deal?

_If_ frontend development is all you do, then no, it isn't.

One of the good things about the internet is that it's possible for a lone
wolf to build and ship something amazing. One person can understand enough of
the full stack, from HTML/CSS through JS to a serverside language and basic
server administration, to build something great, unfunded.

The constant churn in frontend development makes that increasingly difficult.
If you find a useful library for your backend code, great, just 'gem install'
it (or pip or whatever). Useful JS library for your frontend code? You've got
to learn the packaging technology du jour just to be able to install it. In
two years' time this'll be different, and you'll have to get to grips with
another complex web of tiny little components that fit together in ways you
don't fully understand. Whereas your backend (for me, Ruby+Postgres) is still
essentially the same it's always been, and just as great.

Indie full-stack developers can no longer keep up with frontend development,
and I think that's a great loss.

~~~
Raphmedia
> Indie full-stack developers can no longer keep up with frontend development,
> and I think that's a great loss.

Who exactly? Did you ever hear a front-end developer say that or are you
building a strawman?

There's nothing stopping anyone from building a simple jQuery powered website.
There's nothing stopping anyone from building an app with Angular 1 either.
Hell, you can even download .zip files on GitHub, unarchive them in a folder
and start using them in your projects. Complex build system are only a way to
streamline development when you get to a certain level of projects output.

~~~
lolsal
I was a full-stack developer 5 years ago. I am not any longer due to the chaos
in frontend development technologies, best practices, etc. It was too much for
me to keep up with, so I opted out and only do backend stuff now.

------
perlgeek
> 2.5 years for the youngest isn’t that old in the scheme of things - it’s
> less than half the support lifespan of your typical desktop OS, for example
> - but it’s still a ways off our caricature.

Let's compare it with some server-side technologies:

Python/Django: 2005

Python/Flask: 2010

Nginx: 2004

Perl/Catalyst: 2006

Maybe I'm biased towards older software, but the difference to the popular
frontend stuff is striking.

The only thing in the frontend with a comparable history (that I can think of)
is jQuery -- and I still use it today, but it seems many developers frown upon
it these days. And it's a library, not a framework.

~~~
zitterbewegung
I think more developers should use jquery to prototype an app and move torward
a framework when it is needed. The same should be said when adopting redux
when using react . Also webpack for building and moving beyond SQLite for data
.

~~~
no1youknowz
> I think more developers should use jquery to prototype an app and move
> torward a framework when it is needed.

They really shouldn't. With VueJS it's not that difficult to get setup and
running with the CLI and components is such a game changer.

Don't get me wrong. I love jQuery, there's nothing better than taking someone
else's library and then extending it. Here's an example [0].

However, one thing that I have learned. It's much simpler and easier to
develop code in Vue compared to jQuery. It took me a day to develop a wizard
exactly the same as [1]. Of which it's now a component which I can drop in
anywhere in my codebase (which I do numerous times) and in future Vue
projects.

So FuelUX code: 463 LOC vs my Wizard: 180 LOC.

One last thing to leave with. I have a page builder much like Elementor. In
jQuery I'm doing a lot with the Dom and it's such a pain in the ass. It's
about 20k LOC alone with hundreds of functions.

Today, with Vue. I prototyped a JSX/JSON backed version, where a watcher
listens to the store. The UI commits any changes to the store and the watcher
re-renders the HTML. I did this with just ~90 LOC.

Completely unbelievable from my perspective and I'm still only a newbie when
it comes to Vue, Webpack, Babel, etc.

jQuery/jQuery UI. It was great, but it's time to move on.

[0]:
[https://github.com/bgrins/spectrum/issues/480#issuecomment-3...](https://github.com/bgrins/spectrum/issues/480#issuecomment-316187422)

[1]:
[http://getfuelux.com/javascript.html#wizard](http://getfuelux.com/javascript.html#wizard)

~~~
aaron-lebo
Mithril is similarly small and very easy to get started.

~~~
RodericDay
Mithril is my favorite by far.

It's not even close. It's depressing how little-known it remains.

~~~
pygy_
@RodericDay, I just vouched this comment which was [dead].

You've been shadowbanned since
[https://news.ycombinator.com/item?id=14982937](https://news.ycombinator.com/item?id=14982937)
(9 months ago) you may want to appeal that decision or create a new account.

------
dhruvarora013
I'd actually say that its less about instability and more about rapid
experimentation. There's two main catalysts - the youth of single page web
apps and the openness of the modern web.

The complexity of your everyday website is increasing as they move from static
sites to web apps. The pressure to be as responsive and fluid as a mobile app
is high, and that requires solutions for data management and synchronicity.
There is no standardized way to solve these yet.

When you tie this increasing complexity with the free-form structure of the
web (there is no recommended way to build a web app unlike mobile apps or to a
lesser extent desktop apps), and then add the growth of JavaScript from a toy
language to a full-blown complex ecosystem, you get even fewer established
practices.

This is not to say that there will never be best practices but rather that
what you're seeing is a language scaling with its needs without having a
central dictatorial entity at its helm. You're seeing unprecedented growth and
that can easily be confused with chaos and instability.

~~~
vram22
>The pressure to be as responsive and fluid as a mobile app is high, and that
requires solutions for data management and synchronicity.

Can you explain what you mean by that? Is it related to mobile apps supporting
notifications, as one point. maybe?

------
keyle
It's also very unstable and young because requirements keep moving, and
developers keep figuring out more 'auto-magic' and simply better ways of
implementing UIs.

UI used to be simple, a page, a few links, click through to other pages. Then
we needed templated pages, because we had a lot of pages.

Then full blown 'applications' were ported to the web, and life was a
nightmare of double-headed dragons and dark holes with pikes. Jquery provided
some help here but it was more in terms of nuts and bolts, than as an
architecture.

Then came all the MVC libs which really helped enforcing a structure for large
apps.

Then came Angular and all of its madness, but a positive step ahead, giving us
usable SPA.

React brought some sanity back and now Vue (in my opinion, don't shoot) brings
the sanest/cleanest way forward.

My guess is what we do on the web will change once again, in a few years, and
we will throw all that out and start again with new framework. Whether it will
be in AR or still on the web, there are still many problems to solve.

E.g. the whole 'responsive' thing.

~~~
mirkules
To expand on your point, somewhere along the line, the web went from a content
delivery mechanism to a full GUI + content delivery mehanism.

The allure and advantages to developing a full GUI on the web are many,
including portability and availability.

But the downside is that you are suddenly developing to the lowest common
denominator - the browser - which not only has to support the "old" web but
complicated GUIs (something it was never designed for), which in turn means
all sorts of "magic", as you put it, to make it work (i.e. crazy DOM
manipulations).

And because browsers were never designed for this, there is no One True Way to
develop a simple user action. Search for "drag and drop in javascript" for
example. So what happens is, everyone invents their own way of doing stuff,
which turned into a race of who is more popular/clever, resulting in a
gajillion ways to do the same thing.

~~~
tracker1
There are drag/drop APIs defined... but people make abstractions... This
happens even in desktop UI development. There are _LOTS_ of front-end
libraries.. but it takes a lot of effort to make them, so there are still far
fewer.

The web is easily flexible, and configurable in terms of how you deliver your
UX... you aren't hamstrung into creating something that looks like it was made
in 1996.

~~~
mirkules
Delivery and flexibility are the greatest pros. But while the delivery
mechanism is great, the UI has to be delivered and interpreted every time,
through an unknown engine that theoretically follows a spec. This results in
a) slower execution times and b) inconsistencies in how the UI is interpreted.
Javascript browser applications are simply slower and less stable for than
their native counterparts for those reasons.

All that on top of a language which is on par with PHP as far as consistency,
and often times worse.

With regards to your 1996 comment, again I beg to differ. Try writing
Photoshop or GarageBand as a web app. I shudder to think what that would look
like, and the cost each would incur.

There is a reason that "mobile web apps" have lost the battle to native,
essentially - the friction to deliver an app is much smaller (app stores),
every platform is more-less consistent and the apps are smoother and faster
instead of choppy and half-baked for web apps. I would much rather, for
example, use a Home Depot app than their website. Or Coinbase vs. GDAX (even
though GDAX is more feature-rich). I can't even think of a webapp that I'd
rather use (on a regular basis) if an app is available instead.

But maybe I'm just a graybeard who can't accept change. Or maybe I'm simply
old enough to remember what 1996 was like for UI, and that the web today feels
like those times, just with prettier icons. Likely a combination of both.

~~~
tracker1
I take umbrage with your PHP reference... JavaScript the language is pretty
damned consistent, and nice. The browser APIs, that's a different story.

As to PhotoShop or GarageBand, I think there's some more flushing out to do as
far as APIs, and frankly that kind of stuff might be workable with
WebAssembly. It would take a lot of effort to convert everything, also, not
sure if you can use WASM in WebWorkers, but that may be more ideal. As to the
cost, are you meaning overhead, or programming cost?

I'd guess a not insignificant number of "native" apps for mobile are at least
partly framed web apps. Also, I would probably just reach for React Native and
re-use as much as possible, which would still leverage JS for most of it.

In the end it depends... you get a _LOT_ from web applications today. I see it
as a bigger boost for internal/corporate/enterprise applications. Because you
don't have to manage wide infrastructure and updates in nearly the same ways,
you can simply do server deploys and be done.

Also the 1996 apps reference was in that most UI toolkits default to looks
that haven't changed much since 1990's and aren't skinnable in the least. I
remember the late 90's and early 2000's, litestep and winamp were two of my
favorite things. I know that was user customizations of apps, over
developer/designer. All the same, maybe I want my site/app to look like
Material Design over Bootstrap, or something else.

------
dustingetz
It's because of all the icky data-sync for the client/service round trips. An
async, slow, failure-prone concern wired throughout the entire codebase. I/O
hurts everyone in subtly different ways and it's hard to solve so you see a
lot of churn.

service/database has this problem too (the ORM flamewars of the 00s) but to a
much less degree because it is in a happier place on the latency chart:
[https://gist.github.com/jboner/2841832](https://gist.github.com/jboner/2841832)

~~~
rubber_duck
Not really - those things exist in native frontend as well but it's more
stable than js. Writing GUI is not trivial, people take stuff like data
binding/templates/MVC etc. for granted nowadays, go check out early desktop UI
libraries like say win32/MFC/winforms/gtk+. Took a long time to get to stuff
like WPF, Qt quick, etc.

With browser there were several constraints :

ES5 is extremely error prone and scales very poorly to larger codebases

slow JS VMs

missingt for sane layout like flexbox

1\. Got better with npm, we pack, es6 transpilers, typescript/flow and tooling
built along the way

2./3\. Got solved by finally depricating everything < IE9 (IE in general if
you're lucky) and tooling

I'd say angular is relatively stable now and decently productive once you get
a hang of their patterns, I've been using it for different frontend projects
since early betas, written ionic apps for mobile with it - have very few
complaints about the framework, some of the stuff didn't always work along the
way (like ahead of time compilation, i18n) but recently (5+) I've had 0 issues
with the framework and I'm quite productive with it. I think the alternatives
will mature as well and things will settle.

~~~
dustingetz
Native frontend on desktop and mobile have in-memory database and sync out of
band. Web browser tab is too resource constrained to run a in-memory database,
and less secure as well (you don't have root on your iphone so Facebook can
restrict your data access patterns, prevent scrapers, prevent mass-delete of
all those old posts, etc)

~~~
rubber_duck
Those things don't remove the sync issues, blocking the UI thread, they just
enable a slightly better use experience.

And dealing with asynchronous code is not the only issue in writing frontend
code, GUI apps can be really complex beasts, managing that complexity
effectively requires tools that didn't exist in js world untill recently.

~~~
dustingetz
They kind of do though, the complexity of data sync can now be dealt with
entirely separately from the complexity of the app logic itself (which is not
true of, say REST architecture)

------
pavlov
This part puzzles me:

 _> "Put yourself in the shoes of a junior-to-mid-level JavaScript developer,
writing a new application for the first time._

 _> "It starts innocently enough. You have a completely clean slate and want
to keep things simple. You are a devout Agilist and YAGNI is your watchword.
So you begin with a ‘simple, barbones framework’. That sounds good, doesn’t
it? (Even if it did not, that’s often the only choice you’ve got)._

 _> "Being barebones it does little, so the task falls on your shoulders to
choose some helper libraries. If you are doing frontend work, it might be
helpers for Redux for forms and API requests. If backend, it might be
middlewares for Express."_

Why is the default answer to the problem of "it does little" to "choose some
helper libraries"? Shouldn't it be: "I'll write some code to make it do more"?

Why does this first-time app developer need Redux? Why would she need a helper
for Redux to do API requests? These days you can just call fetch() — it really
doesn't get any easier.

All the APIs that one gets in the browser or in Node.js are already very high-
level and easily understandable by entry-level developers. If anything, piling
more leaky abstractions on top will just make things more complex. How did it
happen that junior JavaScript developers feel so insecure about using the
standard stuff?

Maybe it's because more senior developers have spent two decades crapping on
the standard stuff. Therefore, as a self-appointed spokesperson for the
veterans, I hereby grant all junior JavaScript developers full permission to
just go ahead and program whatever they want without having to look for a
single library or creaky build tool — and they shouldn't feel bad about it in
the least.

~~~
Omnius
> How did it happen that junior JavaScript developers feel so insecure about
> using the standard stuff?

I know a lot of "developers" that are learning frameworks and not javascript.
When you start in a black box then you look for other black boxes to fill in
the gaps you need.

I am not even opposed to that. I strongly believe in never re-inventing
(unless its academic) what can be used and has been tested, but when the
developers are not javascript developers but react, vue, angular developers.
Then you get this gap where the inexperienced are afraid to outside of what
others have built.

~~~
pavlov
One has to learn somehow, and reinventing is an important part of that.

Aspiring artists will paint nude figures and flower arrangements and white
cubes on draperies, even though these subjects were done to death centuries
ago. Junior programmers should feel the same way about doing things that have
already been done: someone probably has done it better, but I still have to do
it for myself, maybe a few times over to get the hang of what's the point.

~~~
Omnius
I don't disagree its why i said unless its academic.

------
donkeyd
> Imagine being a junior developer

The junior developer has it easy. Imagine being the tech lead for a startup
that has to pick the framework that'll be used to build an application that
needs to e maintained and that they'll need to hire developers for to
maintain.

I was this person, I made a choice and now every single person is casting
doubt on it. The choice wouldn't have even mattered, It's near impossible to
find experienced front-end developers of any kind right now and everybody will
always ask "why not [this framework I'm familiar with]?"

------
spankalee
Asking this question without looking at the underlying platform is ignoring a
huge source of insight into the problem and its solutions.

Growing up from a document viewer to an app platform in the particular way it
did left the web as the most important and ubiquitous GUI app deployment and
runtime platform, but without a dev-accessible native GUI component system. No
other major modern UI platform was _ever_ in this state.

This left all the work of creating the most basic widget system to userland,
while at the same time the platform's features available to that userland were
relatively paltry to begin with. As those features of JavaScript and DOM grew,
frameworks were released frequently because newer ones were designed to take
advantage of newer features. This lead to a huge amount of fragmentation.

Which brings us to now. Outside of threading, the runtime features are much
more suitable to an app platform now, and finally the web has a native UI
component system in Web Components. I think there's one or two more big shifts
ahead of us toward Web Components and better utilizing Workers, and then
things will settle down because we'll finally all be using the same platform
features. Even if we still have opinionated and helpful layers on top, the
foundation will be more stable and standardized.

~~~
paulddraper
> Growing up from a document viewer to an app platform in the particular way
> it did left the web as the most important and ubiquitous GUI app deployment
> and runtime platform, but without a dev-accessible native GUI component
> system.

Exactly this. Web technologies cannot be understood without understanding the
history of the web itself.

You could just as easily imagine, say (random example), Internet + Gopher +
Lisp playing the role of Internet + HTTP/HTML + JS.

It was somewhat inevitable chain of events, plus "right time, right place"for
particular choices of tech.

~~~
thisrod
> It was somewhat inevitable chain of events

The question that intrigues me is why Tcl/Tk didn't take off around 1995. We
could have had internet apps about a decade before web apps were feasible.

The only answer I can think of is that no one in 1995 would have contemplated
running a Tcl script that their computer had just downloaded from a random
host, but Javascript boiled that frog gradually. I'd be keen to hear other
ideas.

~~~
blacksqr
[https://news.ycombinator.com/item?id=2380044](https://news.ycombinator.com/item?id=2380044)

------
tenaciousDaniel
I was exhausted by front end development, so I thought I'd try something new.
I ended up first looking into AI, and then into Blockchain.

Long story short, I have run back to the relatively calm and serene world of
the front end, with my tail between my legs.

The front end may be moving quickly, but in the grand scheme of larger
technological change, it's far more stable than we give it credit for.

------
patorjk
> What is to be done? ... Consider non-microlib architectures

What about what happened with Angular (1), the 3rd library on your list? That
whole framework was deprecated in favor of Angular (2). Additionally, the list
of front-end libraries given doesn't really reflect the landscape front-end
devs have traversed.

Years ago, I remember working on an app that heavily relied on YUI around the
time that library was shutdown. I also heard stories about how ExtJS 4 wasn't
backwards compatible. I'm not sure I buy into the author's thesis about the
reason for front-end fatigue.

~~~
reitanqild
There's a clear upgrade path (with tooling) between Angular.js and Angular 2,
4, 5, 6. There's now also
[https://update.angular.io/](https://update.angular.io/) to help.

~~~
patorjk
Angular 1.x is not listed in
[https://update.angular.io/](https://update.angular.io/).

Additionally, there was no initial update path between Angular 1 and Angular 2
until the community cried foul. It's been a while, but after they finally
released an Angular 1 to Angular 2 bridge, I read several tutorials and books
that discussed the upgrade path but said to absolutely not use it in
production. It would kill the performance of your app. That sort of made the
value of an Angular 1 to Angular 2 bridge pretty weak. If one were to migrate
to Angular 2, it would seem more time efficient to just to start fresh rather
than spend time on a wonky bridge between the two frameworks.

~~~
reitanqild
At AngularConnect last year I now migration of large applications was a topic
and if you are interested I think it should be available online.

Also: angular.js isn't dead, it is just stabilized. Yes, no more features
(from Google) but it should be safe to use and also I think they signalled
quite clearly that they would be happy to let the community pick it up.

------
rusk
I think the quality standard is different.

Front end has to "look good" and be "good enough to use". Little finnicky
errors are often tolerated as a user can be expected to work around a certain
issues. Since issues can be quickly spotted code hygiene and rigorous software
quality practices aren't as important. Also, performance and resource
utilisation aren't as important, to a degree anyway.

Back-end, unsupervised, or high-performance code on the other hand is largely
invisible to the end user. It has to run for long times without error and if
something goes wrong can be tricky to get at, diagnose, and repair.

These requirements demand a higher level of code-hygene. Coding standards,
logging, documentation, automated testing etc. etc. which makes developing
this kind of code much more expensive than you would expect for something that
you ultimately "can't see" (unless something goes wrong).

I've seen organisations struggle with this dichotomy where they're trying to
do both without appreciating these distinctions. Product managers getting
annoyed that it takes so long to get GUI changes in, while engineers getting
annoyed that their (necessary) tech process overhead often gets shorted
because "it doesn't add value".

You can get away with taking short-cuts on the front-end, that you can't get
away with elsewhere but ultimately this leads to a messy, unwieldy codebase
with mountains of tech-debt and once you get to a certain point it makes sense
to just throw it out and start it again.

Though "starting again" is considered to be something you should never do [0]
with front-end stuff it's a little easier to get away with because, like I say
it's all visual, and a good bit easier to test and play with and tease out the
subtleties.

[0] [https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

~~~
godinaa
I disagree. Rigorous code standards are just as necessary on front-end code as
back-end. In my experience, no code review, poor design or documentation, and
lax standards lead to jittery experiences. For example, people write complex
blocking code that causes the page to freeze for moments while that processing
is happening. People write event handlers that execute too often and slow user
interaction.

~~~
rusk
My point was though, that such issues can be quickly picked up just by _using_
the application, and you can usually elicit the causal factors by prodding at
it. Often times such issues in non-UI code can go for years without it being
noticed.

But broadly speaking yes I agree, but one or two of my line managers in the
past would not.

------
kuon
I work with elm now for frontend. It has often been criticized for being too
conservative and slow paced in its development. But the result is that code is
easier to maintain, libraries have a great quality and most of the time there
is only one, obvious, way of doing something.

~~~
freedomben
Somewhat unrelated, but a couple of questions for you:

1\. How did you learn elm?

2\. Was elm your first functional language? (Not wanting the "javascript is a
functional language" battle here plz)

3\. What is your backend written in? Do you maintain that?

4\. What libraries do you make use of?

5\. Any regrets?

~~~
z5h
I wrote this in Elm: [https://ixberg.com](https://ixberg.com). (feel free to
sign up, use it, share it). I learned Elm by going to an intro course at
Lambdaconf, and watching this
[https://frontendmasters.com/courses/elm/](https://frontendmasters.com/courses/elm/)
and coding in it. Elm was my first PURE functional language. I've done some
Scheme before. Backend is Firebase. No special libraries in particular. No
regrets.

~~~
LandR
Am I missing something on ixberg.com, I can't sign up?

Only have sign in but that is not clickable?

------
0xcolton
Having worked as a frontend dev for a while, my observation is this - because
the UI is closer to the user, and closer to the product side (for consumer-
facing apps), it has faster iteration cycles, doubling or tripling the rate of
technology decisions that are made.

You'd never rewrite an API twice in a year, but maybe you'd rebuild your site
or interface that often, if you're responding to users.

With increased demand for tools comes more supply - more libraries and
frameworks with more stars and follows.

The reason we don't see this in the mobile world is because it's a much more
closed ecosystem - there's no open spec for mobile like there is for browsers.

~~~
dnomad
Yeah, there's a perfect storm that happens on the frontend.

(1) Users are more empowered and expected to continually change requirements
all the time. (2) The underlying technology is broken. Specifically, there is
no _component model_ that makes it easy to compose existing components. Every
frontend app reinvents not just the wheel but the tools to cut the stone. (3)
There is no UI component model provided by the browser. Every webapp looks and
behaves completely different from every other webapp. There are no common
metaphors, common components, common fonts, common icons or even best
practices. Every company writes their own UI kit and interface guidelines. (4)
Thanks to the highly intelligent fuckers at Google/Facebook/Yahoo everybody
has very high expectations when it comes to Web UIs. These guys are also
driving rapid innovation in the space. Unlike Windows apps -- which haven't
changed much in 25 years -- Webapps seem to become dramatically different
every 3-5 years.

The result is the wild west meets post-apocalyptic disaster where everything
is constantly changing and the developers don't have the tools to actually
manage or control this change.

~~~
josephcooney
I agree. Throw into the mix non functional aesthetic changes. Even if the
actual requirements/functionality didn't change new design trends would mean
you'd be at minimum re-skinning/themeing your site/web app every 18 months or
so just so it doesn't look "dated".

------
jonnytran
Yes, no one takes the time to research. Most popular does not equate to good.

I took the time to do the research back in 2013 and found that Ember basically
solves all the problems OP talks about. Tom Dale, one of the creators of
Ember, blogged over a year ago [1] about how Ember has been around since the
days of Backbone. As the years rolled on, other frameworks became obsolete,
but Ember evolved (with sane upgrade paths) and is still relevant.

1: [https://tomdale.net/2017/04/making-the-
jump/](https://tomdale.net/2017/04/making-the-jump/)

------
tzs
There is an interesting take on this by a Reddit user named 'jerf' over on the
Reddit discussion:

[https://www.reddit.com/r/programming/comments/8n00k2/why_is_...](https://www.reddit.com/r/programming/comments/8n00k2/why_is_frontend_development_so_unstable/)

I think this is the same as the HN user 'jerf', but am not certain.

~~~
wvenable
I think I'd add to this comment that you can't solve a lot of these problems
with more code because in the browser code size is a very significant factor.
On the desktop, or even on mobile, code size isn't very important. So we can
have big libraries that do a lot of work.

------
tribby
well, ever since the proliferation of mobile touch devices (it's been less
than a decade) there's been this somewhat perverse history of "mobile-first"
really meaning "native-first." tons of mobile websites are still essentially
ads for their counterparts in app stores. this is for lots of reasons (mostly
to do with financial incentives for both app makers and app stores), but
ultimately the web still isn't as good as native. the chaos of the front-end
world is a reflection of web developers trying to solve that, rather than
those working on operating systems, web browsers, standards, etc.

the other reason is that vue hasn't be around very long ;)

------
andrewstuart
It's unstable because there are millions of developers working with front end
technologies and that community is rapidly finding better ways of doing
things.

And when better ways are found, because development is so time consuming and
difficult, people move to embrace those new and better ways.

I'm glad of the rapid change because there is alot more improvement needed at
the front end.

Consider for example the vast amount of crushingly complex configuration that
is required for many front end development tasks - this is yet to be
addressed, although giant leaps have been made - such as create-react-app -
thank god.

JavaScript has to become "zero configuration" to the greatest extent
practical, and JavaScript programmer should dump configuration heavy tools as
soon as they possibly can for zero configuration tools.

~~~
rimliu
s/better/different/

Compared to how much code size and complexity for the tooling increased the
benefits for the end user are tiny, if there are any at all. We are just
getting SPAs which do not work with JS off where a simple static page would do
perfectly.

------
chauhankiran
I know that the star is a de-facto way to calculate the popularity of
particular repo. But, let me put aside this calculation for a moment, then I
myself have stats around 250 repos and more than 40% of it, I have starred
just because to refer it sometime later, not because I like it or love it,
just for future ref., when I have to work on something that might need help or
ref. from that particular repo.

So, if there is something that have a way bookmarks the repo then chances are
hight these repos have lesser stars. Also, there is popular trend nowadays I
see that 100 other developers have starred one repo for some particular reason
that chances are hight that other 5 developers might star it because they just
follow the developer, who have starred.

------
EvanYou
FWIW, the GitHub age isn't entirely accurate because both React and Vue had
major rewrites and the current default branch doesn't hold the entire
development history. Vue's first public release was Feb of 2014 and React is
just celebrating its 5th birthday.

~~~
evilduck
Likewise, Ember holds the record on that list at 6.5 years, it was forked from
SproutCore which goes back even further.

~~~
k__
Wasn't it just renamed from SproutCore?

~~~
evilduck
My point was that Ember is older than the repo age indicates.

“Forking” vs “renaming a project and creating a new repo” sounds an awful lot
like the same thing to me anyways.

------
freedomben
I do wonder how much of the instability relates to the strong opinions that
the JS community often has (I'm guilty of this too). Any broad stereotype is
going to be wrong a lot, but it does feel like JS devs on average are a lot
more opinionated about the way things ought to be. They are also more
disgusted and unhappy working in codebases that don't conform to their
standards.

I truly don't mean this as a bad thing, in fact I put myself in this category.
Obviously it _can_ be a bad thing if it causes you to be unable to work with
others, but it can also make for elegant, consistent, and hackable codebases
that boost productivity and minimize bugs.

------
carapace
Programming industry is the only one more fashion-driven than the fashion
industry. This is a known issue going back to the dawn time.

The big secret is that for most of us this is "works as intended". We _like_
to program. Imagine being a mountain climber who loves climbing and gets paid
(well!) to climb mountains. With real mountains, eventually you get to the top
and you have to stop. With programming, the act of climbing the mountain
creates more mountain above you. As long as you can find people to pay for it,
you can keep climbing.

If you like programming please shoosh so the marks don't get wise.

If you just want to get shit done use Elm-lang and get on with your life.

~~~
reitanqild
The first part of your post is brilliant and then comes this:

> If you just want to get shit done use Elm-lang and get on with your life.

If this was sarcasm it would make sense but there's little else in the post to
suggest that.

Elm is one of the hippest languages right now. It also depends on a single
maintainer AFAIK, and also has a limited community.

I'd also like to program Elm but suggesting to move to that from React or
Angular? I'll leave that to my 10 years younger self.

A better description might be: use whatever you know and try to keep code on
the server side as long as possible.

~~~
carapace
I hasten to point out that that "fashion-driven" line is somebody else's. The
internet says RMS or Larry Ellison.

My point about Elm isn't that it's the silver bullet, rather that it's a tool
that makes the meta-game easier.

------
Achshar
I always find it curious that almost no one is talking about not using a
framework to begin with. I have been writing complex UI with vanilla js for
some time now, never had any issues or took longer than I expected to get a
job done.

~~~
burakemir
You have to ask yourself whether, in the process of building that complex UI,
you haven't invented another framework.

After the first few web apps, one necessarily sees the repetitive elements and
wants to capture that in libraries and abstractions. Routing URLs? Reuse that
widget? This is just coding instinct.

I think it is possible to have a stream of projects where each new one gets
its framework copied and pasted from the previous. That does not mean it's not
a framework, just one without name and documentation.

Then there are projects of a certain size that you wouldn't want to do like
this. Stakes too high, more than 1-2 developers. Then you can either brush up
your framework and give it a name and documentation and contribute to the
'problem' of too many frameworks.

Or use something that others use and is just as suitable.

------
hajile
The real complaint right now should be Babel v7 -- or more specifically, the
community around it. Babel v7 has been in development for quite a while. It's
still changing and isn't even a RC yet.

I understand the need to test new compiler builds, but production isn't the
place to do that (especially not until a RC is released). A beta designation
is meaningless if its used as though it were just a normal production release.

Using a beta compiler in production tools, libraries, etc shows EXTREME
inexperience. I have a number of dependencies that I cannot update because the
new versions rely on various v7 builds (ranging from ancient alphas to
bleeding edge betas).

I suspect the issue is that most JS dev teams are small with projects small
enough that edge cases are uncommon and easier to find and fix.

Stackoverflow dev survey shows that the average US dev is 28.7 (down from 31.6
in 2015) with an average of 10 years of experience despite 58% having less
than 5 years of experience.

That means that on average, you have a very young team. Further, the vast
majority of teams most likely do not have ANYONE with more than 5 years behind
them. It's not surprising that such things aren't recognized for the disaster-
in-the-making that they are.

Web technologies have settled down and stabilized dramatically over the past 3
years. I suspect that as more web devs gain more experience, we'll see this
continue as rashness is replaced with a more conservative approach.

------
player2121
To me this attributes more towards general evolution of the browsers which
naturally leads to more complex requirements for the modern web-app. I
remember that in 2010, when we started re-writing our desktop apps during our
transition to web, the initial requirements were such that it was still
possible (although very hacky) to use the latest version of ASP.NET. Then 6
months later we received a new set of requirements which rendered this
_latest_ stack useless. We literally had people sleeping under the desks
pulling all-nighters trying to transfer a session state between browser and
server without dropping an egg. That's was around time when backbone.js came
out.

If we compare the things that browsers can do _now_ with what was possible 5y
or 10y ago, no wonder why we have so many new frameworks. Browsers are trying
to catch up with (or even replace) an OS as a main container for running an
application and because it's hard to release all features _at once_ without
agreeing on standards, we have a situation when people have to choose a new
library each time a new major API/feature is available. And this what I see is
the main reason why `front-end development is so unstable`

WebAsm is coming which will again lead to yet another huge re-write.

------
api
Three reasons I think:

(1) The closer you get to the front end (especially GUIs), the further you get
from algorithms and other mathematical certainties and the closer you get to
something that's more a matter of design and fashion. People get tired of GUIs
looking and feeling a certain way and they change, and that often requires a
code re-work because changes in GUI look and feel can break previous
abstractions.

(2) Form factors and display technologies change. Mobile completely
annihilated 30 years of GUI work for example. To a lesser extent high-DPI
screens have done a number on some older GUI systems. The stuff under the hood
changes too but more slowly and in less fundamental ways e.g. an SSD is mostly
a "disk" from an abstraction point of view even though the tech is wildly
different. Command lines are fundamentally unchanged since the 1970s. VT
emulations have become more advanced but the basic paradigm is incredibly
stable.

(3) GUIs look deceptively easy but in reality they're incredibly hard. A
modern GUI layer is at the same level of complexity as a modern game engine
like Unreal. The list of edge cases and layouts and modes and languages and
interaction metaphors and input devices and so on and so on you have to
support is very long. Software engineers routinely underestimate this
difficulty and try to re-invent GUIs and GUI abstractions in a quest to be
clean and small and simple. They're then forced to shoehorn everything a
modern GUI requires into these clean and simple abstractions, breaking them
and turning them into overloaded monstrosities. Simple clean systems get ugly
when you try to extend them too far. A more elegant design could be achieved
by starting with the premise that the problem is big and hairy and developing
heavier and more flexible abstractions accordingly.

------
throw2016
There are a set of converging interests causing pain in the ecosystem. First a
company promoting a project, then people hoping to provide services,
consulting or training, and third people hoping to get a job or padding their
current resumes.

None of these people have a particular interest in the technology or its
merit, its anything they can make money or benefit from and then forums like
HN and others are used to aggressively push out these technologies.

By the time people start catching on about flaws, over-engineering or needless
complexity the latter 2 groups have already moved on to something new. Rinse
and repeat and HN is very much a part of this.

There is very little tolerance for skepticism and proper scrutiny of anything
'new' and in the hype train. These are usually dismissed with ad hominems
about 'grey beards' or people 'scared' of change. Since everything is so 'new
and cutting edge' there is no respect for any authority or experience and
scrutiny becomes impossible. And since self interest is involved the arguments
become needlessly charged.

~~~
mmt
I assume that observation applies to more than just front-end development. At
least I've personally seen the effect more generally.

I think another self-interested actor is the "nobody ever got fired for buying
IBM" manager, except that, today, it's not IBM. IBM has, of course, been
replaced by whichever technology is currently in high repute. They need never
gain technical knowledge themselves.

Granted, in some cases, that's actually a case of legitimate delegation to
their engineers (whose conflicting interests you've addressed), but, since
they have the same access to the Internet as everyone else, that can't be
assumed.

> And since self interest is involved the arguments become needlessly charged.

I hadn't _fully_ considered that until now.

That isn't to say that I'm not a cynic, but, rather, that, for example, the
average HN commenter may not want to come to terms with having, even to a
slight degree, such self interest. That can lead a form of needlessly charged
argument, defensiveness, that wouldn't necessarily be obvious otherwise.

In a professional setting, it can lead to seemingly-irrational decisions in
the face of overwhelming evidence that the other way is better.

------
chrisco255
I think this is a piece by someone who has not really been in front end web
development as a career (or does not specialize in it) for very many years.
The author's thesis is that 'poor choice architecture' is what drives churn in
front end. I disagree. The churn in JS tech has reduced over the past few
years.

Some of the churn was in part due to limitations of the web platform. ES5 was
limited in features. The web has evolved a lot, and now we don't need to
depend on every framework re-inventing things like modules.

React has been around for 5 years now, and it's still the dominant choice for
front end architecture. This is not by accident. React solves some of the
biggest challenges in front end development with a clean, minimalistic
component API, a virtual DOM abstraction to minimize re-renders, JSX (still
superior to underpowered template languages), and one-way data flow (which
makes refactoring and state management easier). Also functional component
model has implications that it can render to any target.

React is not just a web development innovation, it's a UI innovation. There
has never been a desktop UI framework with this much flexibility and power.
You can target web, native mobile, native desktop, create custom canvas-
rendering if you like, render to touch bar, VR, etc...no limits.

The author sort of implies that a one-size-fits-all framework or some standard
way of doing things across all projects would lead to less frustration and
less churn in the JS community.

We've seen many attempts at this (Ember, Angular, etc). The thing is, not all
projects have the same needs. The web is a big place. There are simple web
pages with mostly text content (and little need for JS) all the way to rich
apps with interactive video, real time chat, dynamic graphs and complex
customized data feeds for each user. There is no one-size-fits-all
comprehensive framework that will ever meet those demands. For the easy
projects, they're overkill and for the complex, long-lived projects, you're
likely to beat your head against the limitations of the framework.

The innovation that has come in state management, style management, and
component-based design in the past few years is unrivaled by any other UI
community. I think the article is a surface level grasp at the situation. It
implies that the JS community is spinning its wheels instead of producing
solid long-lasting paradigms for application development. I disagree.

~~~
_Tev
It nicely shows HN bias when comment like this is downvoted into oblivion. "JS
framework churn" is a thing of the past _, with only a few I-hate-JS types
trying to keep it alive.

_ and I'm not sure it even applied to people actually working with JS even in
the past.

------
baybal2
>Why is Front-End Development So Unstable?

Because on average, the skill level in the whole webdev community is low.
Below that of "a dev with average schooling, and average industry experience"

Webdev has close to no barriers for entry, and is under the strongest
influence from the fact that the evaluation of deliverables is not done by
another tech professional out of all software development jobs

The combo above makes things that are unheard of in other software development
niches possible, like meeting borderline or de-facto frauds running webdev
businesses selling "ultrasophisticated" corporate websites on Wordpress to
F500 types for few $k USD per hour of dev time, or well entrenched in-house
"developers" in tech giants who made it to six digits on technobabling to non-
tech managers and copy and paste.

All of this is evidently projecting onto to the tech solutions used in the
trade, and the popular image of the webdev development process. And over the
time, popular stereotypes are becoming self fulfilling prophesies: Angular -
was an okish framework at near 1.0, but marketing messaging made it look like
an "enterprise stuff," and their devs eventually turned it into it -
purposelessly overengineered monster filled with SOAisms; jQuery - got bad
fame for unusable, animation rich websites made by least talented part of the
dev community, and this infamity has both sealed its further development, and
was responsible for attracting even more unskilled devs into making websites
with crawling slow animation;

And like this for few pages, as well as for the notion of webdev world being
"unstable." Many people here who are not novices to webdev can probably call
few sites that had a "single piece of JS code continuously maintained over 10
years" or more. I myself knew people who were making yandex.ru homepage in
nineties, they say that a very sophisticated ajax autocomplete code there was
developed and maintained continuously since 2004

~~~
PrimHelios
>Webdev has close to no barriers for entry

How does something like regular desktop development have any more barriers? I
picked up Python at 14 and that had absolutely no barriers for entry other
than installing IDLE on a laptop. If anything, webdev has more barriers for
entry because you need a webserver and a backend of some kind.

~~~
baybal2
>I picked up Python at 14 and that had absolutely no barriers for entry other
than installing IDLE on a laptop.

Will you ever be employed by a "serious company" to make commercial desktop
software just for few demos you show from your laptop?

~~~
PrimHelios
I set up an entire flask dev environment with one pip command, too. Still no
real barrier to entry, at least not any more than front-end development.

~~~
baybal2
I would say: 1 loose portfolio of demos without any history of signed off
successful projects will still be getting you a decent job in webdev, but for
sure not in commercial desktop software industry

~~~
PrimHelios
Ah, I see what you mean. I can't really comment any further as I don't know
what it takes to get hired as a webdev, but I'll take your word for it.

------
augbog
> Before we get carried away, it’s worth validating whether the meme really
> has basis in reality. Do front end technologies actually change that
> quickly?

> In the sense of major view technologies, probably not. Consider this list of
> the highest ‘starred’ JavaScript front-end technologies on Github:

Seriously? So you're basing front end technology changes based on stars on
Github?

Also I think it's wrong to say that front end technologies have "changed."
It's just people have discovered better or just different ways of building
things and that should be okay.

I agree with the portion how it can be overwhelming to a junior developer, but
it is also easier in some ways. In truth, if you are a junior developer (or
hell any developer really), your focus should be less on choosing the right
technology and more on understanding what technologies fit what needs.

~~~
Cthulhu_
I think the stars were mainly to get some kind of data, given how it's hard to
get real live data.

The article itself resonates with a non-data-powered feeling I've had for
years. The front-end change meme is from a few years ago, during the highly
unstable period shortly after Angular and (with it) single-page applications
rose up, then suddenly Angular 2 was announced (which made everyone feel like
their investment and commitment to Angular 1 was a wasted effort), React
climbed up and got a few alternative implementations, React state management
got a couple of alternatives (and a lot of thought went into those; I see that
era as more of a philosophical era), and there was some drama on both the
Angular and React side, causing people to split off and do things like create
a new programming languages (Atscript), Angular the good parts (Aurelia), and
(a bit late to the party), Vue.

------
tw1010
"Unstable", "Issue", "Problem". The opposite of the front-end world is not
something to desire. Change means people are fixing problems and giving away
their solutions for free. To desire less change means wishing fewer people
gave away their work.

~~~
tiberius1900
Change is not necessary a good thing. Bad change is worse then no change at
all. However, when it comes to programming frameworks, rapid, unstable, change
is generally not very desirable. Take a look at the most popular open-source
OS/kernel in the world: Linux.

It's a Unix-clone using a monolithic kernel made in a time when Lisp machines
existed and microkernels were all the rage. It used ANSI C which, to be fair,
was new at the time, but stuck with it, in the face of C99 and C++.

And, as a windowing system, it still uses X11, a system designed in the mid
'80s. There has been a very slow migration towards Wayland (which is now
already 10 years old).

As it's scripting language it uses bash (1989), which inherits a lot of it's
characteristics from the Bourne shell (1977).

Yes, in the case of Linux may be a little bit biased as OS development back
than was still more mature than front-end is now, but still, the principle
still holds: "slow and steady wins the race".

------
elcapitan
The article is right about the frontend side, but I think it doesn't look to
good on the backend either. The actual code side (frameworks, libraries and
languages) is relatively stable, but mostly because most of the complexity
nowadays goes away from monoliths and into services, of which many are off the
shelf, and plagued with the same issues as all the trendy javascript
frameworks. Nosql-database du jour that solves some problems allegedly very
efficiently, messaging systems, thousand ways to script infrastructure and
virtualization.. the hype is not in the code and libraries, it's in the
infrastructure components, but that doesn't make it any better.

------
tracker1
I do find a bit of the argument hyperbolic... My preference today is Koa +
about 3-5 modules (including 1-2 custom) on the backend and React, Redux,
Redux-thunks, redux-first-router and fetch (in most browsers) on the front
end. For UI, will generally suggest bootstrap or material-ui (the library).
create-react-app does take a lot of the guesswork out of the front-end.

In the end, front/back-end tech grows at an incredible pace. Look at go, rust,
.Net Core and a half dozen other options that sprung up in the past 6-8 years
and all the frameworks around them. It isn't new. Last generation(s) it was
Python, Ruby, C#, Java and on, and on... this isn't new.

------
kehrlann
I believe classifying libs/frameworks by number of stars is not enough ;
"when" these frameworks got stars, or how many stars they got in the past 6
month, is probably important. Not sure jQuery or angular 1 got many stars
lately...

~~~
Blackstone4
Agreed. The quality of the stars are important. What percentage of people star
repo's where they've read the Readme but never used the code or used the code
and decided it was bad quality and never unstarred the repo

------
rb808
This problem is way deeper than web front ends. There were/are dozens of
frameworks for Windows and Unix front ends too, before browsers were invented.
Every year or two some new tool became popular which made all the previous
ones obsolete.

~~~
gaius
Not really. On Unix it was Motif vs OpenLook. On Windows it was MFC vs OWL. On
Mac it was PowerPlant vs MacApp. And that was it really, and you could have
stuck with one for over a decade and never been short of work.

------
PaulHoule
Is there a difference between "Medium" and "Self Promotion"?

~~~
seattle_spring
I tried barking up that tree a year or 2 ago when Medium took over HN.

~~~
PaulHoule
I built a system for filtering my HN feed and one of the first rules I put in
was "no links to sites that have pop-ins" and tedium matched that. (Not like I
have an automated way to do that but it is not too hard to add sites like that
to a block list.)

------
rossdavidh
I give the author credit for thoughtfully trying, but not much of this seems
to actually explain why it is Javascript that has this problem, more than
Python or Ruby or Java or C#. The reason for Javascript's excessive churn
must, I think, be related to its most typical use case as a browser client-
side language, and in particular to its use in single-page apps. The rest of
it are all good points, but I'm not sure they explain why Python, etc. don't
have this problem (as bad, anyway).

------
brillout
OP mentions using a framework.

Alternatively to Next there is Reframe
([https://github.com/reframejs/reframe](https://github.com/reframejs/reframe))

My main problems with Next is that it is

\- not ejectable (and locks you in),

\- not a universal framework (you cannot create an app that has a static
`/about` page but a dynamic `/search` page. With Next your app is either all
static or all dynamic.)

(I'm Reframe's author.)

------
tlrobinson
So here’s the thing... browsers are generally excellent at maintaining
backwards compatibility (see “SmooshGate” for christsake). Old frontend
frameworks still work just fine, therefore when you complain about frontend
development be “unstable” you’re complaining about other people creating or
adopting new frameworks/tools. If these things really aren’t worth learning
you are free to continue using the old ones.

~~~
emodendroket
Well, you aren't really, because you have to work with other people who want
the latest and greatest.

------
piinbinary
This offers a good explanation for why the most popular options are generally
the ones that developers choose, but not why the thing that is currently
popular shifts as fast as it does.

Why did React take the limelight while Angular fell out of favor? What caused
that shift in what is popular?

~~~
kearneyandy
My personal experience with this was that Angular 2 was announced, which was
completely non backwards compatible. So there were a bunch of people that

1) Needed to rewrite their code

2) Distrusted Angular to be stable

React had a philosophy of small reusable components and incremental upgrade.
This is a particularly attractive idea for people experiencing the above. I
think this is probably part of the shift in popularity.

------
Yaggo
Front-end is the ultimate incarnation of Bazaar model.

------
nunez
Because web browsers are so different, there are millions of ways of getting
around it and most devs would rather make their own solutions

------
mseebach
> Put yourself in the shoes of a junior-to-mid-level JavaScript developer,
> writing a new application for the first time.

> But how could you do better, Junior Developer? Who was there to guide you?
> The Senior Developers, too, are learning as they go. We’re caught in this
> avalanche too, just trying to keep up to date and remain employable.

No, this is exactly the problem: junior developers making major architecture
decisions unassisted. The "senior" developer who is "caught in the avalanche"
isn't senior by any reasonable definition of the word.

Development in general, and, it seems, front end web development in
particular, is both easy and hard. Somewhere between batteries-included
frameworks, blogs, YouTube channels and MOOCs, it's very easy to get from zero
to something good looking and more or less functional pretty quickly. But this
can easily hide the complexity that pretty quickly creeps in, and reasoning
about complexity is one of the crucial things that a senior developer brings
to the table.

~~~
jillav
Yes exactly. Building something fast without understanding the complexity
behind can be both a blessing and a curse.

It's a blessing for the one who needs to deliver. It's a curse for the one who
needs to learn.

To be efficient in the long term, and not get lost among the framework wars,
one must use what was learned in Engineering School, University or from
seniors : write specs, set priorities, plan ahead. Use or build the tool that
suits your need, do not follow trends.

Think like an engineer.

------
zmix
The short answer is: Because they abandoned XML on the web.

------
zer00eyz
I think the instability is a byproduct of what it is.

Today we have [https://caniuse.com](https://caniuse.com) but this sort of tool
in one form or another has existed for a long time - I think that mobile, and
native mobile have only compounded the problem.

Frameworks, and ecosystems (Node, and what it spawned) are practically a
requirement to get things done. But abstracting issues away from front end
developers, hiding them behind hacks and fixes only serves to make things
worse, and harder.

The foundation of the front end isn't just broken, it is a fuckstorm... and we
keep piling more stuff on top of that foundation trying to make it make sense,
make it rational. With each layer we add creating new sets of issues that only
get worse over time. Then someone "smart" enough to build something a bit
better does just that, and we get this:
[https://xkcd.com/927/](https://xkcd.com/927/)

The reality is that the fish stinks from the head and in this case, blame
google, apple, MS, and Firefox - [https://medium.com/@dmitriid/ok-w3c-and-
whatwg-dont-die-but-...](https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-
die-but-7952221fcbe4)

Javascript isn't much better [https://ariya.io/2014/05/the-curious-case-of-
javascript-nan](https://ariya.io/2014/05/the-curious-case-of-javascript-nan)
\---

(Note the above links are just my favorite "examples" of these issues not even
a good indicator of the real problems therein, everyone has their own
grievances)

And this IS the heart of the issue. Any one sane, any one with a high level of
skill isn't going to want to work in an environment where they aren't in
control where someone can yank the carpet out from under them at any given
moment. No one is going to stay long when new browsers and missing packages
create more work, or work that has to be re-done to deal with some edge case
or issue that literally came out of nowhere. Front end people see those of us
working on server side code where we have a HIGH degree of control (orders of
magnitude) and realize how bad it is for themselves. Simply put any one who is
good invests the time and energy to get OUT of that line of work. Tallent will
quickly migrate away from the broken foundation of the front end. This only
serves to exacerbate the situation, as a new "smart" person onboards thinking
"I can do this better" and being right to some degree.

------
linhuiwu
because browsers changes a lot.

~~~
_greim_
This here is the actual reason. Medium posts and micro-libs are fringe factors
by comparison.

------
_ZeD_
for the same reason of the eternal september

------
softwarefounder
It's only unstable if you drink the JavaScript cool-aid, and change frameworks
frequently.

I've been using Knockout 3.* for the past five years, no issue here.

Edit: Looks like some Angular and React devs have started downvoting :)

~~~
zo1
Knockout is incredibly lightweight and easy to get into. However, it's not the
"in" framework like Angular and kin, so it gets a lot of bad reactions.

The biggest reason for this, I believe, separate to any technical
benefits/advantages, is that the "big" and "in" frameworks have a gigantic
knowledge-base hosted on the entire internet. Because of the sheer amount of
people on that ship, they've all collectively encountered and
tried/solved/figured-out a large amount of usages and combinations of the
library. What that means is that mediocre and/or "shallow"-knowledged
developers can easily leverage that to solve problems they might encounter by
copy-pasting solutions. Rather than solving it for themselves.

Now, that doesn't necessarily mean they're not capable of doing it, it simply
means that they have to spend more time figuring out the problem and/or
learning the framework in order to be able to do so. Most people would rather
opt out to doing a quick search, copy-pasting, adapting to their specific
context, and moving along to the next problem. So, when they have to deal with
something like KO, they know what it's going to entail: Hours of learning, or
digging into internals and figuring out the quirks of the framework.

------
fealios
React is only 3 years old?!?!

~~~
seattle_spring
No... It was release in March of 2013, making it more than 5 years old.

------
beders
It's because we keep trying to use something designed for displaying hypertext
documents as platform for interactive applications. It's dumb and successful.

