
Ask HN: Is all programming constantly changing or just front-end JavaScript? - saltcod
I&#x27;ve been working on frontend dev for several years now, in the pre and post framework era. React and the other frameworks and ES6 in general, has meant a ton of change to the very basics of how we work.<p>The way I do basic things has changed fundamentally in the last 4-5 years. Some of that is because I&#x27;m no longer a &quot;beginner&quot;, but much is because things have just changed a ton.<p>People who know the JS &#x2F; frontend ecosystem AND backend stuff as well:<p>Is this rate of change unique to JS, or is it everywhere? 
Is Rails very, very different now than 4-5 years ago?  Django?<p>I use PHP a bit and I&#x27;ve seen that change a bit, but it feels like mostly for the better, with namespaces in particular. Otherwise, I don&#x27;t feel like PHP has had near the amt of change that JS has had.<p>tl;dr:   is it crazy everywhere or just with JS&#x2F;frontend?
======
ggregoire
I've been doing frontend dev for 10 years and had to change my stack & way of
working _only_ 3 times:

\- HTML templates (served by Symfony/ASP.NET/Rails/Django) + jQuery +
dependencies manually downloaded/updated/deleted/added to the index.html

\- ~2014: Angular SPA + Grunt + dependencies managed with Bower and added
manually in the index.html

\- ~2017: React SPA + Webpack/Babel + dependencies managed with NPM and added
automatically in the index.html with Webpack.

The last one is by far the stack with which I'm the most productive and I
encounter the less bugs. I feel like frontend dev is finally mature and
enjoyable.

But anyway, jumping from one stack to another one was quite easy. A few days
of learning.

-

I've been doing backend dev for 10 years too and had to change my stack & way
of working as often, if not more.

Jumping from one (or several) languages/frameworks/databases/ORMs/web
servers/containers/package managers/testing tools/and so on, usually take
several weeks of learning.

Imo, the "frontend world is crazy/changes too fast" is way over exaggerated.

~~~
julienreszka
I wish programming was more like playing a musical instrument. I feel like
there is too much tuning not enough playing.

~~~
Sendotsh
I think programming is more akin to developing and/or manufacturing
instruments. Playing them would be the users.

~~~
throwmeback
I think the subparent meant the developer experience - this counts as playing
as well.

------
rco8786
It's all changing, but it seems that front-end JS is changing the _fastest_.

That's (IMO) due to a handful of reasons. But three standout in particular...

1) The state of Javascript's standard library is getting better but still
pretty bad. So people continually reinvent new ones.

2) Every company with a frontend (see: Every Company) has to work with
Javascript (esoteric compile-to-js aside) on the front-end, so the sheer
number of people/companies using JS is larger than basically any other
language or framework.

3) Javascript is increasingly the first (and sometimes only) language that new
developers learn and tinker with. And we get the resulting
ideas/platforms/frameworks/etc/etc that people invent as they're learning.

~~~
rhlsthrm
Agree with the first two points, but do you really think "new developers" are
the ones who are creating the "ideas/platforms/frameworks/etc/etc"?

~~~
zbentley
I do. Maybe not the tools that become popular, but new developers often
consider publishing their first side project or personal tool to be a valuable
milestone.

I think a lot of green developers' JS tools don't make it to the mainstream,
but they certainly do make it more difficult to filter hype from substance.
That's not a valid reason to discourage contributions: more people hacking on
more stuff and making more discoveries, even at the cost of fragmentation, is
far more valuable than putting a chilling effect on contributions (and there
are other ways to mitigate fragmentation).

------
rolleiflex
From what I could see, the amount of churn in the Javascript world is
unsurpassed by anything in software or product, almost to an order of
magnitude.

I ended up being a product designer (my main, academic education), a frontend,
and a backend with varying levels of expertise in my lifetime, so I have some
direct experience.

My current advice as of April 2019 is to keep calm, if you can stay away from
JS, do it, if you can't, pick Vue, avoid Webpack, use Typescript, and forget
the rest. That should go fine for the next couple years, if you can manage to
remove Webpack, even longer.

~~~
Jorge1o1
What's the matter with Webpack? It carries quite a lot of advantages, like
tree-shaking, code splitting, and lazy loading.

These are real, tangible performance benefits, so I'm going to need some kind
of compelling evidence as to why avoid Webpack.

~~~
untog
Configuring it is a giant time suck. Particularly if you want to do hot
reloading and all that kind of stuff.

I'm a big fan of Parcel for 90% of the things I do. It just works.

~~~
mattbreeden
It does just work. Until you want to use something that the core devs don't
use.

Like having the most popular front end framework be unusable for at least 6
months: [https://github.com/parcel-
bundler/parcel/issues/645](https://github.com/parcel-
bundler/parcel/issues/645)

Often you'll need to hope some third party made a plugin or make one yourself,
which isn't really any different than using webpack, but the webpack ecosystem
is much larger.

I struggled through parcel for a long time before I switched to Webpack 4 and
had all of my existing build system and some additional niceties working in
<45 minutes (probably 30 min of that was just reading the docs).

~~~
ricardobeat
Looks like that particular issue was closed in July 2018? Also, anybody who
considered that feature important enough could have fixed it. It's not rocket
science. Certainly 10x easier than when that magical _something_ in the
webpack build chain breaks.

~~~
mattbreeden
> Looks like that particular issue was closed in July 2018?

Yes, after being open for 6 months.

> Also, anybody who considered that feature important enough could have fixed
> it. It's not rocket science.

First off, maybe- but I was responding to the comment of 'it just works', so
that's not relevant. My entire commentary was on 'it just works'. It doesn't
really 'just work' if users have to implement their own plugins and fix their
own bugs on super popular JS integrations.

Second off, a user did fix it, and it took the devs a month to respond to the
PR- so you're still at the mercy of the core devs.

> Certainly 10x easier than when that magical something in the webpack build
> chain breaks.

And this I'd just have to disagree with you on. Webpack has way more eyes and
as a result I have had one issue (bug) with it which had already been fixed. I
had many issues using Parcel beyond the one I linked of the most popular
front-end framework not working.

