Ask HN: Is all programming constantly changing or just front-end JavaScript? | Hacker News Reader

Ask HN: Is all programming constantly changing or just front-end JavaScript?

131 pointssaltcod132 comments

I'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.

The way I do basic things has changed fundamentally in the last 4-5 years. Some of that is because I'm no longer a "beginner", but much is because things have just changed a ton.

People who know the JS / frontend ecosystem AND backend stuff as well:

Is this rate of change unique to JS, or is it everywhere? Is Rails very, very different now than 4-5 years ago? Django?

I use PHP a bit and I've seen that change a bit, but it feels like mostly for the better, with namespaces in particular. Otherwise, I don't feel like PHP has had near the amt of change that JS has had.

tl;dr: is it crazy everywhere or just with JS/frontend?

View on HN

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.

This has been about my experience too. Down to the exact technologies and years.

Same here! Though I never truly felt comfortable in Angular. React was a game-changer for me though.

This is similar to my own experiences.

During the past decade the JavaScript ecosystem had to evolve and adapt to handle increasingly more advanced requirements. Multiple tools and libraries rose up to meet the challenge, and the best ones have slowly floated to the top. It's not like the winning tools are even that recent: I think Webpack was already around before 2012, TypeScript was released in 2012, and, if I remember correctly, React was released around 2013. Fun fact: babel was called 6to5 when it was initially released.

Webpack can sometimes be difficult to configure because the problems which it sets out to solve are also complicated. To be fair, their old docs were quite lackluster, and the creator's coding style was uncommon, which made reading through the source a bit challenging. I know a lot of people are critical of Webpack, but I was overjoyed when I first discovered it, as it enabled me to correctly solve a huge number of issues. Once adopted, it let me drastically simplify our build pipeline, as well as our development and testing environments.

I can sympathize with non-frontend developers because I also feel overwhelmed sometimes when I look at all the tooling related to backend / devops / infrastructure stuff. But I understand people build and use these tools because they're usually solving fairly complex real-world problems. I suspect that many people that complain about JavaScript don't care much about the frontend and they just want to get it out of the way as quickly as possible. They want to pick up whatever standard tools the community has centered around and hammer together something without having to dive in too deep. If the developer looks down on frontend development and they encounter a difficult problem which they're unable to solve, then they must deal with the cognitive dissonance.

To give a concrete example of something I've struggle with: I can barely make sense of the containers ecosystem. Using docker-compose during development to bring up an application's external dependencies is amazing. However, I generally haven't had much success configuring and using docker to run an app locally. There's always performance issues, or I can't get something to work correctly, or I can't figure out how to get a good workflow going. Since we're on the topic: if anyone knows a practical example of a regular web app (e.g. rails or node, but I'm not picky) which has a few workers and which depends on a few services (e.g. Postgres, RabbitMQ, Redis, MinIO), I'd love to check it out. Oh, and I haven't even mentioned deployments and Kubernetes, which seems like a whole nother dragon.

If you're not a fan of frontend development I'd suggest using server-side rendering with occasional scripts dropped in for extra functionality. Think carefully about your application and its requirements; not everything needs to be a Single Page App. Depending on the kind of application you're building, you might want to evaluate next.js [0] and create-react-app [1].

[0] https://nextjs.org/

[1] https://github.com/facebook/create-react-app

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

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

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

Programming is a lot like playing a guitar. You can play old songs forever, but you can’t fairly complain that they went out of style. Plus like guitar, your skills at playing one genre don’t directly translate to another so if you want to keep up on the trend threadmill it takes a lot of extra practice.

Can you elaborate on your backend changes? I've been doing django for 10 years and still am. So for me, the biggest server-side change is dev ops, cloud, etc.

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.

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"?

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).

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.

What do you think is problematic with Webpack? Or do you think it will simply become unnecessary at some point?

I like your advice to avoid Webpack and prefer TypeScript, but I think the advice to lean away from JS in general is poorly-founded. JS is a powerful, portable language with lots of opportunities to add value. It’s a good language to have in your toolkit along with others, and you can make a good living by learning to write good JS programs.

That is true. I meant it as in: ‘If you can avoid writing something in JavaScript, do so’. Obviously, there are contexts where it is the only game in town — I have big hopes for WebAssembly for that reason.

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.

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.

Webpack works well without any configuration.

The nice part is you can do advanced stuff with it if you so choose.

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

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).

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.

> 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.

> Configuring it is a giant time suck.

But Webpack is such a time saver once configured.

Same goes on when you have to setup a Docker and some chef/puppet/ansible scripts.

This is why I just use create-react-app and never bother to configure webpack manually. Create-react-app is getting better these days and I haven't found any reason to eject yet.

