Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: I'm away from the software industry since 2017; what has happened since?
249 points by lohengramm 35 days ago | hide | past | web | favorite | 233 comments
I used to work as a programmer. In 2017, I had to stop working because of health issues. I remember Rust was a cool project, JS had plenty of frameworks fighting between themselves, SPA was a thing albeit I was skeptical of it, and I was in love with Go. Big words like Data Science and Machine Learning were thrown everywhere. Whas has changed in this scenario? Are there new stuff I should know about? Thanks.

Probably the most surprising thing for you: Go is getting generics. No exact timeline, but it's happening for Go 2.0.

Rust is seeing production use in many places and its being accepted more as the sane alternative to C for modern development of high performance software. Ecosystem still not big or mature enough to make big waves, however, but that depends on how you interpret "big waves".

SPAs are used and abused, the tooling to make a performant progressive website with them has gotten better but the know-how is not widespread enough.

React has essentially won the mindshare battle and they are focusing more on functional components. But there are other things with their own healthy niche like Svelte compiling components that manage their own DOM, Elm is still around (and still not 1.0) and it has inspired other "Elmish" frameworks.

Desktop software quality has gone downhill and seemingly everyone is using Electron.

For many companies, Kubernetes is the new normal mode of operation. You should know it, but it's still far from "the way to do things" for industry in general, mostly due to its complexity and learning curve.

>React has essentially won the mindshare

Casually job hunting right now, and it is insane how much React has won to me. Like I knew it was popular, but it seems like it has an outright monopoly with the remaining 5% of market share being split among all the other alternatives.

I don't know what the actual market shares are, but when looking at open positions around the US from coast to coast, it seems to have won.

> I don't know what the actual market shares are, but when looking at open positions around the US from coast to coast, it seems to have won.

React is currently in it's honey-moon phase, but many of its warts are starting to show. It probably has another year or two before peaking, but doubtful that such a large heavy-handed library will remain dominant forever.

Honeymoon phase was like in 2015. Were way past that today.

Also doubtful? What about Java?

>Rust is seeing production use in many places and its being accepted more as the sane alternative to C for modern development of high performance software

Not quite there yet.

Not quite where yet? It's seeing lots (albeit quiet) of production adoption, and it's still growing.

Viewed from here, Rust has far less penetration than Python did in (say) 1995. I see more Julia than Rust, for example.

Whatever its benefits, Rust remains quite obscure for now.

Probably more of a compelling alternative to C++, and not as much so for C (yet), from what I've read so far.

I'm not sure it's even a compelling alternative to C++ at this point. The borrow checker is sometimes unpredictable and hard to reason about and the language syntax is not always consistent. I think we will see more adoption in the future but there are reasons why it has not been adopted as much as one would have expected.

Yes. Besides being distinctly more like C++ than C, there are other less complex languages (zig comes to mind) that are contending for that area.

>React has essentially won the mindshare battle

I'm looking to learn a front-end framework and had a few people recommend Vue. Sounds like maybe I should go for React instead? In case it matters, I'm not looking to be a front-end developer. I'd mainly like to improve some small projects I have. And get the most value out of my time learning a framework.

At my company we decided to go with Vue and not React about a year ago, mainly to avoid the complex tooling that React absolutely demands that you add to your JS build process.

And we still like Vue a year later. It integrates well with the rest of our site, much of which still has not been rewritten in the functional-reactive style yet. And not having to do a full-on transpile/build step during development is a huge win for reducing cycle times.

As a backend developer who makes frontends for his projects, I enjoy Svelte. I found React to be quite complex when I tried learning it last year.

I’d use vue if not for svelte, probably.

I'm in the same boat, and also love Svelte and wish it success.

Svelte's reactivity was also something we had in Splash, the Microsoft-internal UI framework that was used to build the Zune desktop app and Windows Phone 7/8. I haven't enjoyed building UI since then, but with Svelte I can finally enjoy frontend development again.

Found svelte 3 after Rich's talk and managed to complete a production app using it. Found it not only a lot easier, but almost flawless.

same here - using svelte in production and it rocks.

Vue is definitely a better framework, and for built for larger projects (performance)... but React got the first mover advantage after angular abandoned it. ¯\_(ツ)_/¯

The Vue bubble is a real thing.


Vue will be much more understandable. I've used both pretty extensively (React at work and Vue at home.) and I like both. React definitely feels more complex but there is also a lot more OSS to pull from.

One thing I don't like about React is that there are so many ways to skin a goat. We write functional components, and while I like them, this instantly makes half of google search results at least slightly irrelevant. However Vue is kind of doing this as well with the Vue 3 syntax change with backwards compatibility.

having done both vue and react on various things for the last few years, we ended up choosing vue for all future developments. But React is definitely way more popular ( and more marketable) they both can be used for large and small development. The upcoming Vue 3 is looking like a good progression too.

React itself is nice and simple, but all the cruft needed to run it is a bit off putting. If you’re happy to have a meg of app code you can build great things though.

Depends on what kind of project you're doing. Vue is still great for smallish projects, but if you're looking to make yourself marketable React is the way to go. For future proofing yourself, it might be worth looking into webcomponents as well. Likely there wont be anything built using them directly, but there are a bunch of new frontend frameworks that utilize them (stencil for instance). Next gen frameworks will highly likely take advantage of shadowroots and other parts of the spec under the hood, so it might be worth understanding that stuff now.


For resume building + career growth -> learn react

For quick and dirty side project -> use vue

For future proof / bleeding edge understanding -> use webcommponents

Go getting generics is definitely surprising. I used to even argue in favor of Go the way it is.

If there's one thing I got from these responses, is that I should look at Kubernetes.

Thank you for your answer.

Haha yeah, I remember y’all going on and on about it. That’s when I realized how many syndromes there are in Stockholm

Kubernetes is the thing everyone will be moving away from in the next 5 years because it was too complicated for their purposes.

The unfortunate ones that don't manage to move from it will be maintaining 5 year old kubernetes installations.

> Kubernetes is the thing everyone will be moving away from in the next 5 years because it was too complicated for their purposes.

Kubernetes solves a huge variety of problems with a single platform. In five years, Kubernetes will still be around, but there will be layers built on top of it that simplify common use-cases.