------
jppope
I would argue that the frontend js changes are mainly to do with user
expectations for what constitutes a well designed user interface. People
expect more, and we have to give it to them to survive.

Addressing your specific question => have the backend languages/ frameworks
changed? meh. sorta. They've made incremental changes, but the meat and
potatoes look the same from 4-7 years ago for the opinionated frameworks.

However, the massive backend change that is probably more relevant to your
questions is the shift in how we do infrastructure. Cloud based Version
control, Microservices, Containers, Kubernetes, Docker, IaaS, Serverless, CICD
systems... all of these things are transformational changes to backend
ecosystems- both in scale and in the way that we interact. It has also made it
so we write less code which is actually an increase in velocity for what we
can produce.

thats my $0.02 anyway

~~~
alexpetralia
Nice comment. I agree - I think innovation in backend development has really
been subsumed by DevOps and data pipeline architectures, which have both
really changed quite a bit.

~~~
eitland
Java and .Net is steadily improving. But unlike the JS world things are mostly
backwards compatible and there exists stable (some have argued too stable)
dependable frameworks.

We are starting to see this in the frontend world as well with Angular. After
throwing everything away between 1 and 2 it is now mostly smooth (until Google
decides to ditch it for something else).

~~~
tannhaeuser
> _Java and .Net is steadily improving_