Webpack is virtually indispensable, it has a poor reputation because the docs weren't great in v1.x and because it takes some effort to understand and configure correctly. When it's configured it's rock solid and it rarely needs touching again.

I have this theory that people dislike it because that complexity comes front loaded - the most fun part of any new project development is right at the start and if you're spending time setting up webpack then the developer perceives that as frustrating time wasted rather than an investment in the project that pays off long term. A big part of create-react-app's success is because it means the developer can get started right away and not have to worry about that.

About web pack and many others:

I use Vue with several others dependencies. But 0 package managers.

This is mine:

    cat js/vue.js js/vue-router.js js/vuelidate.min.js js/validators.min.js 
    js/vuex.js js/vuex-i18n.umd.js js/translation.js js/vue-moment.js 
    js/vue-virtual-scroll.js > js/build.js

0 problems. Predictable, not folder with millons of little JS files, etc...

What about Babel, JSX? I'm a C++ dev that's trying to learn JS.

As I know if you want to use modern JS you have to compile it with babel to "portable" JS with Babel.

And it was really painful to create DOM elements with createElement and small wrappers around them, so JSX should help here.

Or you can just skip those?

Listen to the pain. You can skip JSX and Babel. As I’ve mentioned before, Vue obviates the need for both.

Libs are all ready to use, you don't need to compile them with babel.

And for stuff you write yourself, they'll only need babel if you (a) want to support some ancient browsers (e.g. IE7), or (b) you want to use fancy new JS features.

If you're OK to target 90% of the people with actual browsers from 3-4 years ago, then you don't need Babel at all (at least not for that).

Are you able to use vue components? I would love to see how you manage your app js code with this approach.

I have a single JS file, not vue components. Is still possible, but then my DIY build.sh need to be more complex.

Still, the main point is that you can bring as much extra machinery as needed, instead of bring all then only use a fraction.

Does Vue + TS remove the need for Webpack? Which one creates the JS and CSS bundles?

You technically don't need bundles for Vue. It can be inserted in a plain script tag and work with other tags on the page. You can even do components that way and import them with a script tag. CSS can be done the old fashioned way too. Vue's nice like that. It's easy to not use a bundle or to use one depending on what you'd like to do.

Which production-ready options do you see for frontends without JavaScript?

None yet, unfortunately. I expect the first ones to come out of Go compiling down to WebAssembly.

We'll need a new toolchain -- wasm debugger support in the browser, especially. (I love your username.)

Why languages that compiles to JS won't apply? Let's say Elm for example?

Still I am too excited to see rise of traditional non-specialized languages to web game with webasm like Blazor (C#/.Net) but yep not production ready.

You went from "JS changes too much" to "If you use JS, use these hot new frameworks / libraries" (Vue, avoiding Webpack) ... which I think underscores the constantly changing nature of frontend.

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

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.

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).

JS is not backwards compatible? Where?

JS the language probably is AFAIK. I and many others in this thread are talking about the JS ecosystem.

> 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.

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.)

I would say JavaScript backward compatability is one of its biggest sellers? Babel transforms almost any new language feature to be backward comparable with much older specifications

I agree that backend languages are stable and the new shiney ones are less frequent to emerge and more conservatively adopted but... within the languages themselves things are changing quite a bit, 7 years ago PHP was at version 5.2 and lacked any support for non-string defined functions (i.e. we had to do stuff like

  create_function('$a,$b', 'return "ln($a) + ln($b) = " . log($a * $b);');

since that point there is now actual support for anonymous functions, greater namespace support, typing...

So over the past few years we have had a great improvement in the toolset we have to work with, but, to the other half of your point, we're mostly working with the same groups of tools, they're just better.

> would argue that the frontend js changes are mainly to do with user expectations for what constitutes a well designed user interface

Are those expectations met though? I have yet to see a fast and delightful user experience in a SPA.

* 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.

> * 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.

> 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).

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.

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

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.

I agree with pretty much all of what you said. One thing I might change though, is that I'd prefer a copy-on-write (COW) metaphor for WebWorker and SharedArrayBuffer, similar to how Clojure state works. So you'd pass an array by value, but there would be no performance penalty unless values are mutated. I'd also like to eliminate shared state between threads and switch to channels like how Go or Erlang work. These should also be COW.

I feel that HTML/CSS is an evolutionary dead end. People think in terms of tables when they do desktop publishing. So forcing them to translate to CSS and back is a task for compilers, not humans. Most people working in web development today are too young to remember that this was all a solved problem in the 80s with WYSIWYG. We let the asynchronous nature of the internet determine the architecture of our markup, which was a mistake in hindsight.