Kubernetes solves a huge variety of problems, as well as introduce new ones. Kubernetes is great if you need a scalable infrastructure, but currently, every mom and pop shop wants to ride the Kubernetes train.

The main problem comes when something breaks and building another abstraction layer on top of it won't help.

Oh, it'll be around, that's for sure. Like Cobol.

How popular is React?

I haven’t done much web development in several years myself.

Typescript is mentioned a lot on HN. Saw ReasonML mentioned recently. Vue.js has a movie on the way.

As far as Web frameworks go, what’s popular seems to change every couple years.

I think the reason React isn’t mentioned that much is because of how de facto its dominance has become.

The smaller-community frameworks are mostly interesting because they’re not React (i.e. they purposefully target different scopes, niches). The de facto standard framework for component-oriented front end development has been React for a while now. Typescript (which you see mentioned) complements react, it isn’t a component framework that aims to replace it.

React hasn’t lost any significant steam. You’re far more likely to get a job at a non-tech-centric company doing React today than you were.

Why kubertetes vs docker? And why rust vs D or golang ?

My God does Kubernetes sometimes feel like using a cannon to remove a zit.

Ha! I realized this yesterday after considering it (very briefly) for a home lab deployment—I’m pretty sure I dodged a cannonball on that one.

Docker-compose with nginx-proxy should work well for home labs.

You may also use Caddy instead of Ngnix. It's way easier to set up and customize.

Until it's not just one machine. You might briefly then use Swarm... But does anyone for long, whether production or home?

K8s has its complexities for sure, but to me it's the simplest - or at least 'only figure it out once' way of running multiple machines (besides having 'the webserver', 'the db server' etc., of course.)

I feel like there should be a better thing than kubernetes. In theory it’s simple, but in practice it’s so convoluted!

Yeah, that’s the plan I went back to when I realized I was way off track!

I can agree on this :p

> Why kubertetes vs docker?

Docker is for building a computer program to run on a single computer.

Kubernetes is for building a cluster, often across many computers with many programs.

They work together.

Kubernetes still almost always uses Docker as the runtime. Docker was late to the party with all the other stuff Kubernetes does. With Amazon, Google and Microsoft all offering managed K8s and Enterprise private cloud offerings too, I don't think unseating K8s as a management plane for cloud-native microservices will be trivial, even if the tech is immature and has valid criticisms.

