
Ask HN: Why does front-end development change so often? - RyanShook
All technology moves quickly but front-end development evolves at a whole different level. What is popular one year is “old” the next and often a totally different menthodology. Why do you think front-end development is in such a constant state of change?
======
thomasmeeks
I think there are a few different factors at play:

1\. Javascript has a massive and diverse community. Developers that would
otherwise avoid the language must learn to use it. So, where other languages
would rally around one framework (because of the self-selection), Javascript
rallies into sub-communities around methodologies and architectures.

2\. Javascript is gaining new developers at a very high rate. All these new
minds bring new ideas, new combinations of ideas, and lots of re-invented
ideas too. All of it, even revisiting old ideas, pushes the collective
industry in new directions.

3\. Frontend developers have had to layer on top of a set of tools barely
adequate for what we're trying to accomplish. For example, jQuery should never
have been necessary, but was revolutionary when it came out. Today there's
still not great solutions around storage, security, performance, etc. Solving
these problems improve the abstraction and allow higher-level frameworks to
appear.

4\. Based on what I've seen there appear to be very few UI toolkits that
aren't kind of garbage. Human interaction and rendering pretty bits is hard.
Generally I think the industry (even outside webdev) is still looking for the
"right answer" to the problem.

~~~
MuffinFlavored
Is it in your mind/words harder than backend development?

~~~
bobthepanda
I feel that frontend has a lot more quirks than backend development has simply
because of how hard it is to get UX right. Browsers are a lot better these
days about standards but there is still inconsistency, especially if you want
to target certain segments of the population like IE or Safari. Accessibility
has general guidelines but YMMV with different screenreaders. And developers
are not in the position to ask users to switch to a preferred compatible
system just for their special snowflake shopping site or gig economy startup
or CRUD app.

------
d--b
Because UI is hard and people think they can come up with some framework to
"fix it".

UI is inherently complex. The relationships between views, states, data and
events blows up very quickly, and inevitably lead to code that gets messy. So
people come up with frameworks to organize code and auto-generate some stuff.
But then complexity doesn't really go away, so frameworks also get messy, and
people come up with more frameworks.

Does it get easier overtime? Probably a little bit. But overall there is no
silver bullet.

That said, the concepts are not different. Once you understand where the mess
comes from and what the next framework is trying to "fix", things become a lot
clearer, and you don't really have to learn much of anything to be able to use
the newer stuff.

EDIT: also in javascript, it's very easy to roll out "frameworks". In other
languages, UI libraries are deeply connected to the lower-levels of the
operating systems. On the web, you just make a library that manipulates the
DOM and CSSs, and everything else is done for you by the browser. It's much
easier.

~~~
jb3689
> also in javascript, it's very easy to roll out "frameworks"

Also worth mentioning that the switching costs for changing frameworks in JS
is incredibly low. You can just load different JS files and presto - you can
use a new framework. No servers to setup or anything like that

------
laser
To push back a little against this notion—is this even true? On the web front-
end, I develop with React and Vue, which were released in 2013 and 2014
respectively. On the backend, I primarily use Phoenix, which was released in
2015. On the iOS front-end, I write apps in Swift, which was released in 2014.
For our ML, practically nothing we use existed three years ago (except
underlying layers, like language and below). That being said, you don't have
to use the newer technologies if you don't want to. People use them because
they offer advantages over the older technologies (generally), whether that be
in development effort saved or performance and features. You can still build
your web front-ends in jQuery, your backends in php or asp.net, and your iOS
apps in objective-c. I hear the notion fairly often that web front-end
development evolves more quickly, but I'm not sure that it's even true.

~~~
quanticle
It's been true in my experience. I've had interviewers scoff at me for
mentioning Bower and Grunt, saying that the latest best practice was Webpack.
Is Webpack really better than Bower and Grunt? It's different, that's for
sure.

I get the feeling that a lot of the web development community has trouble
understanding the difference between different and better. That's why we see
so many wheels get reinvented so often. Is React a _better_ way of
manipulating the DOM than, say, Angular? I don't know the answer to that. It
certainly is a _different_ way. Is Webpack _better_ at combining and packaging
code than Grunt and Gulp? It's a different way of of packaging code.