Don't know about that. Java is IMHO about to enter a serious downward spiral
as lots of stuff is being deprecated going to Java 9 such as ancient
jetty/tomcat versions, JAXB 1, JAX-RS (which people used in the 2000's and
early 2010's to create "RESTful" apps/microservices), and being force-
obsoleted with incompatible newer versions having features no-one asked for.
The Java ecosystem might have worked well under the illusion of multiple
implementations for standard core interfaces, and with projects requiring high
attention such as Hibernate, Spring, freaking Maven, etc. as long as it was
the cool shit (it wasn't really cool IMHO) and had some money behind, but as
Java is becoming legacy technology, it increasingly sucks to maintain pom.xml
(aka pron.xml) files pointing to obsolete packages on a barren place like
mvnrepository/maven central. My experience with younger devs having to
maintain Java code: they secretly look for Go and entirely other career
choices to get tf away from Java and Maven, and I can't blame them.

~~~
eitland
Yep. And .Net had issues in the transition to Core.

We are still talking about an order of magnitude or more (5-10 years of
stability vs months.)

------
mises
* Yes, JS is changing stupidly quickly.

* C++ has changed a lot starting with C++11, and is still changing quickly. However, not nearly as quickly as JS.

* C is still stuck in the age of the dinosaurs. The tooling has gotten a little better with clang, cmake, etc. (though these are as much a result of its close relationship with C++ as anything).

* Assembly is not moving, mostly because it's dying. There's one notable exception: ARM.

* PHP is changing much faster than it has for a long time.

* I learned rails about 4-5 years ago and haven't done much with it since, but it doesn't seem very different (though this could be wrong).

* Rust, go, zig, and other new languages are all vying to replace legacy languages such as C/C++, even for high-performance, low-level applications. This may be part of the reason some things that didn't change previously are now changing: competition. Ditto with PHP and node.

* One other item of note I haven't really explored: functional programming seems to be the new hipster technology, and as a consequence is rapidly evolving.

It's kind of crazy in many places, which, to your earlier point, does indeed
hinder productivity. For many people, more time is spent learning new
frameworks, programming paradigms, etc. than actually doing work.

Oh, and I'm only commenting on the parts I have at least some experience with.
I'm not sure for other areas. I've also heard a lot about swift on ios, along
with cocoa. Even windows has uwp and has really been pushing its modernized
c#/xaml ecosystem.

~~~
toast0
> * Assembly is not moving, mostly because it's dying. There's one notable
> exception: ARM.

What? Assembly is not moving, because it's complete. You can pick Intel or ATT
syntax, and then you just need to handle new mnemonics when your processor or
choice ads new opcodes. Certainly, assembly has a smaller market share than in
the past, but there's nothing to replace it for critical sections, so I don't
see how it's dying, since it won't ever be dead.

~~~
mises
> it's complete

That might be a better way to phrase it, you're right. I've got nothing at all
against it, and appreciate using it for certain applications. I meant less
dying in the sense that it will go away entirely and more that it is slowly
becoming relegated to critical applications (i.e. very few applications are
written in it).

------
_bxg1
Much of JS's turbulence in the past 5 years has centered on it coming into its
own as a "real" programming language/ecosystem. Modules, a headless VM,
reactive patterns for user interfaces. All of these are things that other
languages started out with, whereas JavaScript started out as, well, a
scripting language. It was just sprinkled atop HTML pages, not running the
whole show.

So my guess would be that things are going to slow down soon. Not completely;
JS might remain one of the most turbulent ecosystems. But I think there will
be a sharp dropoff in churn.

~~~
emilecantin
Yeah, Javascript just lived through its "adolescence", with all the changes
and hormonal swings such a phase entails.

------
prewett
I think much of JS's churn has been the problem that the UI primitives (HTML)
are unsuitable to what people want to do. When you can't even vertically
center something without reading a bunch of web pages that tell you something
like six different techniques, you can imagine that people are going to make a
library to do make it easy to do. But since the foundation is crap, and good
API design is actually hard, the result is not very good. So someone tries to
fix it later, and runs into the same fundamental problems.

I think JS the language is in better shape, but even then it is hampered by
poor decisions early on. (Integer arithmetic done with double-precision
floating point underneath the hood? And it supports bit twiddling, but only if
it is really an integer and not a floating point number? And implicit
conversions? What could go wrong...)

But it is also hampered by other problems. I used WebWorkers recently to
compute normals to large amounts of triangles on think, rather than
transferring them over the network. In any normal language, I'd add a mutex
around the data and spin up some worker threads. But in JS I can either copy
the data, or give it away and that thread can't access it again. Since I need
the triangle data and don't want the hassle of giving it away and then having
the WebWorker give it back again (along with the normals), and then having to
manage putting it in the right spot, as well as what happens if I need to
access triangle data that's currently being processed, this is a major pain. I
understand that the WebWorker design makes it impossible for the browser tab
to hang on a deadlock or have all the fun threading errors, but as a
programmer, JS is the one language that forces poor performance on me. So you
can imagine someone like me, but with more influence, saying, "hey, we need a
redesign to fix this." But since the previous designers presumably knew how
all other languages work and rejected that approach, the redesign probably
won't really fix the problem, for similar reasons why we didn't get
WebPThreads the first time around.

~~~
lkrubner
" _I think much of JS 's churn has been the problem that the UI primitives
(HTML) are unsuitable to what people want to do._"

I said the same when I wrote "The Problem With HTML":

Just to offer some perspective about where I’m coming from, I’ll start by
saying that I think of these as tools that made it easy for beginners to be
productive:

Hypercard

Visual Basic (obviously I mean the classic versions, before .NET. The stuff in
the 1990s was genius)

Adobe Flash

Adobe Dreamweaver

I spent 1995 learning HTML and putting together simple websites. I was
thinking this is something I’d like to do professionally. In 1996 my father
and I went to a demo in New York City, where Adobe was introducing PageMill,
their Web page creation software. My father was impressed. My dad wasn’t in
the tech industry, but he was pretty smart about technology trends. He said,
“Anyone who knows HTML just lost their job. This will replace the need to know
any of the underlying technologies.” But that turned out to be wrong. Even
now, in 2017, most companies building Web software still rely on individuals
to hand-write their frontend code. Indeed, from the point of view of business
productivity, everything has been going in the wrong direction.

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

What is curious is that the companies that have the money and resources to
roll out something better than HTML have not done so. The biggest surprise
here is Adobe, which owns Flash, which many people thought of as the future of
the Web circa 2004. Why didn't Adobe roll out new basic network protocols to
replace HTML, and perhaps also replace IP and TCP? I don't know. They had the
resources to do it and instead they did nothing but stand around and watch
their most important asset die.

------
armadsen
No, it’s not, or at least not as fast as the current churn in frontend JS dev.
I started doing Cocoa dev on the Mac in 2005. There have been changes to be
sure, the biggest being the introduction of Swift I’m 2014. But I’m still
using AppKit. I can (and do) still use Objective-C alongside Swift. And I have
a pretty big codebase dating back to 2006 that still compiles and runs fine
even with the latest version of Xcode.

(I realize this isn’t backend dev, but there are other kinds of programming
besides web development :-))

~~~
ummonk
>And I have a pretty big codebase dating back to 2006 that still compiles and
runs fine even with the latest version of Xcode.

I mean, the same is true for any webpage written using JS + html + css in
2006.

------
RickS
As somebody that's in JS all day but rarely touches backend, hearing about go,
rust, kubernetes, docker, etc make it feel like backend is similarly fast-
changing.

The difference seems to be in the narrative about the older tech. The "rails
is still fine" crowd is loud, which is great. There is no equivalent for older
JS tech. Though I would be willing to believe that's because things like
jQuery are full of dated patterns that lead to bad times.

~~~
Jorge1o1
The beauty of React and other frameworks is that it separates the concerns of
state and UI.

I don't see it as a tool for making a fancy button or widget, I see it as a
tool for guaranteeing that what the user sees is always what's actually going
on in the logic.

Too many times I've written something like a "clear" button or a "reset"
button in jQuery, added an extra field, forgotten to include it in that
clear/reset method and now the UI doesn't match the logic, leading to
unpredictable and hard to debug results.

~~~
konaraddio
React separates concerns but it doesn't separate state and UI. It separates
concerns through components but encourages tightly coupling relevant state and
UI into components because a UI typically reflects changes in state (this is
what JSX is for).

The "Why JSX?" on React's docs covers this with more detail:
[https://reactjs.org/docs/introducing-jsx.html#why-
jsx](https://reactjs.org/docs/introducing-jsx.html#why-jsx)

------
abuchanan
Been meaning to write a blog post about this, but my 2 cents is this: The
degree of change in a programming language ecosystem is inversely proportional
to the expected lifespan of the systems being built using that language.

One caveat for the pedantic - yes, as the expected lifespan becomes zero, so
does the rate of change. (i.e. you have a dead language)

The lifespan of a system gets longer the closer you move from the UI through
the business logic and finally to the underlying data. It isn't uncommon for a
business to rebuild its frontend website every 1.5 years or so, whereas their
systems-of-record might be expected to last a decade or more.

Since JavaScript is used most frequently on the frontend (for obvious
reasons), and new frontend projects kick off more frequently, there is less
need for backwards compatibility, fewer risks to trying the new and shiny
framework, etc.

I'll probably get internet slapped for saying this, but I would predict that
JavaScript never does become the preferred language for the system-of-record
type backends no matter how quickly it evolves. In fact, precisely BECAUSE it
evolves so quickly. What makes it a great fit in the one niche, makes it a
poor fit in the other. Lest this be taken as JavaScript bashing, note that the
same thing happened to Java in reverse. It was evolving too slowly for the
frontend niches it tried to move into years ago.

------
chrisco255
While I think things have changed a lot since 2012 (when I started) I don't
think they've changed that much since 2015. The language and ecosystem went
through a lot of churn as single page apps and front-end complexity exploded.
In 2012, there were something like 10 different popular JS frameworks to pick
from and most of them have been all but replaced by the top 3, which seem to
have stabilized: React, Angular 2+, and Vue.

ES2015 brought a lot of changes to the language itself. But recent years have
been less dramatic minor syntactic improvements.

Front-end web has unique challenges and constraints that other front ends
don't have to worry about as much.

A web app has to download the full payload of the app code and execute in one
sitting. Yes, there's a myriad of ways to optimize this (such as caching,
server-rendering, etc), but having to understand that just adds to the
complexity of web development (and places evolutionary pressure on JS
frameworks).

A web app has to look and run well in a huge range of screen sizes and devices
and browsers. Android and iOS apps can target minimum versions of an OS or can
usually ignore devices older than a few years. Browsers can't break backwards
compatibility.

There is no common, prescribed tooling for the web like Android, iOS, and
Windows enjoy, for example. This is a trade-off. I think the web sees more
innovation and creativity as a result. But there's something to be able to
spin up Visual Studio or xCode without having to worry about researching the
trade-offs between 5 different approaches to tackle UI development.

Ultimately, I think JavaScript gets a bad rap, but the churn is intimately
bound to its role as the universal programming language of the web. The web is
no walled garden and it has evolved dramatically over the past decade. We
should celebrate that JS has been flexible enough to grow with it.

------
vbezhenar
I'm Java developer for the last 10 years.

I learned Java 1.5 back in the day. This knowledge is useful. I added some
syntax sugar over the years and Java 8 was huge release with lambdas and
significant standard library improvements, but old knowledge is relevant.

I learned a lot of J2EE libraries. Enterprise beans, Portlets. Most of this
knowledge is obsolete. But servlets and web services are still relevant.

I learned Spring and Hibernate back in the day. Well, Spring evolved a lot,
but basics stayed the same, so that knowledge is revelant. Same about
Hibernate.

All my JVM internals knowledge is relevant.

I learned Maven back in the day. Recently I switched to Gradle because it
seems to be better system, but Maven is not obsolete and I could continue to
use it. Though those systems are extremely easy and it's not a huge investment
to learn them anyway.

Recently I added Kotlin to my tool set. But this language is heavily based on
Java, so all knowledge about Java, JVM and standard libraries is relevant.

So yeah, Java is pretty stable platform and very few things were obsolete.
Most of my knowledge is stayed relevant.

JavaScript is crazy world. I have to dive into it once every few years.
Everything changing. My old projects don't have a chance to work with new
libraries (especially fun with dynamic typing). JavaScript really needs One
Big Architect With Beard who will make everything right for everyone to
accept.

------
peelle
Been doing back end for 13 years, and I try to visit a programming conference
or two a year.

I think on average back end churns slower. Every year I'll hit a conference,
and hear about the latest and greatest, but only a fraction of that stuff
sticks around, and gets integrated.

I believe most company's won't swap language/framework/libraries until
absolutely necessary. So the adoption of new things you might see at a company
is much slower than someone who job hops every 3 years.

The company I am at now, had a C++, cout << "<html>..." version of the site
for 6+ years. The version that replaced that is a younger language with a MVC,
but it's already been 9+ years since that was implemented, and it'll probably
be a few more years until anything else supplants that.

Another thing that I think affects front end is the browsers. I don't know the
stats, but I believe that Chrome/FF/Edge release more features, experimental
features, and bug fixes per year, than your average language, or OS. This
cascade of releases in turn effect front end code, and libraries. It's a wave
pool, not a ripple in the pond.

------
rajangdavis
I think javascript is changing more rapidly because:

1\. It's on the back-end and front-end.

2\. Lots of corporate sponsorship of Node.

3\. Adoption of other languages' functionalities (namely async/await from C#,
sets from Python, symbols from Ruby (could be wrong here), hash rocket from
Ruby/Scala).