Kubernetes and Docker (if we're talking about Docker as CRI, most often this is implicitly assumed) are totally different things.

"Rust is making waves!"

Rust ranks lower than Delphi on TIOBE, isn't used in a single aerospace, defense, or critical application. Ada has been for almost 40 years, is backward compatible to Ada '83, and has a proof subset (SPARK).

Those waves look more like pond ripples caused by a light breeze.

How about, "Rust - now with bigger pond ripples."

Didn't the comment you replied to say specifically the opposite of what you quoted?

If you take the time to read about it, you'll quickly realize TIOBE is pretty bad.

What index do you suggest instead?

To start with, I would try to fix the list here https://www.tiobe.com/tiobe-index/programming-languages-defi...

as well as adjust the query for programming-specific engines like GitHub. To have a programming language index not even consider github or stackoverflow as primary sources makes it a laughing stock IMO

The most interesting developments have been in infrastructure.

AWS has started to take on third-party, open source components e.g. Cassandra, ElasticSearch, MongoDB as they run out of things to build. Expect them to continue further up the stack possibly into applications.

Kubernetes has really taken off with every cloud provider having a solid implementation. And it's getting massive adoption within the enterprise as companies look to reign in their cloud cost, simplify their infrastructure and have better DevOps. It also allows them to standardise the NFRs across multiple applications e.g. metrics, logging, security, routing which is more important than ever.

Data Science has seen massive adoption in the last few years within the enterprise space as companies go after the low hanging fruit. Also seeing lots of traditional Data/Reporting Analysts been cross skilled in Data Science and vice versa. It's definitely here to stay for the long term just without the hype.

>"AWS has started to take on third-party, open source components e.g. Cassandra, ElasticSearch, MongoDB as they run out of things to build."

I'm aware of their Elasticsearch and MoongoDB offerings but what is their Cassandra offering?


Oh sure but that actually predates Cassandra. The Dynamo white paper is one of the things that kicked off the NoSQL movement. In other words it's not something they created to "take on" Cassandra.

Perf is becoming more important than it had been. Rust is still around and growing. WASM is becoming mainstream. You see some people migrating away from things that require garbage collection. Edge is becoming real, with Cloudflare and Fastly doing edge functions/workers, and AWS having come out with outposts, local zones, and wavelength (deploy AWS VMs to Verizon 5G hubs).

AWS is still eating the world, Azure is doing well and growing faster in enterprise markets but devs still hate it, GCP seems mainly startup and ML loads and they have an ultimatum to become top 2 or bust by 2022.

Open source is a little under fire. AWS made a closed source MongoDB clone. I feel like things have moved a bit away from DIY toward settling on whatever the big three provide.

JS framework overload has settled down and it's pretty much React and Vue. NoSQL has too, there's still mostly the same players as in 2017 but I'm seeing far fewer new entrants. In general I'd say things have slowed down as a whole, and the level of innovation isn't what it was a couple years ago. Shiny new object fatigue has set in a bit and people just want to make things work.

Docker in production is very real (our team uses docker in production only, not dev), and k8s has the mindshare.

ML is still fairly hot, but various experts saying we're starting to hit a wall wrt ML capabilities, and others saying plow forward and see.

> WASM is becoming mainstream

Really? While I've heard of a lot of experiments and a few companies using it in production, I'd hardly call it "mainstream".

You're right. I work in the WASM field, so it probably seems more mainstream from my bubble. It would be more accurate to say it's stabilizing and has reached a point where various orgs are rallying around it as a real thing and starting to build stuff around it.

> I'd hardly call it "mainstream" Agree, coworkers tried to use this for a project, 10/10 not ready for prime time. Basic tooling is missing, how does one perf/profile within wasm itself? We got stuck with plenty of issues.

>Perf is becoming more important than it had been

My eyesight is becoming worse, but I read that as Perl

I like Perl, but it's had a bit of an identity crisis since Perl 6. I believe late last year, they renamed it to Raku as a 'solution' to this identity crisis. I still think Perl can get the job done in a lot of different circumstances and, despite the fact that it's not really used as widely for web tooling as it was in the late '90s, it's still an invaluable scripting tool for sysadmins still willing to dip their toes in and learn it. As others have noted, the 'shiny new toy' effect has made Perl less attractive, but I think Perl has unfairly gotten a bad rap, especially in regards to opinions of how 'ugly' the language is - I tend to think it's more elegant than ugly. And of course, any programming language can be ugly - all depends on how clever the programmer in question wants to be.


Perl came as a reaction to the Unix tooling that was awk regex and all that jazz. It was designed to replace those tools and it did a good job at that. Times have changed, however, and perl no longer fills a function. We have python now, which surpasses perl in functionality.

What functionality does Python have that Perl doesn't?

I'm legitimately asking because I'm pretty sure there is almost no functionality in Python that isn't in Perl.

In fact of the features I've read about that changed between Python 2 and 3, all of them remind me of a change in Perl. Except Perl didn't break old code in the process.

> GCP seems mainly startup and ML loads

BigQuery is hot everywhere (I'd rank it as by far the most valuable GCP product). Tons of enterprises are AWS except for when they replicate their entire dataset from S3 to GCS so their BI teams can use BigQuery.

>Perf is becoming more important

Should look at BPF/eBPF. Mainly bcc & bpftrace packages that come with ~70 tools out of the box.

If you're still suspicious of SPAs, you can be sure there's still an alternate universe outside of the Valley bubble that builds server-side web apps on modern frameworks, though now we use Vue.js instead of jQuery. PHP has continued to be a top language of choice for the working class dev, and Laravel is an example of one of the most beautifully crafted (and wildly popular) web frameworks ever made.

Examples of the kind of tooling built by the community that betrays the cultish appeal of Laravel (yep, people actually make a living off Laravel-specific tooling)

- https://tinkerwell.app/ - https://laravelshift.com/

> language of choice for the working class dev

What an incredibly strange framing.

So are you implying that you're not filled with the spirit of the proletariat when you program in PHP?

I certainly feel like the bourgeoisie when I use Rust or Haskell.

> I certainly feel like the bourgeoisie when I use Rust or Haskell.

I feel like a peasant sharecropper when I use Java.

That was my initial reaction too, but then I found it hard to disagree with (in the general case of course) and instead thought maybe it's an astute and interesting observation.

The more familiar slight is that it's 'the language of choice for script kiddies', but I suppose they've grown up and gotten apprenticeships.

I just don't know what separates the working class developers from the "other" kinds of developers. I'm a 9-to-5 working developer, and I don't use PHP.

Well, in the most broad - but applicable 'enough' - sweeping generalisation I can think of: a degree.

I think the implication is that PHP is a language that has been accessible to those who didn't join the programming profession via the traditional academic route (CS, CE, EE, or Math degree from a University).

And that's pretty well borne out by its history, and is part of PHP's enduring appeal to many people who don't have formal educational backgrounds in the computing sciences.

I wonder what it is about PHP that has led to this and whether you could recreate it in a new language without the historical inconsistencies and traps.

Some combination of:

- fully interpreted

- very weakly typed

- highly applicable to a broadly desired use case, i.e Personal Home Pages (hence the name PHP)

It's not too different from what made Excel such a broadly accessible and impactful 'programming' tool.

> though now we use Vue.js instead of jQuery

You realize Vue.js is fundamentally an SPA framework, right? It's got built-in router, state management, etc. In frontend dev, those are all things that are only SPAs really need.

To people "suspicious" of SPAs: are you suspicious of Gmail? Slack? Those are typical use-cases of SPAs. What you're actually suspicious about are ill-informed devs building SPAs when they should be using simple static websites, or server-side includes, or simple progressive enhancement in vanilla JS. But none of those options are practical if you want to build something like Slack, GMail, or Google Docs, or any of the myriad other desktop app replacements we find now on the browser.

All the said, I agree that Laraval looks like an attractive framework. I haven't had the chance to work in it professionally, and probably never will, but it looks solid and with the improvements PHP is making as a language, probably would be totally tolerable and perhaps even enjoyable to work in.

EDIT: Ok, the router and state management are official, but not built-in. Fair enough. I've not used VueJS professionally before (only React, AngularJS, Backbone, and custom frameworks before them) but it's one of the appealing things about VueJS compared to React, which seems to be its major competitor presently.

Vue has an official router, but it's not built in and usually something like Vuex is used for state management. I'd certainly agree Vue is oriented towards SPAs, but that's not all it does.

Vue is much more 'batteries included' than React, while also being incrementally adoptable. IMO this is why it's popular with the jQuery crowd.

> IMO this is why it's popular with the jQuery crowd.

I had no idea. I've only used React, Angular, Backbone, and custom frameworks at work (mostly React in recent years), but I like what I've seen of VueJS because of its "batteries included approach" (which is React's weak point, although they seem in some ways to be moving toward being a full framework).

VueJS seems about as different from jQuery as you could get. I mean, it's even got a virtual DOM.

The closest thing you could get to jQuery? Modern, vanilla JS, whose recent APIs were often inspired by jQuery. But the jQuery crowd vehemently rejects that option because their idea of vanilla JS is stuck in the year 2010.

The reason why Vue works well for jQuery devs it’s because it allows you to continue doing what you’ve always done: server render then enhance on the client. Vue does this beautifully by accepting rendered HTML as its template. This means you can augment regular HTML and get the benefits of React without transpiration of JSX, nor the cumbersome nature of string templates in script tags. That’s where the jQuery comparison comes from, and it’s one of the major reasons for Vue’s success in that crowd. It’s a feature that doesn’t seem to get enough attention from/is often overlooked by those in the know because usually those people are writing SPAs.

Yup - Laravel is fantastic. After many years of disappointments with PHP frameworks (Symfony - too complex; CodeIgniter/Yii - not complex enough), I tried out Laravel recently and haven't looked back since.

A lot of good answers here, but none seem to mention that asp.net core is improving a lot and getting traction.

Microsoft bought GitHub and LinkedIn.

Oracle is disliked like before.

Have to second this. ASP.NET Core is awesome. Probably wouldn't try to learn it as a first web framework (Django or Rails are better at this), nor is it quite as batteries-included as those other two, but it has a very "grown up" feel to it I like.

Relative to other frameworks, ASP.NET Core is sort of like the tooling maturity of Java (great editor/libraries, rock-solid VM, everything typed and static) combined with the simplicity / "start from scratch" feel of Padrino, Sinatra or Flask, with the expressiveness of a really nice language with type inference, good functional primitives (e.g. LINQ). You can probably serve hundreds/thousands of customers on a single Heroku dyno or three due to extremely robust non-blocking I/O, faster code execution, and much better memory management than Python/Ruby.

Give it a shot. I really like it.

In my mind, with OpenSource being more and more well regarded, the disdain for C#, a language once Windows-only, grows larger.

Probably just a bias in my circles, as we're heavy OSS users and contributors..?

I mean, ms has released net core 3.0 (fully open source), blazor, and ml.net. F# has always been open source. They also made private repos free on github, released vs code, released zero and deepspeed for pytorch and published the state of the art NLP model along with it. So I'd say your circles probably have a justified chip on their shoulders from the old days.

Microsoft was one of the biggest OSS contributors before they bought GitHub :)

I also see this. As a dark matter .NET Dev I realized that in the last 5 years C# and .NET is now treated fairly. It is widely regarded now as a valid choice with no limitations (like costs or OS).

The universal availability of debugging and intelligence in all relevant editors (Code, Atom, vim, emacs, etc) through the LSP and the related debug protocol make things easy.

You've been spared from the blockchain and serverless hype trains.

The blockchain months were rough.

Bert (more like transformers) really did change the whole nlp scene. It truly was nlp's imagenet moment. Though nlp continues to be significantly more difficult than vision to get running in most problems.

I think React is "winning" the framework competition, if we're judging from number of jobs. It seems like a business decision for many people - React can make websites and apps, and it's probably easier. I haven't had enough experience to say, but it seems like Java; not necessarily the best tool, but something easy to hire for.

Flutter is also coming in hard on mobile. Also not something I've had enough experience to comment on, but there's also little criticism, which suggests it's a good thing.

This view is supported by looking at question counts on Stack Overflow over time: http://sotagtrends.com/?tags=react-native+flutter+ios+reactj...

Could be that there’s also a correlation between the increased complexity of SPAs requiring more hours to accomplish less and thus requiring more jobs...

I see it as like Java. It's an inefficient language, but it scales well. Inefficiency acts like bureaucracy; it adds stability at the cost of speed. But this applies to something like Angular as well, or even the PHP frameworks.

> React can make websites and apps, and it's probably easier.

It was order-of-magnitudes easier than what existed when it was first released. IMO once CSS modules became common (around 2017 IIRC, so OP may not have known about it), that was when React won - we got fully-styled and functional web components for free.

React + TypeScript seems to be to frontend JS as JEE was to Java.

JEE to Java? In a positive way? Or as in: this is a humongous framework for what it’s doing (CRUD apps)...

It's a good question. As in: If a large enterprise, e.g. a bank or an insurance company, has decided to write an app in Java, they'd choose JEE/TS. That was my original thought.

I'd think it means "the ubuquitous choice for certain things".

JEE was somewhat disliked by many even at his peak, while react+ts seems to be beloved by most users :)

What is Ruby on Rails in this analogy?(the thing that replaced JEE monstrosity)

There is none. I'd consider Ruby on Rails not relevant nowadays for anything but small shops. You can find exceptions, and for example the whole Gitlab is written in Ruby on Rails, but you can find exceptions for Cobol too.

Personal biases are involved I'm sure. Ruby is fine, Rails is great, I just don't see it used very often.

On the other hand, I still see a ton of JEE being heavily utilized in a number of sectors. Ruby might have in the past taken over Java for small shops that basically create a frontend to a database, but I'd argue that was never true for the enterprise sector.

I don't believe people would choose voluntarily JEE-way of web development over rubyonrails and the like (django, flask +zillions others) after 2004.

Dumb question but how is react better than jquery? (Im from 2010 instead of 2017 like op)

I’d say they scratch different itches. jquery helps you write better js, the same JS you may have been writing for two decades.

React is, from my perspective, an attempt to abstract away a lot of DOM, with the objective of decreasing the size of the solution space to common problems.

The idea is that two engineers working in two different parts of a company would write more or less the same code in react, whereas the jquery solutions would have been very divergent. React enforces patterns and makes it harder to write bad code. That’s the dream, at least!

I wouldn’t compare the two directly, they’re solving totally different problems. Jquery makes writing vanilla JS less verbose. React is more like an engine that’s written in JS and programmable with JS, with the goal of making browser code more composable and opinionated (wrt data flow).

They solve totally different problems. Jquery is a toolkit, react is a framework for how you build an entire app (reusable components that are specified by their props).

Short answer: yes.

Long answer is that they don't do the same thing. I think jQuery was an incredibly clever and durable library and became so ubiquitous that most of it's most valuable features got folded into the JavaScript and CSS standards and no longer require dependency on a library. React is a modern way of structuring components. It's a fresh learning curve, but it's actually pretty intuitive and very useful.

JQuery is a great set of tools to make websites more interactive with JS.

react is a compiles-to-plain-js framework for building data heavy complex applications in the web browser.

React has its own template language built into your functions, quite opinionated data flow paradigms, and tries to abstract all of the direct attacking the DOM away into passing pure data around.

JQuery gives you better tools for hitting the DOM, but still is just a set of tools, not a development methodology.

This is simplified, obviously, but trying. :-)