In other communities, there's a much more nuanced discussion of whether
technologies are appropriate. In the web development community, there's a much
greater emphasis on painting technologies as absolutely "good" or "bad",
"current" or "obsolete", without the suggestion that this new technology can
coexist alongside existing technologies and address new use cases that the
existing technologies didn't address. I've heard of numerous (and participated
in two) projects which migrated from an existing framework (such as Angular,
Ember, or Knockout) to React, solely because React was newer. There was no
consideration whether React was a more appropriate framework for the task at
hand. There was little consideration of the costs of the transition. It was a
knee-jerk decision. "This framework is old, and the code written in it is
nasty and buggy. We need to "refactor" (read: rewrite) our code to use React
so that we can be current with the state-of-the-art best practices in web
development."

I compare this with, for example, the Python community, where there is much
more of a detente between frameworks like Django and Flask. Even though Flask
is newer, there wasn't ever really a question of Flask replacing Django. Flask
was merely seen as a solution for cases you'd have to strip out of a lot of
Django (like its ORM and much of its middleware) in order to get a simple
interactive website up and running quickly. There wasn't nearly as much of a
push to use Flask because it was merely newer.

~~~
ng12
> I get the feeling that a lot of the web development community has trouble
> understanding the difference between different and better

I think you're confusing the HN community with the web dev community :)
Everything I picked I picked because it was better for a specific reason.
React solved the problems I was having with writing reusable code. Webpack
takes all the grunt-work out of Grunt. TypeScript purely for the ease of
refactoring.

> I've heard of numerous (and participated in two) projects which migrated
> from an existing framework (such as Angular, Ember, or Knockout) to React,
> solely because React was newer.

You can do this with any project The reason these choices exist is because
lots of very smart people are thinking very hard about ways to do things
better -- it's naive to think there's no merit to them because some people you
happen to know are making poorly informed decisions.

~~~
quanticle
>The reason these choices exist is because lots of very smart people are
thinking very hard about ways to do things better

Well, that's one way of thinking about it. Another way of thinking about is
that it's a lot easier to gain recognition and mindshare for releasing a new
framework than there is in refactoring or implementing improvements upon an
existing framework. This incentive structure applies at both the corporate and
individual level.

I've found, from my experience working at large tech companies, that many
frameworks get started because a senior engineer wants a demonstrable
_project_ to demonstrate their leadership and technical skills in order to get
a raise or a promotion. A new framework is definitely a high-impact project
with a very clear deliverable and a well-defined set of requirements. So they
make a new framework and then market the absolute daylights out of it, since
one of their goals isn't just to create a new framework, but also to
demonstrate some level of adoption for it. So the framework is pitched as the
next big thing, which makes all existing frameworks obsolete.

Scale this motivation and approach up to the level of corporations rather than
individuals, and you have the modern web development ecosystems. Corporations
want goodwill and mindshare, and they know that one of the ways to get that is
to release a framework that everyone uses.

~~~
ng12
That's a nice theory but I think it's wrong. Can you provide an example of a
framework that should have been an incremental improvement (or not written at
all?).

The only possible example I can think of is React vs. Vue, but even then
there's a pretty fundamental differentiating factor which is that Vue is
lightweight (e.g. easier to drop in to an existing non-Vue project).

~~~
quanticle
React. Vue. Angular 2. Meteor. Vulcan.

Do any of these frameworks actually solve problems that weren't being solved
before? Did rewriting Angular 1 in Typescript really improve things for the
user?

~~~
ng12
> Do any of these frameworks actually solve problems that weren't being solved
> before?

Yes. React solved two big problems in the front-end space: building re-usable
components as a first order concern and moving away from the imperative DOM.
As mentioned, Vue is arguably pretty similar except with some concretely
different goals.

Angular 1 -> 2 was not about just Typescript, it was a large-scale refactoring
to move away from some of the more imperative aspects towards a more
component-based architecture which incorporates some of the advances made
since Angular 1 was introduced.

Vulcan's a framework which uses React and Meteor is it's own separate thing so
I'm not sure what you're trying to identify here.

------
SomeHacker44
I avoid this "rat race." I have been building extraordinarily fast page per
click apps in Java (and now Clojure, at one point Play/Scala) for over two
decades. My usual front end is largely static but if I need a little dynamic I
now add a touch of Vue or some websockets if push is needed. Minimal but
custom JS.

On a decent connection it is rare for full click to rendered time to be over
80ms, and usually much faster.

I think too many engineers think too much has to be done on the browser side.
It just isn't true, for the vast majority of cases, in my experience.

Of course, I have built an array of "modern" framework heavy front end apps,
and back ends for native mobile apps, but I always start things simple and
page per click. It gets the job done and is wicked fast.

~~~
pryelluw
Same here, except with Python/Django. If performance is an issue, then I'll
pre-render as much as possible and serve from elastic or other k/v db. A small
amount of JS (really small) can handle any dynamic portion.