4\. Teams building their JS libraries to serve the unique needs of the team
(Uber's fusion.js, React and Redux for Facebook, Google's
AngularJs/Angular/Material Design).

5\. Browsers converging on JS spec which allows for arguably more cross
platform development.

6\. Node is a "good enough" solution for managing IO when it was introduced
(hesitating to say perfect because Ryan Dahl has mentioned that he would have
done a lot of things differently and has introduced deno as means to correct
what he thought were the warts of Node).

------
Tiktaalik
I'm 10+ years as a game developer working largely in UI and I'm just learning
JS now to make use of a new framework built by Coherent Labs. Previously the
main tool set was Scaleform, which makes use of Flash scripting. I don't feel
game dev has changed that much. Only very, very recently has it started to
change at all.

In game dev land it's just C++ or C# if you're a unity shop, and things
haven't changed too much. For a long, long time things weren't different at
all, but with the new C++11, and C++14 things are getting a bit different.
Right now I'm working in a fairly modern codebase, and it's been a learning
experience for many of my coworkers to get up to speed on some of the new
features introduced with C++14.

Probably the biggest change is occurring with the way that games are
developed, with Object Oriented development practices kinda going away and
games being developed in a more Data Oriented way using Entity Component
Systems (ECS). Unity for example currently has an ECS system in preview
release.

It's been pretty interesting to start learning more of the JS ecosystem. Even
though I've only been working at it for a few months I've already had the tea
table upended on me by our partners deciding to redo some stuff in typescript,
so there's another new thing for me to learn.

------
LyndsySimon
My intuition is that it's a function of how many people are doing the type of
work you're doing and how fast the environment within which your code runs
changes.

Front-end JS is where both of these factor are at their peak - it's often the
first stack new developers use, and there are a _lot_ of devs doing it. Add in
the speed with which the browser landscape changes and the (relatively) recent
expansion of JS onto the server ... and everywhere else ... and you kind of
have a perfect storm.

The other extreme is probably something like legacy systems development - like
maintaining and expanding banking and financial systems - or embedded
environments where the hardware has a long life expectancy and is not easily
upgradable.

------
francisofascii
I had primary been a C# dev, then switched to JavaScript/TypeScript for a few
years. Lots of change in those years: JQuery, Angular 1, Angular 2,
TypeScript, etc. Then I recently switched worked on a C# project. Other than a
few Dot Net Core changes, it was basically the same, and easy to switch back
to C# land. Not I am back in JS land. This time using Angular elements. When I
left, I was getting used to declaring local variable with let instead of var.
Now local variables are not let, they are mostly declared with const, which
reinforces the notion that nothing is ever really "constant" in JavaScript
world :)

~~~
munk-a
Aha! And Angular is already one of those tech pieces that's "on the way out".

I've had similar experiences working primarily on the backend where paradigms
may slowly shift but the tools for their declarations are _thankfully_ pretty
stable.

~~~
mattlondon
I don't think angular is in the way out - there is still a lot of active
development on it with a lot of users. React and Vue have more mindshare sure,
but angular2+ is still heavily used as I understand it.