As other people have said, they're different sorts of thing; but the sort of thing React is wasn't as big a deal in 2010. Backbone and AngularJS, two frameworks that are practically Precambrian at this point, both had their first release in late 2010.

In 2010 terms: let's say you want to write a web app. jQuery : your library of useful PHP functions :: React : Ruby on Rails. That analogy breaks down in many obvious ways (React isn't MVC and [modulo JSX transpilation and whatnot] uses the same language as jQuery, Rails is not easy to reason about especially if you're in 2010 and method_missing isn't considered harmful yet), but hopefully the basic idea comes through - library of functions vs. very opinionated framework that facilitates rapid development.

The main benefit is handling binding and state, and allowing you to easily break your application into a component hierarchy of reusable components. It also has an ecosystem that will let you find packages for most anything you want to do, probably in five different ways.

They solve two different problems.

jQuery: Add some javascript features like ajax/animation/some DOM manipulation to a (dynamic/static) HTML page.

React: Create the dynamic HTML from scratch, that will still do ajax/animation etc.

It's debatable if it really is for most sites, especially if you have a good way to generate/write your html. React is a better choice if you are truly building a web app rather than a website.

> especially if you have a good way to generate/write your html.

Server-side React is a great way to generate HTML.

There seems to be a lot more skepticism towards AI/ML and especially anyone pitching their product as using it. I think the requirements to do data science as a job description have ballooned as well - we’re talking requirements for having a PhD and lots of experience.