I'd vote to rearchitect the web to be synchronous and run under a single-threaded runtime that makes no distinction between front and back end. Then let the runtime handle representational state transfer, a bit like Rsync but for the DOM. This would work like virtual memory (so the developer wouldn't have to worry as much about where state resides) and executation would block until a remote procedure call (RPC) is lazily evaluated deterministically without timeout or having to remain always connected.

Then with that prerequisite implemented, we could revisit fluid layout in a formal way, derived from first principles. This might mean transpiling things like SCSS variables to non-turing complete grammars (context-free grammars) like CSS. I'm a little foggy on the terminology for this so someone please correct me if I have it wrong.

In other words, we should be able to derive the position of our elements from other positions. So we should have a markup language like:

    elementX.center.x = body.center.x
    elementX.width = body.width/2
    myX = elementX.right
    elementY.left = myX + 1

But this would only be processed in one-shot mode. I think a markup like this could be created on top of HTML/CSS but it could be difficult due to quirks.

Without basic metaphors like these, web development can never move from being a craft to a field. It will forever be reduced to hand waving and having to drink the kool-aid. Which is fine for now, but will add increasingly more friction as the web development market gets more saturated.

"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

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.

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 :-))

>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.

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.

I think jQuery and IIFE/AMD modules are fine. Tools for the job, React might be overkill for some smaller apps, and jQuery is a hassle with larger SPA/PWAs.

But why bother with jQuery? Vanilla is pretty decent.

Prefer React/Vue for the big stuff. But you can't beat vanilla when you need perf and control.

As a backend developer I am in the "jquery is fine" crowd =)

I'm always able to accomplish what I need without a lot of headache, though I'm not making gigantic SPA frontends.

There are very few people using go and rust for website backends. And kubernetes and docker are about deployment, not development.

If you are a backend developer, working in Ruby/Rails, or Php/Laravel, or Python/Django, or whatever, then I think you have a more than sufficient set of tools to do what you need to do, without worrying about much outside of that. It's a much more sane and stable experience than trying to be a frontend JS dev today.

> hearing about go, rust, kubernetes, docker, etc make it feel like backend is similarly fast-changing.

That's just hacker-news discourse. As for go and rust, backend programming languages aren't changing very much for most people. Python and Java are the most numerically significant languages and the experience of being a backend engineer in those languages doesn't change rapidly. (Python has just spent about 10 years releasing v3 and, while it is a great thing, honestly the difference that will have the most impact on peoples' brain-time is that you can interpolate variables into a string from the local scope using an 'f' prefix, and that `print` now requires function call syntax.)

Backend infrastructure is exciting and subject to radical change, however.

Yes, things are changing rapidly everywhere on the stack, but it seems that with front-end dev the same two things are left behind with each generation: performance and accessibility.

Each time we get close to making performant and accessible web sites easy for mortals to develop, some major disruption in the force occurs and well-crafted solutions no longer work in the new environment. So people reinvent them, poorly, and it takes another four or five years before things catch up.

I think many designers and developers prioritize their own needs or preferences and fail to advocate for what users really want. No user wants a web site or app to take 10 seconds to load on their phone, yet most do. Users don't care if your app is written in React, Angular, or served from a WordPress site. They just want to be able to use it.

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.

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

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.

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.

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.

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.

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).

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.

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.

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 :)

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.

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.

Angular is not on the way out, at all

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.

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

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).

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

I managed to get approval to bump my group up to C++11 a couple years ago thanks to some significant new features in the STL like usable smart pointers. So far none of the successive standards have offered anything sufficiently worthwhile to move us off C++11. It's possible that a new standard will introduce a killer features, but I wouldn't be too surprised if we simply stayed on C++11 forever.

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.

> At least Python hasn't had a major release since 2010 (Python 2, anyway).

I'd argue PEP 484 is possibly more transformative than the change from print 'foo' to print('foo')

https://www.python.org/dev/peps/pep-0484/

Aren't those entirely optional?

You'd think so from the PEP, but the amount of drama it has created is off-the-charts

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

True that, I had a load of code in 2.7 which I was dreading migrating to 3, but pretty much that change sorted it.

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.

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.

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

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.

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.

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.

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

Edit: the "brochure" - https://lisp-lang.org/

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.

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.

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.

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

"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."

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.

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

> 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.

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.

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.

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

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

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.

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

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?

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.

    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.

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.

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.

I understand where you're coming from, but you're basically talking about interpreter support here - not the language.

This would be like me taking the old Borland 4.0 C++ compiler and then telling you that C++ is SO slow to change. It hasn't moved since 1994!

Which is wrong. The language spec has clearly updated. ECMAScript is not defined by browser support, even if you should be taking browser support into consideration before choosing tooling.

Just because you're not choosing to use new language features doesn't mean they don't exist.

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'.

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.

Reply on news.ycombinator.com