------
moron4hire
It's not really unique to JS. We've had framework churn for a long time in
lots of language communities. Look at Java and all the different desktop UI
frameworks and build frameworks it has. .NET has at least three, first-party
UI frameworks that are _still in active use_ , not to mention the dozens of
3rd party frameworks in the wild. Don't even get me started on Data Access
frameworks.

What is unique about the modern era is that A) there are a lot more developers
than ever, and B) it's easier to get a niche of other developers into
supporting your vanity framework project.

So if there were always going to be X% of developers getting behind any
particular project, A means that B hits a critical inflection point of N total
developers that make it achieve self-sustainability. Once a project becomes
self-sustainable, it looks important.

But going back to point A, all these new developers don't have the experience
necessary to evaluate whether or not a project is worthwhile on its own
merits, beyond "well, N number of people use it". For a long time, front-end
work was denigrated as "lesser" because it was typically done as an
afterthought, foisted on designers, not deemed "important" or "hard" enough
for "real" programmers (please note my use of weasel quotes to indicate I
don't personally believe it to be so, that's just how the development
community has treated it over the years). So, being treated as something of a
read-headed step child, the front-end community has lacked a certain level of
adult supervision that could help guide its growth in a stable, manageable
way. The "blind leading the blind", so to speak, out of complete necessity.

I guess it was a little easier in the late 90s and early 00s in that
businesses were much more reluctant to use open source code. It was a lot
harder to get buy-in on anything that "wasn't invented here". But that doesn't
mean there wasn't a lot of "invention" going on.

Your job as a developer growing to become a "senior" is to learn how to ignore
the churn of shiny new things and do what is right by your projects. This has
always been the case.

------
tobinfricke
I program in C, C++, and Python at my day job, and those languages are
pleasantly stable.

~~~
rabidrat
That's good to hear. I was worried that C++17 was a major revision to the
language. At least Python hasn't had a major release since 2010 (Python 2,
anyway).

~~~
antoineMoPa
Most places seem to use very old C++ versions.

~~~
aardvark291
The trick towards succcessful C++ development is to be very judicious in
picking the features that you use. So not jumping to immediately using all the
new features is a good sign.

------
acangiano
Assuming you're using well-established technologies, your knowledge doesn't
become obsolete as quickly. Not even close.

I can take a Rails developer who stopped using Rails 5 years ago and get them
up to speed in less than a week.

------
catpolice
I think the churn rate is higher with front-end stuff, but I don't think it's
really due to any special property of the technology. Honestly, I suspect that
the rate of change in a given ecosystem is roughly correlated with the number
of programmers actively working in it.

The number of front end web developers has been skyrocketing since the late
90s - a lot of people who've been in the industry for a while don't realize
how many more of them there are compared to 5, 10 or 15 years ago. There's
been growth elsewhere too, but just in the past few years the number of new
bootcamp front-end developers I've seen seems to sort of swamp most other
sectors.

I suspect that since much of the innovation in that space has been driven by
open source efforts, the amount of change is in part driven by the number of
eyes on problems and the number of people interested in trying new things.
There are a jillion new JS projects on github every month, and some of them
catch on, so there are always new options.

------
davimack
Basically nothing down in database-land has changed, from what I can tell.
Added features, but everything in those languages is designed to be backwards
compatible (unless you're talking PL-sql, which has had some major shifts, to
bring it in line with the rest of the world). And that's having done database
stuff since Paradox for DOS and Access 2.0 (I think - might have been 3, but
... ancient days, anyway).

For the rest of my stack, it's mostly Visual Studio, and it's shifted a bunch
over those 25 years: VB5 -> VB6 -> VB.NET until .NET 2.0 -> C#

Whatever changes there have been in HTML & JS, I've gone through, plus some of
the DHTML weirdnesses that came along the way.

I'm going to say that, other than databases, there's about the same amount of
needed change. And even with databases, those do change, in that you might
want to get a bit more of a life and use something other than MSSQL for a
change, which amounts to such a shift as the others have been.

------
munk-a
I think a big contribution to the rate of change of JS is that there is not
yet a division between frameworks that do display stuff and frameworks that do
utility/heavy lifting - this is partially due to the fact (IMO) that a lot of
systems isolate heavy/complicated logic (especially business specific stuff)
to a backend which JS queries to source data to operate over.

All of the current frameworks are intimately tied into display logic and that
display logic is constantly in flux with shifting trends, device/accessibility
support and shifting coupled technologies (css-flex, css-grid...). This lack
of an isolation is causing people to jump frameworks to capture support for
newer design trends and the like but... I think it's getting better. I'm not a
front-end dev but react is the first offering I've seen that seems to really
strongly reinforce a decoupling point between display and logic.

Really though, look at the realm of application development, in that realm
users are accepting of crazy out-of-date UIs so the sterotypical "Oh this was
definitely built with Java" (with substitutions for MFC and Qt) is sort of
accepted. So, I may be off base.

All I know for certain is that there was a period in the 00s when I was really
hopeful that all website design would be handled seamlessly by my designer
coming in and throwing some style-sheets on everything and no changes to
markup would be required - that time has passed and the responsive web is
baking in a really strong assumption of native-application-like functionality,
this isn't bad or good - it just is.

So, in summary, I'm still hoping that the majority of front-end work can shove
a crowbar between the declaration of logic and the rendering, but I feel like
the rate of UI change and shifting display thingies will forever outpace
attempts to provide a unified toolset that actually captures the majority of
intended uses.

------
ufmace
I'm doing Rails now, and I'd say no, it's just JS. Since Rails 4 was released
particularly, most things upgrade between versions with only minor hiccups.
The changes are mostly adding new modules to have a standard way to do various
common things, but the old ways generally don't stop working. You can upgrade
to the latest Rails and switch over to the new module, or not, at your
leisure. New Ruby versions come out pretty regularly too, and the changes are
mostly improvements on speed and memory usage, and addition of new syntax
types. I don't think there have been any breaking changes since Ruby 2.0 was
released.

I've worked in a few other languages, and I don't think anything else has the
vibe of rewriting your whole system around a whole new popular framework every
few years.