------
furi
The web environment was never intentionally designed to be what it has become
(a system for drawing fully featured user interfaces and even games) and so
isn't really equipped for it, you could argue it's missing a lot of widget
primitives, the view-updates-as-string-manipulation is archaic to put it
kindly and the whole thing is untyped and shackled to a weak language without
so much as a proper this keyword.

This environment is simultaneously so restrictive (in that you can't really
introduce new languages except by having them transpile to JavaScript) and so
bad that people end up trying to tie it into something more cohesive (React's
virtual DOM, Typescript) and then only partly succeeding (React's dependence
on setState and things often being much easier to do with
document.getElementById than in the React way, Typescript's inability to
handle libraries intended for the web), leading other people to try do it
better.

~~~
ng12
> Typescript's inability to handle libraries intended for the web

Can you elaborate? TypeScript is incredibly popular for client-side
development.

~~~
furi
Maybe I missed something, but my experience was that Typescript was capable of
making useful conclusions (i.e. MyLibrary.MyType.width exists, but
MyLibrary.MyType.dog does not) about other libraries, delivered to it via NPM,
that were also written in Typescript. If your libraries were written in
JavaScript to be run in the browser you were stuck doing `declare var
mylibrary: any;` and writing "unsafe" code. This is also true of any global
variables/functions/etc. that exist in <script> tags in your HTML.

To be clear I don't expect it to be able to do this, reading JavaScript that
was written without types and deciding what the types are sounds more or less
impossible, it's just a demonstration of how you tend to end up with an
imperfect solution as a result of the decisions made early on in the web's
development.

~~~
jelgt2011
Typescript allows you to essentially write a typed API interface for your
library (instead of rewriting your entire library in typescript), but support
is fairly spotty.

------
markmiro
I think there are several reasons for this:

* The APIs for building web UIs are really hairy and difficult to understand. * The fact that the web is a standard and quick way of getting apps to people means lots of people are heavily invested in it. * There's still a disconnect between developers and designers. This means many libraries seem to be developed around recognizing past patterns rather than a forward-looking vision. At least that's my guess. * Other human things such as the desire for recognition, users taking any level of UI polish for granted and expecting more over the years, and so on. * The surface area of features exposed on the frontend is enormous. You have forms, arbitrary shapes, layout, color, state management, querying external data sources, and so on.

You combine the above and you get massive technology churn. Maybe people
underestimate the complexity involved.

I get the frustration though because at the end of the day we're still pushing
pixels onto the screen. Even a lot of the primitives haven't changed in a
while. We still have our colored boxes and text arranged in some
configuration. You might expect all the good ideas to have been tried already.

------
Maro
I think it's because all the relevant dimensions are so vast:

\- devices: desktops/laptops, smart phones/dumbphones, lynx, curl, uncountable
browsers

\- programming languages / paradigms: in the end it's all HTML/CSS/JS, but
there's lots of ways to generate these

\- in whatever PL you selected, a bewildering array of libraries

\- open source and commercial offerings

\- small single site pages to things like MSDN

\- public facing pages to large internal legacy intranets

\- use-cases, from wikipedia to youtube

\- running in a browser vs in a container like the spotify app

\- languages (like english vs german), so unicode etc. issues

\- vast amount of developers doing the work, with very different backgrounds

To the degree things works, it's small wonder really :)

~~~
RyanShook
That’s a good point. Lots of fragmentation leads to lots of different
approaches to similar challenges.

I had always thought of the top-down development of Windows and Mac as a
negative but now see the benefits because it forced developers to get behind
tools and technologies.

------
juddlyon
There are some excellent answers here. An additional (if not unpleasant) one
is that there are a lot trendy devs who like to treat new technology like
fashion. If you're not up on the latest, you're not one of the cool kids. It's
a kind of ingroup/outgroup thing.

~~~
adrianhel
Then again. I thought jQuery and AngularJS was problematic when they were
trendy. React is 6 years old and still doing it for me.

------
throwaway98121
I find front end development extremely boring. Just my personal opinion. So
you make another web page using a new framework. So what? How is it better or
more valuable than what you could have built 5 years ago? Did you discover a
framework that gives you faster time to market? Is it easier to support
because it’s a smaller code base and multi platform? Is the performance that
much better? Did some Ab testing really prove to you that you need to optimize
load times because millisecond scale differences impact dollar value? You
could have and that could perfectly justify a new set of frameworks that solve
those use cases. The majority of the time in my experience, people just move
from one toolkit to another not because they evaluated requirements or pain
points and found something truly better but because it’s the cool new thing.
It all ends up being garbage tech debt.