I could be misrepresenting from just what I’ve read here but trying to be helpful. Ymmv

Block chain and cryptocurrency is another thing that's gone from unhinged hype to heavy skepticism.

Nothing has changed. It is still programming. You take some input, you manipulate it and then you do something with the output.

How you do that comes down to mostly a matter of preference with a smattering of "engineering".

In my humble opinion, frameworks and mostly hotshot languages are akin to celebrities. If I asked hey I was away for 10 years spending time in remote island and just came back to LA what changed ? Nothing changes in the main business. We’ve got few celebs come and go Toby Maguire, Lin-Manuel Miranda aka React. They still need to bring back Ahnold for Terminator (looking at you C) or Tom Cruise for MI (looking at you C++). The industry is the same, you need inputs film money and people to generate outputs that people enjoy.

I always thought of C++ as Jim Carrey, Tom Cruise is way too simple for the role!

Pretty much. The cool kids have their heads in the clouds, but still can't be bothered with correctness, reliability, debuggability, etc.

Nothing new under the sun.

We are running out of nouns to name js frameworks.

I used to troll my old housemate (web frontend guy) by saying something along the lines of "Oh, Node.JS? Yeah some people I work with use that, but they're mostly moving over to Pangolin with Clamp on the backend." (substituting Pangolin and Clamp for any other nouns)

I don't think he ever caught on.

Note to self: check out Pangolin and Clamp.

I've got to say, they sound totally believable. I'm not entirely convinced you're making a joke here.

Joke is on me. I picked those nouns at random but Pangolin is a bona-fide frontend framework[1] and Clamp is a text truncating utility.[2]

1: https://pangolinjs.org/ 2: https://github.com/josephschmitt/Clamp.js/

It does emphasize the point that we're running out of nouns.

I work in electronics and laser stuff, where we use german-style compound names like "multi-pixel photon counting" and "erbium-doped fiber amplifier." Even in low-level compute, packages are named descriptively e.g. FreeRTOS. Lots of acronyms, but very few cute single-word nouns to name things. I've only observed that trend in relatively high-level software.

Hilarious. Stealing this idea, thank you.

I feel like nothing really changed. Rust still is a cool project, JS still has plenty of frameworks, SPA still a thing, Go still a thing, Data Science and Machine Learning is still thrown everywhere. Blockchain hype is dead, I guess.

SPA:s are now being overused for no particular reason, particularly by junior talents, who by now have been taught this is the one and only way to build Professional™ web sites.

The Javascript frontend scene almost literally exploded, in various ways.

Webasm got some serious traction. Old serious people like this, becuase it may eventually allow them to avoid the increasingly crazy javascript scene.

Computer vision (by means of machine learning/deep learning) got quite a bit easier to use, even if you're not a PhD in Computer Vision. Real-time inference from static photos is now easy. Real-time inference from video is still sorta hard/expensive, depending on your deployment target (embedded, backend).

Python people are still using Python even though it's dead slow.

A bunch of people moved from Java to Go and suddenly felt a lot happier.

I am a Python / Django guy given the choice. Python may be a slow language, but I haven't seen many places where python is the cause of the bottleneck. Rewrite stuff so that the database is doing the heavy lifting, and add the appropriate indexes and you shouldn't have any problems.

SPA's are a pain in the arse. Usually close to twice the amount of code to avoid page refreshes. Usually the apps are way slower than a page refresh as well - with lots of JSON calls to get data that would be in one server side page load.

> SPA's are a pain in the arse. Usually close to twice the amount of code to avoid page refreshes. Usually the apps are way slower than a page refresh as well - with lots of JSON calls to get data that would be in one server side page load.

Yeah. It's infuriating.

I dont know if is just a impression of mine, but people are getting more realistic and less romantic about this stuff, really understanding the limits and the use-cases, letting Python do what it does best but leaving some parts of the system to be managed in a AOT-compiled platform like C.

I think a lot of people got burn when they adhered to the "i want to use just this thing for everything" mantra, which is pure illusion. And as with all illusions we tend to nurture, it will lead to a crash with the status-quo of reality.

This was also what happened with Javascript. If you used it as the script language that it is meant to be, everything will be fine.

The problem, as i understand it, is trying to follow the misguided and over-hyped steps of Java.

> "i want to use just this thing for everything" mantra

Is node.js dead yet?

I think this wheel of fortune will continue to roll, of course, from one hype to another. If someone want to be the `sucker` that believes that creating a LLVM on node.js is a good idea, no one will stop that person of course, but the trends of the current reality will at some point with an unavoidable nosedive.

Theres a difference between being a pioneer or an adventurer from being a fool who let their emotions turn technology akin to a religious cult.

Node.js, of course, can be a great tool, but only if you know when and where to use it (just like the demonized PHP, can be great and work like a charm, you should also know when to nevermind the boll..).

More and more popular I hear. Exciting stuff, though JS seems very much disliked on HN.

I disagree. I think SPA's are fantastic. Sure, they can be misused, but so can most things.

I'm an intermediate level web developer. I enjoy working with ReactJS-- I like that it's a framework and way of doing things.

1. manages to accomplish everything that I need to get done

2. has a huge community & huge amount of open source reactjs components available

3. is highly customizable

If one isn't going to use a modern, prolific SPA framework such as Vue/Angular/React, other options seem to be:

1. Vanilla JS (potentially a mishmash of vanilla JS + CDN/local js libraries)

2. jQuery

3. other jQuery-era frontend frameworks