------
ummonk
The way of doing things in front end was rather crappy until 5 years ago.
Front end development was basically in development and not ready for
production yet until the creation of react. I expect it to slow down and
behave more like a mature framework / language now.

------
gfs78
Things are not changing that much faster. What changed was the business model
of software companies.

In a distant world the tools took years of closed work to get to version 1 and
version 2/3/4 each took a couple of years too. And in most cases what you got
was the whole package (Visual C++ with the C++ compiler, the IDE and MFC for
example).

Nowadays is all in the open in github or similar. Feedback and updates are
faster, community involvement is higher but things are less stable because all
the polishing (architecture, interfaces, etc.) is done, from the perspective
of the framework writer, "in production".

Basically is the agile business model of release early and often applied to
software tools.

------
nostrademons
All programming is constantly changing, but web front-end is probably among
the subfields changing _fastest_. It seems to have slowed down significantly
since about 2014 or so.

I've been programming professionally since 2000, and I'll say the biggest
change is actually that the _market structure_ has changed. Back then,
programming specialties were primarily divided by platform: you were a
"mainframe programmer" (probably working with COBOL, RPG, DB2, etc.), a "UNIX
programmer" (C, C++, awk, sed, perl, shell), a "Windows programmer" (Win32,
MFC, later .NET), a "Java programmer", a "Mac programmer" (Pascal, C, later
Objective-C, with the Mac Toolbox and later Carbon/Cocoa frameworks), an
"avionics programmer" (Ada, C, with a good knowledge of physics), a
"scientific programmer" (Fortran, Matlab, later Python/NumPy/SciPy), etc. The
idea of a "web programmer" was just getting started, and the technologies
(Coldfusion, ASP, JSP, PHP, Flash) were very immature, and largely outgrowths
of the platform you used to run the webserver on.

Sometime around 2009 every software system became a distributed system, with
multiple clients and a wide range of backend services running on different
boxes, and so specialties bifurcated by your _role_ within that ecosystem. So
now you have web front-end engineers, mobile engineers for Android & iOS,
back-end engineers, data scientists, data engineers, deep-learning experts,
infrastructure engineers, SRE/DevOps, security people, scalability/performance
experts, etc. You're even starting to get blockchain engineers, though they
don't fit into the current distributed systems model.

Some of these fields change less quickly than others; frontend (particularly
web), deep-learning, and blockchain have been changing rapidly, while things
like infrastructure, backend, SRE, and scalability change a little less
rapidly. All of them are changing, though. It's the legacy platforms like the
mainframe engineers and avionics engineers that haven't really changed much -
but the flip side is that the current hypergrowth in the software industry has
largely passed them by.

------
dec0dedab0de
Ive been using Django for almost 10 years, and it is still basically the same.
There have been some breaking changes betweem versions but they have all been
very easy to pick up. Even the python 2-3 nonsense has been relatively
painless.

~~~
astrofinch
Django has a strong focus on backwards compatibility and has seen steady
popularity for a long time.

------
singhrac
I'm a scientific programmer (not a ton of experience but understand history).
It's changed a lot over time but it feels like nothing was _much better_ than
writing Fortran / bindings to Fortran until very recently (of course, take my
recency bias into account). Yet, still, significant amount of "critical code"
are written in Fortran. It's a slow-moving world in part because there is a
lot of corner case complexity / significant logic. Parallelism in the form of
CUDA / transparent GPU via Python is changing that a bit, but some algorithms
are still not parallelizable.

------
ng12
Honestly, I don't think it's really changed all that much. I think
React/Vue/Angular/etc are confusing for people who don't write a lot of front-
end applications but honestly I'm writing the same code I used to write years
ago with jQuery except now it's a whole lot easier and more maintainable.

I think what has changed is a lot more people are writing SPAs (sometimes for
good reasons, sometimes for bad ones) and are shocked by the complexity. It's
like any other type of development: pick the right tools for your job and know
them well.

------
brightball
It’s the result of a language that already had 85% of the tools needed for its
domain where the changes in frameworks come down more to preference than
anything else.

The same thing happens in PHP world where you have all the tools needed built
into the language so most of the frameworks are essentially “arranging stuff”.

In other web frameworks for other languages, you tend to see them creating the
actual tools you need to use that language effectively on the web so it’s
easier for the community to coalesce around it than whimsically reinventing
things every day.

------
maxxxxx
In a lot of areas the tools are fairly stable and progress is more linear.
That’s what I liked about C/C++ development where you could go deep and really
learn details. The JavaScript world feels to me a little like reinventing the
wheel every few years and recreating the same thing over and over. Maybe it
needs a few more years/decades to shake out issues and reach some stability.

I think part of the problem is that JavaScript/HTML/CSS are so flexible that
it’s really easy to create new stuff.

------
doodpants
No, there are plenty of areas of software development that are much more
stable. Nearly 6 years ago, I took a new job to develop a Windows desktop
application using C# and WinForms. It hasn't changed much since then. There
have been a few updates to the C# language to add some syntactic sugar, and to
better handle certain niche concerns, but nothing that's had any major impact
on how we typically implement things.

------
halfnibble
The biggest change I can think of in my Python/Django development over the
past few years is: print "" >>> print("")

~~~
LyndsySimon
I don't necessarily agree with that, but it might be a matter of when I
started. My first Django projects were done with 0.96 if I recall properly.

Environment management has changed a ton - first with pip replacing
easy_install and directly using setup.py, then with a bevy of tools for
managing development and deployed environments (Vagrant, Docker, Spinnaker,
K8s, etc.), and nowadays with more advanced packaging tools like pipenv or
poetry. Along the way we've seen the maturation of CI and all of those
supporting tools - linting, style enforcement, and coverage all growing
rapidly.

------
ixtli
It's an illusion.

I think this is just one of the rare examples where people can't arbitrarily
roll their own new language because they're unhappy with bits and pieces of
C++ or Python. Consider that in the same span of time we have kotlin, groovy,
scala, elixir, erlang, r, go, rust, swift, etc., as well as many yearly
flavors of C++. Its just that every time someone makes one of these it
fractures the total attention paid to the the langauge/framework so they tend
to become niche and peter out.