Building a native application with native APIs using JavaScript sounds
interesting. Okay, you built another user interface. How many of these do we
need to build? How many apps does the typical user have installed or even use
among the ones they did install?

I remember recently turning on some tutorial for a web app that was linked
from HN. Angular on the front end, node on the backend, framework B for
writing tests, framework C for running them, some other tool for the build
process. Another tool or plugin for minification. Okay great. You know the
frameworks of the month. Congrats.

I learned HTML back in late 90s in grade school and went on to build PHP apps
in the early 2000s for my Unreal clan. By college, I supported a stack for my
university written in CakePHP. I remember using django for a class project in
my CS program. My first job out of college, there was a tangled mess of
asp.net, .NET web MVC and .NET web apis. My next company, there was a ton of
stuff in Spring and various APIs using jersey.

Honestly, none of the real value was in any of the web apps. The value was in
the backend logic (if there was any significant business logic at all) and
more so in data and real system design, balancing between function,
redundancy, resiliency, extensibility, and some notion of scalability
depending on who the customer was and what expected or unexpected scenarios
could arise and how our systems would behave.

Unfortunately I see too many folks caught up in the framework of the week or
framework of the month when there’s so much more depth if you’re willing to
explore.

~~~
aastronaut
> "Honestly, none of the real value was in any of the web apps. The value was
> in the backend logic (if there was any significant business logic at all)
> and more so in data and real system design, balancing between function,
> redundancy, resiliency, extensibility, and some notion of scalability
> depending on who the customer was and what expected or unexpected scenarios
> could arise and how our systems would behave."

These are all responsibilities on the frontend as well... Website =/= Webapp.
It almost seems that a lot of backend developers are not making this
distinction nowadays, even though SPAs are already out there for years.

In the frontend there is the ever-responsive UI workload, the option for web
workers, and service workers are on the rise. To keep your state there are
JavaScript objects, web storage (session- and localstorage) and IndexedDB.
WebGL anyone...? Newly developed JavaScript should sometimes work in the
browser as well as in Node.js. I am solely mentioning technology here, not any
implementation - this is thanks to the frontend of the web, as sandboxed app
platform (and JavaScript), being so versatile. Next to the system design of
the app there is also the gap to its UI/UX design to fill. ...All should work
reliable on devices with very limited resources, as there is no option to
scale on the client side.

"How to reach offline functionality?" Is a question with all of the complexity
belonging to the frontend. Whereas the frontend is the data's real-time
interaction, the backend becomes more the reliable async distribution of data.
I'm sorry, but frontend app development is everything except from boring for
me.

~~~
throwaway98121
How many apps require web storage? Are there sufficient requirements to
implement web workers or service workers?

Go back to the core design and simplify it. Keep what you need and everything
else is noise.

My point was people pick the new and coming framework and it turns into tech
debt. If development was more requirement driven, we wouldn’t be in this mess.

~~~
aastronaut
To come back to the OP: "Why does front-end development change so often?"

I think a lot of technology that was solely available to the backend for a
long time is now possible to do in the frontend (including machine learning
with Tensorflow) ...it's a quite new and limited (but save) form, but the
advantages in using those capabilities are clear to me.

As everything is quite young there isn't an established pattern yet and a lot
of active research is happening. Just in the last 5 years alone we got quite
an amount of additional languages: Elm, TypeScript, Flow, ReasonML,
PureScript. I personally like the functional approach of React to transform
the interaction of the imperative DOM to a declarative one, but there is still
a lot to be done until we reach something like an MV* pattern for SPAs. If I
were to make a guess, I would guess that all the active change in the frontend
(including the urge for WebAssembly from some) is truly because of the hope
for an MV* pattern that combines all those technologies with the advantages of
the web.

If you were to take on some tech dept, please make sure to keep it interesting
for the future development. The essence of the web is to not find a common
agreement, and I think the active development on the frontend mirrors this
sentiment quite well. ;)

------
simion314
I noticed that even with a small project with only 3 dependencies the dev
dependencies are still large. As an example I was trying to build this project
tui.image-editor from GitHub, it has 3 dependencies but check how many dev
dependencies it has [https://github.com/nhnent/tui.image-
editor/blob/master/packa...](https://github.com/nhnent/tui.image-
editor/blob/master/package.json) and how many those may also have, when I
installed them with npm I counted around 10 deprecation warnings and I was
thinking that in a few years we may not be able to build this projects, we may
have to hunt around for old version of stuff, fix conflicts between packages
and other nightmare scenarios.