ReactJS in my experience makes development faster, easier, better organized and more enjoyable.

I don't think that SPA's are necessarily bad, just that they are used in places where server side rendering would work just as well for a lot less effort. Use the right tool for the job.

> ReactJS in my experience makes development faster, easier, better organized and more enjoyable.

Maybe it makes development faster, but in my experience it makes debugging someone else's code a whole lot more difficult. CSS for example. It seems nice to define the style in the same file as the component code and it makes development a little bit faster. But when you have to debug, it's far easier to have styles defined in classic stylesheets in a different file rather than trying to track down the location of some dynamically generated CSS class. (I know as I have been degugging code that was written by an agency, and the CSS styles are defined in a mix of both React files and normal CSS).

From your list of benefits I don't see anything that couldn't be achieved with sever side rendering and a bit of jQuery. If your front end needs to have a lot of user interaction, then SPA's will be the correct tool for the job. For most web apps they are overkill.

The React frontend we have at my current workplace is incredibly bloated compared to a similar complexity website I created using Django and Jquery. Doing certain simple tasks is like pulling teeth.

I think you are confusing frameworks and SPAs.

For example, React is meant to build small components not SPA. But you can build a SPA using react-router. But you can build SPAs using vanilla JS as well.

The only thing that truly defines SPAs is lack of “true” page changes. JS is taking control of your browser url bar and history. Which I personally dislike.

> React is meant to build small components not SPA

React is meant to build (composable) user interfaces.

What about the server-side of things? If you only have to the UI sure, but if you have to write the whole thing, rails/django is going to be way less work. No need for an intermediate network JSON API with all the encoding/decoding that it entails, just routing on one side instead of two and many more.


Why do we need frontend routing?

> ReactJS in my experience makes development faster, easier, better organized and more enjoyable.


What's the worst thing about React?

Python is pretty performant if you're comparing it to Ruby. ;-)

Python/Django is a great choice for line-of-business/workflow applications where you have dozens or hundreds of users. If you're trying to be "web scale", then Java or Go are probably better choices.

> Python is pretty performant if you're comparing it to Ruby. ;-)

FWIW, neither Python or Ruby are speed kings, but I think that you'll find ruby is on par, or faster than Python in many benchmarks. It is Rails that is renowned for its slowness.

Serverless is starting to become less of a buzzword and more of an actual movement. I see more and more new projects start with serverless as a sane default before going the containers route. Yeah I know, serverless is not server less, it’s a marketing term, the cloud is just someone’s else computer. But I see more and more preferring someone else to manage auto scaling, load balancing, networking, have much smaller attack surface and not having to have a PhD in k8s to launch a web app.

Interviewing is a nightmare.

Always has been.

I had a go at my manager recently for letting people do technical tests then telling them they didn't have enough experience after. He could have worked that out before wasting their time.

I don't know about that. I have been in the industry for decades, and it definitely feels worse (more abusive) today than it did 10 or 20 years ago.

I’ve been away from tech as long as OP and trying to get back into the industry I completely second this.

Hi, I basically agree. But can you expand on this? What exactly do you (or anyone reading this) see as such a problem with regard to interviewing? Especially, anything you see that's gotten worse.

I've been out of tech for as long as OP, a single thing from my experience so far:

- Stronger requirements regarding specific frameworks and languages.

Generically, five years ago it felt like you could be an all around good engineer in some domain and be a good candidate in an adjacent domain. Today, it seems that you need to be completely up to date on the language in addition to all the best practices, build tools, and _all-in_ on a very specific set of libraries and frameworks. A candidate with any deviation is rejected.

Economics tells us it's because of a tighter labor market but in a way it says to me there's less room for learning and creativity.

If you were to ask me, I would say that middle managers are generally miserable and are trying to avoid risk and maintain job security by NOT hiring people as long as there is VC money to burn. But I'm a nihilist.

I know this is late, but a lot of us really want to hire people, but there are a lot of people out there that are overconfident in their skillset, and sometimes you have to do a quick sanity check to weed them out. I agree, though, that most you can tell before that point. I'd never make someone donate a day to a test, but 15 mins of whiteboarding can go a long way if someone doesnt have a lot of publically available code to go look at (and, a lot of devs don't, due to working on public repos)

Here are just a few:

1) All day interviews. Seriously, I've had an 8 hour interview. They served me breakfast, lunch and dinner. This was after several other rounds of interviews.

2) Expecting me to perform "free work". I have had several companies insist that I create and submit "sample" projects. This is NOT simple stuff like FizzBuzz. The projects realistically take 20+ hours and are solving non-trivial problems. This is before you even talk to anyone.

3) It can take weeks or months to go through the process and finally get an answer: one way or the other.

4) Companies straight up lie about everything, from working conditions to performance expectations.

Let's see people still can't write SQL. Most data related issues can we done in SQL. But we hit with a pandas data frame hammer and cry that it hurts instead.

Everyone is data scientist. Load Excel into python? Data science. Divide x by y, and run some algo, data science and ML.

> " I remember Rust was a cool project, JS had plenty of frameworks fighting between themselves, SPA was a thing albeit I was skeptical of it, and I was in love with Go. Big words like Data Science and Machine Learning were thrown everywhere."

From this description, it sounds like nothing has really changed in the past 3 years. This could easily describe today.

There have been some shifts in the fighting JS frameworks though; Vue is a big rising star, has overtaken Angular and is now challenging React for the top spot. Angular is still used a lot, but I think it's on the way out. React is still strong. Typescript is becoming standard.

Server-side rendering is big, though. People talk a lot about static sites (which can still be dynamic), and serverless (which still has a server, obviously).

Rust is more than a cool project; I have no experience with it, but it sounds increasingly like the low-level language of the future. On the JVM, Kotlin is on the rise, has overtaken Scala and Clojure and is second behind Java.

Lots of comments about which technologies are becoming popular. what about things that have lost popularity? Ie. Ruby on Rails and Hadoop

Node, maybe. There's still plenty of it out there but more skepticism about perf and npm, and less hype that it will be the great general unifier of front and back ends.

They were probably equal in 2017, but now go seems to have far surpassed it in terms of server side relevance.

I'd have to see some stats to believe that because that's certainly not the trend I'm seeing. Nodejs is pretty strong, and generally the bottleneck is dev speed and network latency, not CPU performance.