Javascript, on the other hand, is 1) profitable and 2) chosen because no
matter what you really cant† choose a different language to do this work in
the browser. This has the effect of concentrating all work in a very specific
place. Image if instead of some people writing ruby, go, java, etc. you
combined all of their equivalents of npm into one giant thing that everyone
worked on all the time. I think it would look very similar to npm.

Oh and don't forget that framework development is not only driven by new
engineering practices and concepts, but by new features that get added by
Mozilla and Google like async/await and OffscreenCanvas. There's just much,
much more to whole ecosystem when you're dealing with modern javascript than
really any other language.

Also, Javascript is just LISP in C-style clothing so you also end up
drastically different programming styles (take, for example d3's style versus
jquery versus react versus three.js: all valid, all quite different and with
different requirements like webpack.) This maps rather directly to when people
made scala and groovy, imo. They're just like JSX/ES6+ but we consider them
all different languages as opposed to "lots of javascript."

† even here there are some attempts to do this with typescript and rust that
compile to restricted javascripts.

------
erichmond
Clojure doesn't move much at all. Python and Ruby seem to move a little, JS
does seem like it moves extremely fast.

------
andrea_sdl
Well, it's quite clear that JS is seeing a transformation at higher speeds,
but a the same time I feel like the backend offerinngs are now more diverse
and they do, too, evolve.

Spring in java is pushing somewhat on functional programming and lambdas are
now another way to work in java, which means you can achieve a some kind of
real func programming.

We have some beautiful newcomers like Elixir which are trying to fill a gab,
so yeah: I think the JS world does seem like it's going faster (and it sure
does until it reaches a "mature" state), but at the same time we have great
evolutions across all the stacks.

Obviously not everything changes, some things stay the same, that's because
we're looking at some mature technology and not the bleeding edge, but if we
look at the outliers, I think you could easily pick at least an innovator
around each backend language.

------
citrusx
You know, if you look at the current timeline, you'll see that much of the "JS
churn" has basically stopped. I mean, yeah - people are trying new things, and
products are being maintained. But, the landscape today is really very similar
to what it was a year ago.

Yeah, there was a sort of "golden age" of innovation where we went from jQuery
-> Angular 1 -> React, with Elm, Ember, and Angular 2+ as sidecars. And, the
common libraries and tools have also slowed down in the same way.

We've finally solved a lot of the big problems, I think. Advancement will
never end, but I think we'll be able to keep up with it from here on out.

------
mattlondon
Backend has changed hugely with the advent of docker, kubernetes, cloud in
general. Languages as well are changing a lot: golang, rust, hell even Java
started a new release cadence with new stuff (lambdas, streams)

You don't _have to_ move to the latest way if doing things all the time in
either front or backend. You do not have to follow the latest fashions. There
are loads of backend frameworks that no one remembers because
Django/ruby/spring became "good enough" and won, but back in the day there
were many competitor frameworks for what was then frontend development. But
we've largely forgotten about them all, as we will largely forget about the
current gaggle of js frameworks once something "wins" with a good enough
solution.

Tl;Dr - The way we develop frontend has changed from largely server side to
now being SPAs. Things will calm down in the coming years as one framework
becomes "good enough" and ends up becoming the de jour standard.

The knowledge and concepts never change though. What we're doing today in Vue
and RxJs etc is as old as the hills as far as computer science is concerned.

------
mike_ivanov
Sir, have you ever heard about Common Lisp? Here - please take home this free
brochure.

Edit: the "brochure" \- [https://lisp-lang.org/](https://lisp-lang.org/)

------
Scarblac
JS is unique in that it started out as really quite a bad language, but due to
external circumstances (the success of WWW browsers) it became the most-used
one.

So lots of people work on dealing with its warts.

------
guiomie
I used to work in .net, and found that it moved really fast also few years
ago. But I think the js world is indeed the craziest.

I've went from jquery, to angularjs, to angular2, to polymer and now for my
latest project I'm going no-frameworks JS. I've had enough.

Using Custom Elements (HTMLElements) is good enought for me, the latest ECMA
makes it easy to do string formatting in the render function. It's not
perfect, but I dont have to deal with all the pains of npm or webpack or any
other distraction.

------
dangerface
Front end javascript really hasn't changed. The newer native stuff is great
but you cant really use it without dropping support for anything Microsoft, or
writing a bunch of shims not good.

SPA is an anti-pattern, don't buy into the whole craze to learn hottest new
SPA framework which fixes all the problems with the last framework. They are
all trying to make an anti-pattern work, it wont and no gimmick will fix that.

Stop learning gimmicky front end frameworks and start learning front end
design patterns.

------
namelosw
Most of the languages are constantly changing but the JavaScript world is way
faster than anybody else moves.

Although might be over-hyped, I personally believe it's more a good thing
which moves the community even the industry forward. React was kind of
enlightened the functional and reactive patterns to the mainstream developer
community.

In contrast, most of the back-end communities still struggle with data
synchronization between microservices, while all modern front-end frameworks
are able to update all of the view or other read models almost magically.

If anyone wants a more specific example, I think it's quite shocking to me
that there are only very few back-end architectures knows clearly how to
design a whole large scale architecture push WebSocket notification for a
given user -- just like typical google suite stuff. WebSocket has been there
for years, there are so few people know how to develop and operate a stateful
service... unbelievable.

I agree with that shipping business functionality is the most important value
in technology. However, I feel most of the back-end communities worries about
the problems they are encountering too much. And they don't really care about
the art of the programming itself, yet advanced architectures indeed require
language or platform level construct, for example, immutable data structures
are much easier to be concurrent safe, or just the computation should be pure
to be safely rescheduled on other core or machine, etc.

In the front-end world, I think for example React and Mobx which I'm using are
pretty much taking care of most of the accidental complexity of software
development. In the back-end world, I can imagine something similar to a full-
blown framework like Rails but built on top of something like Orleans or
Lasplang would help us get rid of all the accidental complexity, and just
expressing the domain itself instead. We're still too far from there.

A quote from SICP lecture:
[https://youtu.be/2Op3QLzMgSY?list=PLE18841CABEA24090&t=81](https://youtu.be/2Op3QLzMgSY?list=PLE18841CABEA24090&t=81)

"And the Egyptian who did that, geometry really was the use of surveying
instruments. Now the reason that we think about computer science is about
computers is pretty much the same reason that Egyptian thought geometry was
about surveying instruments."

------
antoniuschan99
My professor in school (2008) said if you want a chill job in Technology you
should be a DBA because that changes the least compared to the other stacks.

------
carapace
Prolog proceeds at a stately (not to say glacial) pace.

------
tarabanga
> a ton of change to the very basics of how we work

I do data work on Python (20%) and R (80%). Of these,

\- Both base Python itself (2 -> 3 -> 3.6) as well as the major data libraries
(e.g. pandas) changed a lot.

\- Not base R but the major libraries (e.g. dplyr, ggplot2, knitr) changed
significantly.

So, for me, yes, a ton of change to the very basics of how I work happened
when using Python and when using R's newer libraries.

------
geodel
Using the terminology of Hardware, firmware, software where changes are
slowest in hardware and fastest in software. I suspect JS introducing
something which is even faster than software. May be called Slipperyware. By
the time one grasp it slips out and take form of yet another framework.

------
souprock
It's just with JS/frontend.

In 20 years, the change I've seen is very little. Pointers became 64-bit. C99
brought nicer initialization and the ability to declare variables after
statements. Optimizers got cruel, particularly with aliasing. Vectorization
and SMP can be put to use.

------
werber
I've been in Java shops and .net shops and PHP shops and the only constant is
js. I think ubiquity comes with turbulence

------
elamje
I'm not sure, I just want functional programming to become widely adopted <3

------
jaequery
it seems to me that the devs who been at it for a while, sees the frontend
landscape as huge chaos.

but the newcomers coming into the scene, seem to either love or embrace the
fast pace changes.

i'm not really sure what to think of this situation.

------
foobar_
Every 15-20 years everything changes, the new generation ditches the old,
repeating the same mistakes nth time but making some progress.

~~~
dylan604
2 steps back, 3 steps forward. Sometimes, during spring cleaning, you have to
make a bigger mess to get to a cleaner state than when you began. It's a
timeless issue. Continue to patch existing codebase with known flows that are
so severe that it will never allow for full completion, or scrap the whole
thing and start over using $newHotness that has the potential to get you where
you need to go?

~~~
foobar_
Yup. Rewrites are tricky but doable. I think the best way to rewrite is to do
it inside out, sorta like DNA replication or gradually move things into micro
services of sorts.

Porting however is more difficult IMO, like rewriting everything in Rust or
from jQuery plugins to React.

------
gcbw2

        Every programming language consistency is
        inversely proportional to the scale of adoption.
    
    
    

And by adoption i mean how popular it is with actual companies using it and
pushing delivery over code-quality, with an ever growing pool of junior devs.
Adoption as hobby languages or slim startups full of very experienced devs
doesn't count.

> PHP PHP is in usage decline (by the demographic outlined above). So it is
> getting more consistent (take a look at it during the 3->4->5 timeframe, you
> will think JS is moving slow)

> [ruby on] Rails This is even on a steeper incline than PHP today. So expect
> more consistency i guess.

> everywhere or

Java is always popular (it's the bread and butter of the demography defined
above!), and people make money selling IDE plugins (something hard to grasp
out of the java world) which accelerates the inconsistency. So it is always a
crap shot. A pile of incompatible concepts every time a new senior dev passes
trhu the project. Not to mention in the last years every project moved full
steam to scala and then back. So every 4yr you can see the same project and
not have any idea what is going on because they moved from ant to maven or
gradle, or rewrote half (only half) the project in another jvm language, or
now every method and class is full of never seen before toolkit annotations,
etc.

GoLang started as a nice perl/bash script replacement and is becoming the new
web application server as it gains adoption. Which was first bringing
consistency and parallelization to what used to be done with perl or bash, is
now full of weird ways to manage packages, which are mostly implementation of
web authentication and what not.

erlang is in sweet spot. Some bigCo uses it as hiring bait, and there is lot's
of smaller companies using it. There still isn't a mass of jr devs pumping out
features on erlang projects, so consistency is at an all time high. With
frameworks that actually add to the ecosystem instead of flipping everything
on its head for silly syntax sugar.

Cpp had a bump in adoption recently because of CND related projects and more
focus on ssl and things like that. So the new standard bodies are busy at work
churning in new things nobody asked for, but that so far everyone is loving.

------
patrickg_zill
Just the front end in general and JS.

I have code I wrote in TCL in 2001 that still works and runs in production
today.

------
ungzd
I have impression that other way round, changes in js are one of the slowest
amongst programming languages.

We have lots of js in our project, and it's mostly the same js as when I first
learned it in early 2000s. No ES6, because it's completely unsupported in
Android Browser and IE. Why bother with transpiling for just shorter syntax
for functions? We had Sprockets and I'm not sure if there's adequate
transpiling of ES6 for it. So, browsers are stuck with ES5 forever, does that
mean that JS is evolving fast? And ES6 itself is ancient, it was released when
iOS still had skeuomorphic UI.

On the other hand, while playing with IoT project I had to use C++ recently,
and it feels like entirely different language than 10 years ago. Even Ruby had
syntax changes in last few years, and lots of small standard library changes.

Maybe fashion and "best practices" in js world change frequently, but not the
language itself. Featurewise it's still on the level of Python 2.2.

~~~
schwartzworld
Obviously if you are deliberately avoiding new language features, you're still
going to be writing the same JS as you were in the early 2000s. I could write
Python 2.7 and it would be pretty much the same thing.

However, a lot of ES6+ features offer more than just syntactic sugar. For
example, arrow functions remove a lot of weirdness regarding 'this'.

~~~
ungzd
There's two javascripts: one that really works in browsers, and it's still
ES5. And other javascript, that works on abstract virtual machine implemented
inside Babel. And only the first one is "real" javascript.