Maybe it would be a good idea to commit the node modules to GitHub?

------
lkrubner
I assume you are talking about GUIs over TCP/IP, in which case a large part of
the reason is the mismatch between what is used by most GUI software versus
what we use over TCP. Most of the best ideas get voted down, and there is no
agreement about how high level or low level the language should be. As an
example, see 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)

It’s worth remembering that Swing has been stable for awhile, after a terrible
era when new layouts were being proposed every 6 months. And Flash had a long
era , nearly 20 years, of remaining mostly the same (though ActionScript 3 was
a significant change compared to version 2).

There has been a lot of talk about generating GUIs as pure SVG, but this
hasn’t happened yet. Is that too low level? There has been some talk of
generating GUIs with PostScript, but that hasn’t happened yet. Is that too low
level?

I suspect change will be constant until the industry reaches some consensus
about what level causes the least pain.

I don’t believe Javascript will survive. Eventually this current era will be a
bad memory and we will laugh about Javascript the way we now laugh about Swing
and ActionScript.

~~~
lkrubner
Why was this downvoted? What part of this is untrue or inaccurate?

------
sh87
If you think about the front end ecosystem, in an economics sense, you will
notice these distinct players : browsers, JS libraries/frameworks,
apps/websites consuming these to provide solutions for the end user and the
web devs.

There is tremendous competition at all levels.

Browsers (Chrome, Safari, Firefox) are competing each other fiercely and
provide rapid advancements in capabilities.

Libraries/frameworks (Angular, React, Vue, D3, and a bazillion others) are
competing more fiercely for a stronger hold on the market.

Website owners compete harder and want the "latest" tech to grace their
product offerings creating great demand for the latest tech.

Web devs compete even more fiercely to stay relevant by picking the latest
tech in the market.

Add to this advanced browser capabilities, increased computing power and
fragmented screen sizes (phones, desktops, laptops, tablets) with faster data
speeds and you have a bustling ecosystem that changes more rapidly than any
player can keep up with.

------
djndjakdjfj
Here’s a controversial opinion. Most junior programmers start off programming
front end. And most of them don’t fully understand the frameworks they are
using. So there is a bit of a herd mentality when it comes to front end
development. They will rush to the next hot thing because of all the shiny new
things it can do.

~~~
RyanShook
Not sure that’s controversial ; )