Agreed, I'd like to see stats on this. From the stars on the Deno repo it looks like the server-side JS market is only going to get bigger.

Not true at all. Where you get this from?

Hadoop is still strong, but now that it's matured, the jobs pay a bit less (as it's easier to hire).

Perl has declined quite a bit further.

A lot of noise but fundamentally it’s all the same.

Different perspectives; being in the industry for 25+ years, I didn't think being away 3 years wasn't long enough for much other than names and fads to have changed.

Kotlin has replaced Java for Android development

This month was the 25th anniversary of Delphi, but I guess that is not relevant for the industry.

I think DevOps and cloud services have had the most movement. Kubernetes is seeing rapid adoption as is TerraForm. I'm also seeing a bit of whiplash where enterprises are getting pretty comfortable going all-in on their preferred cloud vendor and just diving into proprietary fully-managed services. AWS is still tops, but Azure is making huge inroads.

Also, everyone has given up on chatbots. Voice assistants are increasing in penetration, but they're just defaulting to transactional modes and not conversational.

In the JVM space there are now new web frameworks that specialize in Microservices. The advantages they offer are very low memory usage, better performance, fast startup time and finally the ability to generate a native executable via GraalVM [0].

[0] A lot of JEE Frameworks heavily rely on reflection and other dynamic features that cannot be used in a native image.

I admit I only dip my toes into the Java ecosystem occasionally. How low is low memory usage? The last microservice-oriented Java framework I used was Spring Boot, but I don’t know that I’d call it lightweight.

I hope no one calls it lightweight. We've been running a few or our own benchmark tests for various frameworks and we have found that Quarkus running on GraalVm is the definition of lightweight.

Thanks for pointing me towards Quarkus! That looks really cool!

Edit: And yes... the folks I was working with were excited at how much lighter-weight Spring Boot was compared to whatever it was they were using before. When I showed them a Go-based server just using net/http, they almost had a stroke!

Any of those frameworks that you endorse particularly?

Jakarta EE has officially taken over the Java EE spec, tlc, ...

Frontend hottest: Next.js/Typescript/React w/ hooks.

Backend hottest: Rust, Graphql is gaining adoption at the enterprise level.

Edit: ML is still very hot but tough to get a job as a Data Scientist without actual experience.

nextjs? whats that

you meant "nestjs"?


It's a server side rendered framework for React. It can also do static sites but doesn't have as many plugins as Gatsby JS, which focuses on static site building with React.

Yeah the idea of building a 100% static site in react seems a bit ironic to me. Handlebars is so much simpler to work with for a static site (like a blog) that isn't going to "spring to life" and become a SPA.

But I can see it being useful in the niche area of someone who needs to do server side rendering for performance (every millisecond to first render counts), while keeping the code simple by not having a second technology to do that rendering, and they need the same thing to be a SPA. Maybe a GMAIL type application? And again the user has to care - I don't care if I wait 10 seconds for my mail app to load as I'll be spending minutes in there once it does, and you've locked me in for other reasons anyway.

This might matter for SEO but to be honest you could just have a non-JS version of the same page which looks different for SEO purposes.

Next.js seems pretty hot, so I am probably missing something :-).

I'd rather not use JS on the server myself, so for my projects I'd either make a SPA with API backend and no server side rendering. Or just a classic "rails style" crud app with a sprinkle of JQuery.

I hope someone chimes in and tell me what I am missing and why to use Next.js other than "I only want to do JS and React for all the things."

Next.js positions itself as a hybrid framework, and is recommending SSG (static site generation) by default over SSR.

See this discussion [1] with the response from rauchg (framework author and Zeit founder) outlining where they are heading.

This ability to easily mix SSG and SSR pages within the one project, the PHP-inspired philosophy of simple file-based routing for pages, and pre-configured babel / webpack with easy customisation are a few things that draw people into next.js dev.

Like anything that deals with reasonable complexity there are a bunch of concepts to understand, but once that happens next.js feels like a thin layer around "it's just react".

I particularly like being able to drop api functions with a standard req / res signature into `pages/api` to immediately have some server-side api endpoints available, which can be deployed to Zeit's now as Lambdas with minimal fuss. It significantly reduces the friction of thinking about and implementing front-end sites with custom api endpoints for whatever you're building.

[1]: https://github.com/zeit/next.js/discussions/10437

Does this mean I can treat it a bit like PHP hosting of yore, where I upload a single file and stuff just works? No NPM etc? That would be compelling!

Some of the benefits of "React" don't come from React itself, but rather the ecosystem. Webpack, Typescript, CSS Modules, etc are all things that work well in the "react ecosystem". Certainly possible outside of that, but its going to be harder.

Do you get type safety in Handlebars?

Correct AFAIK you can't get end to end type safety in Handlebars, in that if you treat a string as an array it will silently not render something, whereas in Typescript / React you would notice.

But... let's forget Handlebars because Typescript/ES6 allows you to write code like this:

    mythings.map(thing = `<li>${thing.name}</li>`).join();
And this is React-free and arguably a lot simpler for the needs of a static site, and actually more flexible as your are controlling the character by character output.

And the question is do I want to pull in not just React but Next.js and learn all of it's ways to do this? I think for a static site no.

AMD is giving Intel a tough time! Checkout the new Ryzen series processors.

I hope your health is better now. Stay strong.

Kubernetes has become important

Experiments with new "open source" licenses are unknown

Low code has entered the hype frey

We moved from one big box to Kubernetes. Now we have a load of kubernetes related problems to fix.

Learning pains? It is more complex, but the efforts will return value.

Email me if you'd like some help debugging and stabilizing

> It is more complex, but the efforts will return value.

It seems Kubernetes is often the wrong tool for the job. The industry, and even Google is starting to recognize that, e.g. Kelsey with his "Monoliths are the future" [1] statement.

That said, boy do I like Kubernetes... It is extremely complex, though, and often its deployment seems not to be justified.

[1] https://changelog.com/posts/monoliths-are-the-future

Have you heard of Anthos from Google? I think they are directing more resources towards k8s

Monolith / microservices is a separate conversation from orchestration. I have deployed both to Kubernetes for great benefit

