Ask HN: Is all programming constantly changing or just front-end JavaScript?
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?
138 comments
[ 4.4 ms ] story [ 226 ms ] threadEnvironment 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.
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
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).
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.
We are still talking about an order of magnitude or more (5-10 years of stability vs months.)
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.
Are those expectations met though? I have yet to see a fast and delightful user experience in a SPA.
(I realize this isn’t backend dev, but there are other kinds of programming besides web development :-))
I mean, the same is true for any webpage written using JS + html + css in 2006.
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/
I think part of the problem is that JavaScript/HTML/CSS are so flexible that it’s really easy to create new stuff.
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.
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 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.
These are real, tangible performance benefits, so I'm going to need some kind of compelling evidence as to why avoid Webpack.
I'm a big fan of Parcel for 90% of the things I do. It just works.
The nice part is you can do advanced stuff with it if you so choose.
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).
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.
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.
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.
I use Vue with several others dependencies. But 0 package managers.
This is mine:
0 problems. Predictable, not folder with millons of little JS files, etc...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?
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).
Still, the main point is that you can bring as much extra machinery as needed, instead of bring all then only use a fraction.
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.
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.
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.
Prefer React/Vue for the big stuff. But you can't beat vanilla when you need perf and control.
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.
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.
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.
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.
The "Why JSX?" on React's docs covers this with more detail: https://reactjs.org/docs/introducing-jsx.html#why-jsx
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.
I have code I wrote in TCL in 2001 that still works and runs in production today.
Edit: the "brochure" - https://lisp-lang.org/
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.
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.
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.
However, a lot of ES6+ features offer more than just syntactic sugar. For example, arrow functions remove a lot of weirdness regarding 'this'.
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.
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).
Porting however is more difficult IMO, like rewriting everything in Rust or from jQuery plugins to React.
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.
https://news.ycombinator.com/newsguidelines.html
* 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.
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.
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).
> 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.