------
enturn
There are some additional insights at a similar Hacker News Discussion. Why Is
Front-End Development So Unstable?
[https://news.ycombinator.com/item?id=17190992](https://news.ycombinator.com/item?id=17190992)

------
Wavelets
I started learning web development last year and have been completely
overwhelmed by all of the tools, frameworks, etc. that are out there. I found
the back-end to be a lot easier to pick up than the front-end.

Granted, I’ve been using Python for a long time and chose it (Django) for my
back-end. It helped to not have to learn both the language, the framework, and
concepts at the same time.

I was so frustrated with Vue that I ended up going with Elm. I did not have a
background in functional programming, but I found it so much simpler than
trying to learn Vue or React.

------
watwut
Combination of "it is not there yet" and "a lot of people need it".

Former means that you still can produce improvement with a small team or even
individual. It also mean that people are in constant search for something that
would fix them very real problem they have.

The latter means that many such small teams are trying and having enough
experience to be able to improve something small. It also means that people
talk about it a lot which leads to information dissemination (so you learn
about new things fast).

------
akamaka
Web development has been the greatest nexus of software innovation for the
last two decades, and its influence has transformed the entire landscape
around it. It has fundamentally changed data storage (XML, JSON), app
integration (embedded Google Maps, share buttons), graphic design (CSS
sweeping away embedded images and paving the road to flat design), and much
more.

Many of these innovations began as surprising hacks which pushed browsers
beyond their limits and created significant problems with security,
performance, and visual rendering.

As these hacks became mainstream features, developers took two different
approaches to fixing the problems. Some worked on creating front-end libraries
which smoothed over the flaws in the browsers, while others worked on the more
difficult problem of fixing the browsers themselves.

Front-end Javascript libraries can significantly improve developer
productivity and a new, improved framework will see rapid and widespread
adoption. However, the slower work of fixing the browsers themselves continues
in the background, making those Javascript libraries obsolete and introducing
powerful new browser features.

As we speak, there is an incredible array of new features in the latest
browsers which are going mostly unused, because most web developers don't want
to touch them until that last 5% of older browsers die off. Today, it might
look as if a certain web framework is the be-all and end-all of web
development, but in reality the groundwork has already been laid for it to be
obsoleted and replaced by better, faster, more secure, more productive tools.

------
pizza
A UI framework has to accommodate a huge range of projects of massively
varying complexity, from barebones text layout to global enterprise across
hundreds of types of devices. But people also want it to be simple enough to
learn easily, prototype quickly, and maintain long-term without significant
headaches. There ain't no such thing as a free lunch when it comes to
simplifying complexity, so one framework cannot rule them all. So we get new
ways to do stuff, constantly.

~~~
simion314
Browser developers are for some reason putting effort in JS engines, speed but
ignore working on the UI elements, you still can't CSS the scrollbars in
Firefox (so projects use big JS libraries) , you can't css the select element
and it's options so again you have to use JS to create a custom select, but
some projects will use some jQuery library for this missing components, others
will use bootstrap, others will wrap this other ones... web components could
make this mess a bit cleaner but for some reason they are not ready or nobody
uses them.

------
zwaps
There's actually two facts you have to consider side by side

1\. Front-end dev changes often

2\. Websites have become worse at being websites

Like AMP, single-page apps being mostly broken if not viewed in a pristine no-
addon Chrome, loading megabytes of scripts to display a bit of text, overlays
blocking the screen, sluggish scrolling, broken dynamic loading, misused and
misunderstood statistical testing suites, fragile "graceful" third party
content everywhere, less accessability, pop-ups, now scripted, again! ... the
list goes on and on.

Being good at displaying text is now a killer feature of only few elite
websites... Imagine that.

I believe front-end devs are much less sophisticated programmers than the
frameworks they use. Those frameworks are usually years of work from big corps
geared at a specific use-case. Back in the day, before so many new
technologies, people were hesitant to write websites with tools they would not
be able to write themselves.

Today, I do not think more than a fraction of front-end devs actually
understand what all these new technologies are doing under the hood, nor could
write them themselves.

And if you are already playing with Legos, it of course leads to putting in
too much stuff without sense and too much stuff where it doesn't belong.

Finally, I think everyone (subconciously?) realized that the web has become
bad. But if the only option you see is a new framework, then people chase
after new tech instead of writing better websites with simple technologies.

------
ng12
I've been using the same tech stack for the past four years, and I'm not
planning on changing anything major anytime soon.

I think it's mostly a perception issue due to the fact that front-end
development was historically a poor experience and things have greatly
improved in a very short time.

~~~
burfog
Four years is nothing. That you seem to think this is a long time is telling.

My tech stack dates back to 1972, with the last major update in 1999 and the
last notable minor update in 2011.

That isn't even a particularly old tech stack. Some stuff dates back to 1957,
with major updates in 1977 and 1990.

~~~
ng12
I only mention it because OP implied it's changing every year, which it's not.
I'm well aware C and make are more than four years old, no need to be
condescending.

Honestly the big "revolution" was the change from imperative frameworks
(jQuery, Backbone) to component-based frameworks (React, Angular 2+, Vue).
Everything else is just an incremental improvement in one way or another.

------
torte
I find it actually slowed down in recent years. Things finally seem to settle
around the React ecosystem (yes yes, Vue has more stars). I also think there
are way more projects which help you get started now without having to know
all the tooling around it right of the beginning.

Regardless if you are working on a project and you have to deliver then simply
stick with what you know. It does not matter what is the latest shiny thing
out there and in most cases it won't matter in a few more years into the
project as well.

If you want to learn something (new) in the frontend space though and also
build something useful, the best approach I found is to only adapt one or two
new things and have most of it build on what you know (using the 80/20 rule).

------
yahnusername
Couple ideas:

Maybe it doesn't change often, but the developer pool is full of people early
in their career who would rather find the next big thing and get in on the
ground level than be 3-5 years behind the curve on the existing stuff. And
then they tweet all day about it.

Maybe it does change often, because there's such a focus on build tools and
developer ergonomics; and doing that in 201X lets you follow the treasure map
made by the ppl who already figured it all out for systems programming decades
ago. The kids are calling it transpilation and tree-shaking these days.
They're writing APIs for GPU access, and assembly code for the bits that need
to be really performant.

------
karmakaze
I think there are a few reasons for that.

1- back-end frameworks tend to follow either the Rails or Sinatra models. We
may get new frameworks in new languages but their structures are fairly
similar. Datastores have been changing but usually get abstracted into a
supporting library. GraphQL a bigger change than we've seen in a while.

2- front-end requirements are changing faster with a greater number of
developers solving more varied problems.

3- front-end is at the top of the stack so is less constrained. Making changes
in the back-end can have consequences to all developers of a product. Front-
end changes only affect the front-end devs who likely do both the app along
with new frameworks being built.

------
sebmak
I think alot of it comes down to the fact that the internet, and frontend-
development (web development mostly) is relatively new. And as with anything
new, the community is just trying everything they can to make it work until
something eventually sticks.

As someone who has done this for a while, I remember how difficult it was to
try and build a UI using flash, then later with just html and jQuery, and now
with modern libraries like React. So while it seems like every year there is a
new "better" way to do something, but that is mostly because is is getting
better and easier over time.

~~~
RyanShook
Front-end web development is at least as old as the web itself so I’m not sure
I agree with that argument.

------
drbojingle
Immaturity. think about a time when you changed the most. When was it? Web
apps use to be sites with a bit of javascript and they've been growing up
these past 18 years. That's it. It's growing pains.

------
MilanoCookie
Related to this topic:

What are the minimum technologies needed to get a solid front-end stack, with
a nice balance between modern features without framework/library/build
tool/transpiling hell?

For example, I don’t want to learn TypeScript when vanilla JavaScript will
suffice. I’m wary of picking up the “hot” new frameworks because they haven’t
stood the test of time and may get deprecated/irrelevant.

Basically, I want to have a flexible and minimalist stack, but also with a
good balance of features (i.e. not just a static HTML site).

Any ideas?

~~~
mmvs
I'd say react.js. It has been proven to be a good choice for all kind of web
applications (small, large) and even static web sites
([https://www.gatsbyjs.org/](https://www.gatsbyjs.org/),
[https://github.com/nozzle/react-static](https://github.com/nozzle/react-
static)). Also it has an awesome community and awesome tooling (create-react-
app), which allow you not to bother with "framework/library/build
tool/transpiling hell".

Check this repo if you're interested in react:
[https://github.com/enaqx/awesome-react](https://github.com/enaqx/awesome-
react)

You can also check vue.js, I have heard from many people that it's very good
and some even say that it is better and easier to get started with than react
:) I've never worked with it so I can't say much about it

~~~
MilanoCookie
Thanks, I keep hearing great things about React, not to mention the added
bonus of React Native. I’ll look into it further.

------
undoware
it evolves quickly because the whole field is based on a couple of hacks, and
the possibility manifold is being constantly dilated via the tiny hole they
opened.

ES5 plus XHR rent a hole to a bizarre parallel world where the whole page was
an applet. We are still working out what that means.

Unlike every other development context, this whole world is an accident.

I made my first website in 1996. Youth, listen to me.

~~~
CharlesW
> _it evolves quickly because the whole field is based on a couple of hacks_

What are the two hacks the whole field is based on?

------
i_phish_cats
Aside from a critical mass of developers, another reason is: Because it can. I
can access new, proposed features not yet implemented in any browser with
polyfills and transpilation. Distribution is not a problem (sans file sizes)
because the user downloads the newest version every visit. Now, if IE users
would just go in a cave and die peacefully...

------
waingake
Fairly recently rendering in the client became possible and desirable. This
was a paradigm shift, it raised a lot of new problems, and a number of
attempts were made at solving these issues. The field is settling now on the
ideas with the most merit. Reacts idea of the virtual dom is an example of an
idea that is becoming a stable standard.

~~~
hnmonkey
Is rendering the right word here? It doesn't feel like it is to me. I thought
rendering was the final step in taking a DOM and turning it into something
that is shown on the screen. Basically, the job of the browser. Based on your
logic you're saying that before now rendering was happening on the server, but
that doesn't make sense.

Edit: I thought about it and it seems like generating is the right word and
rendering is still just something that happens on the client-side no matter
what.

------
mbfg
Curious, does javascript, the language itself, cause this rate of change
(whether you see it as a good thing, or as a bad thing), over server side
languages, java etc.

------
Falkon1313
It's a fad, built of fads. Front-end stuff is able to do a lot more than it
was a few years ago, in a lot of different ways. So everyone wants to get on
board (it's a fad) to take advantage of that, trying various things out,
hoping to find the best way (those attempts become fads) to do things. Most of
it is noise and only time will tell what was signal. Some few classics will
live on, but most of what is being done now will quickly be forgotten. So
things are rapidly starting and also being rapidly relegated to the dust-heap.

------
konaraddio
The web is young so there's lots of room for growth (and thus lots of work to
be done)

------
hliyan
I often wonder how different things would be if JavaScript had a standard
library.

------
robjan
The barrier to entry for frontend is lower and it's easier to present your new
idea visually so people are more likely to bite. There's also a lot of money
and/or glory in becoming and "influencer" and the easiest way to do this is to
create a new framework.

------
jb3689
> Why do you think front-end development is in such a constant state of
> change?

Browsers have been resistant to change and meeting standards for the longest
time. This resistance to change has meant that the core libraries (i.e.
vanilla Javascript) have been inadequate for large-scale front-end
applications. Today browsers are much better than they used to be about
keeping to spec, and the days of old IE hacks in your front-end code are
mostly gone. In addition, you had other hacks in the front-end (using
tables/floats and other arcane CSS tricks to get things to render properly)

These issues caused a surge in wrappers to appear to 1) encapsulate all of the
hacks and 2) present a better interface than core JS had. jQuery was the
biggest player at this time and you were crazy to try and develop without it.
People became accustomed to jQuery and then started to iterate on that (we got
Promises, we got people thinking about how to encapsulate and automate changes
with an API, we got people thinking about how data should be bound to
components). Backbone, Angular, and Ember all appeared to try and solve these
issues

Fast-forward a few more years and you have a new set of problems and proposed
solutions. Tools started getting complex and people would fork off new ideas

Today the browsers are better than they were years ago, and I expect we'll
eventually revert to vanilla JS, but there are a couple of issues that the
browser still hasn't solved:

* How do you componentize CSS with JS in a sane way? Loading everything into a global namespace is kind of crappy

* How do handle a growing language specification? Unlike server-side languages where you control everything, browsers may be on different versions, etc - how do you still write portable code?

* How do you efficiently cache, transport, and invalidate your assets? There are multiple schools of thought here, and I believe HTTP 2.0 will have a big effect on this

TLDR; the community is moving faster than the browser and building their own
solutions to hack around problems, thus you have a lot of churn as problems
evolve and the browsers get better

------
spricket
As some others have mentioned but more TLDR: It hasn't changed that much if
you bet on the right horse at the beginning of the "SpaSplosion". React is the
best example, having been around for close to 7 years.

For a while the biggest issue was that there was no SPA framework or module
loader that had been around for more than a few years. Now at least we have
webpack, npm and yarn. Things feel like they're becoming sane.

Assuming JS stabilizes as other languages have, React is a safe bet for
another decade due to its popularity.

Another safe bet appears to be TypeScript. So if you are okay with following
the crowd, a React + TypeScript project should feel "modern" and upgradable
for a long time

------
amriksohata
Will webasm change this all again?

------
clanrebornyes
Unlike backend frontend isn't built on a solid foundation.

So someone people don't learn the stuff in use (or find it difficult to
achieve the current trend in preexisting technology) in use and find easier
tricks/concepts then base their whole framework on that.

Now newbies, who want to quickly achieve something gravitate towards the new
shiny things which makes the current Trend easy but makes rest of the things
difficult.

You can optimize technology along any axis, but if you optimize it along one
axis it will be deoptimized along some other axis.

For example, think of interactivity. When people wanted to build interactive
website, they brought stuff like websockets/single page application but now
websockets can't be cached like a http API and SPA throws monkey wrench into
SEO.

Now, you made current trending thing (interactivity) easier for newbies but
made other things like initial page load time, SEO difficult.

These are my noob level observations, as you gain more experience you'll find
many examples of this happening in wild.

Similarly, to achieve scalability people brought in JWT instead of Session
cookies and lost ability to revoke the token without maintaing a blacklist or
using short lived tokens which you've to refresh every few minutes increasing
RPS load for the server.

So the moral of the story is that you need to understand what a particular
technology makes easy and what it makes difficult then you select the
appropriate technology without chasing the hype.

------
nobody271
Because a few years ago it was the most easy to use language and people were
creating brilliant tools and software libraries that, truly, changed the
world. Because of the low barrier to entry everyone and their grandma became
copycats by releasing their own revolutionary new framework. For a long while
being a master of the majority of the JavaScript landscape made you elite. So
developers minds were stretched, no, pulled apart by the diverging number of
JavaScript frameworks.

Before long the list of things they were supposed to keep track of got so long
that it just became impossible to do. I haven't been able to keep track of it
since but I assume that just means the number of JavaScript frameworks is
expanding faster than the speed of light.