It just seems like a whole lot of complexity that no one in our team understands especially well (it's another person in the team that does most of the kubernetes stuff).

So far I have seen little benefit.

C++ is getting Modules and Concepts in its newest standard (2020) version, bringing more simplification and making it even more modern and as easy as other languages. The compile-time programming is even more powerful than before

Elixir is now fully mature (almost at v2.0) and probably the best all-round language, with a super powerful web framework (Phoenix) and a very rich ecosystem. Highly recommend playing with it!

Blockchain came and went. I'm unsure of what the current scam/buzzword is on VC's bingo cards.

DeFi is the new ICO



Microservices are the new hype with related tech. It's DDD with a new jacket, requires a devops team and it has some interesting concepts though.

Almost no one has a decent implementation for micro-frontends. Although ING bank released a nice framework related to this - https://medium.com/ing-blog/ing-open-sources-lion-a-library-...

The first rule of DevOps is that if you have a DevOps team then you're not doing DevOps.

sounds really stupid

It forces developers to write better code because they have to maintain it from design to deploy. The biggest pushback I've seen is from people who don't want to think about how inefficient their app runs in the cloud and just want to write the next API.

Can't speak for the industry as a whole but a lot of companies are moving away from dedicated DevOps teams and shifting the responsibility onto developers. The previous DevOps team in many cases still exists but has been rebranded to SRE.

Just a nit pick, but maybe the title should be updated to specify the question is about “web software” rather than software in general, since the question and most of the answers offered are pretty narrowly focused on web technology and ML and not software in general.

Rust has grown tremendously in the last few years. People are using it as a general purpose language, from Unix command line utilities to industrial IoT services. Greenfield projects are using Rust as are next generation refactoring projects. Game development, multimedia, and even data scientists are showing increased usage. Embedded adoption is growing but at a slower rate. I'm not going to drop names until announcements are made but companies that have used Go for flagship products are no longer doing so. They're rewriting in Rust. Healthcare startup(s) who are building systems to compete with Epic are using Rust. Government contractors working on intelligence systems are also using it.

AI is still thrown, investors seem to like it.

React is performant now, so if I was you I'd take a good hard look at Clojurescript / Reagent / Porting those to React-Native.

And welcome back, good to hear your health problems are sorted!

Kotlin is now preferred for Android development. Apple has embraced FRP and introduced it’s Combine framework as well as SwiftUI, a declarative React-ish view framework for all it’s platforms. Swift got module stability and looking towards server side and cross platform development. Google is pushing Flutter pretty hard and trying to find a place for dart, it looks promising but nobody is using it. React Native is being used heavily by startups and small shops but big companies are still building native apps. PWAs are getting better but still have a way to go.

I'm scratching my head to think of anything really significant. It's a bit of a stagnant period, albeit with lots and lots of churn, but all that churn hasn't really amounted to much.

still have to support ie11 but no one cares about 8/9 anymore

Python 3.0+ is no longer optional.

JSX in favor of HTML has won. Compiled server side languages are the future. Everyone writing untyped is converting.

I got one. Hadoop seems to be dead. Cloudera will be a penny stock and MapR had a very strange exit.

Angular - Still lost track w/ their versioning. React - More popular JS Postgres - Getting better and better Svelte - Might make it. K8s - Too much stuff going on. Jump w/ care.

MacBooks are still all the rage even with the crappy keyboard.

And now you can even buy one with the non-crappy keyboard again.

Nothing - oh I forgot there is 8 new Javscript framwork this week. It's been a couple of weeks since I checked but there must be a new language or 2 out there.

Basically nothing

Java release cycle was changed. Now, it's being released every 6 months.

Windows 7 and Python 2 are officially dead now :)

JavaScript, Java and PHP still suck.

Nope, I think that about sums it up.

Serverless is getting bigger.

But no longer a silver bullet. Costs to be calculated.


Svelte is slowly but surely growing and gaining attention. I think more than any other framework it has the potential to really challenge React in the coming years.


That's not what npm stats show. Rich is good at marketing though.

Java's market share is declining fast.

Ruby and Clojure are dead, literally for Clojure, most libs are from >7 years ago.

Javascript(and TS) and Python are the tools of the trade to achieve most common things.

Devs are starting to realize how they got fooled by Rust's marketing/hype train for general purpose programming/exploration/prototyping and productivity because it's too restrictive and its compile times are atrocious.

A more accurate Rust slogan:

A language empowering everyone to build reliable and efficient software at a very high cost.

Which is fine is you really need that efficiency.

This seems like an answer from someone who filters the industry through Hacker News.

Java's market share is still huge. Clojure never really had a big market share and Ruby is still very popular.

Honest question: Is Ruby (significantly) more popular than Clojure?

More popular, probably, but in no way a better option if you are into functional programing.

I think most Python, JS, Java etc libraries are "dead" in this sense that you lament about Clojure. The exceptions are the very recent languages. It's natural, most libs don't become popular and flourishing open source projects.

It seems to me Clojure ecosystem is in good shape, a lot of new libs keep coming out and there's a healthy & growing actively maintained set of libs. The Clojure way of data-centric APIs also means that stable libs don't need to be tweaked often to keep them working while the surrounding world changes. In the early days there were more hobby projects published and less serious use, currently the user base is more tilted towards inhouse business software. I grant that it would be cool if there were more stuff like Overtone or Quil from the early days happening now..

Clojure is more of a case of stability rather than death. Most libs have not needed updating in 7 years. Compare that to other languages which frequently "trigger the libs" ;-)

Yeah, Clojure libraries are feature complete, bug free and never need maintenance ever. /s

Should clarify that first statement.

Java market share is declining but the JVM is still as good as ever. Instead everyone is moving to Kotlin and Scala.

What do you base that on? I still see a lot of Java jobs advertised (never seen a Kotlin job and not too many for Scala). It seems to be entrenched in the corporate world in a way that it isn't going away soon.

"Java market share is declining" -- yes, 90% down to 86%

Some people won't get past the initial learning curve. It's unfortunate because Rust is a joy to work with.

My company still uses Ruby/Rails. It’s just so easy.

Rails is still the best way to create server-side-rendered HTML web apps IMO, but besides the effects of SPAs on Rails, Rails is also declining fast because Ruby became a too niche language.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact