That would mean it's okay to use Angular today, but dev trends (and Google's support "policy") would advise against that.
We have a good picture of how Angular and React works in production now. We cannot say the same for something like Svelte.
If one wants stability, then PHP has a way better track record.
De jure deprecation, correct - but reading between the lines in Facebook's own blog article that introduced Hooks ( https://reactjs.org/docs/hooks-intro.html ), which put a bit too much emphasis on "There are no plans to remove classes from React.", which to me means they're definitely going to be deprecating class-based controls in the future.
> There are no plans to remove classes from React.
They're totally going to remove classes from React.
> We are going to remove classes from React.
They're obviously going to remove classes from React.
> No comment.
They're totally going to remove classes from React.
Rails/Django, then ASP.Net MVC/Laravel/whatever Java was was a massive step forward. If you didn't use it, you were hamstringing yourself. People switched to Rails in droves.
As were using ORMs. You'll still get people quibble about this, but never having to go through the tedium of updating 101+ SQL statements when you add a column in a pain you young'uns will never know...
JQuery was actually another example. Cross browser Ajax statements were annoying, plus just manually adding individual HTML nodes in HTML was laborious.
Apparently they are all now learning Elixir after a short migration wave over to Clojure.
C++, Java and ASP.NET over here for the last 20 years.
I think it's a little more nuanced than that. Usually the older technology is more stable and better documented. But not always. Sometimes the new hotness is the new hotness precisely because it's better in these kind of categories.
- paper
- text files / spreadsheets
- desktop apps / local db
- SSR web apps / single database
- SPA or mobile app / cloud storage
The only thing that challenges that is the reality that around a decade ago smartphones with tiny screens and no filesystem access eclipsed desktop computer, and we're still reeling over how much more expensive that makes development.
The start of my ladder looks much the same as yours except I jump from local files straight to single database SSR/SPA. Maybe slightly more complicated than a local app because you need auth, but when prototyping something I just use basic auth to start.
Chuck it up on a $5 DO box and you instantly get:
- Multidevice access, desktop and mobile (write mobile-first css and the tiny screens aren’t a problem)
- a UI that’s trivial to hack on (HTML and css are easy)
- likewise, a technical base that’s easy to extend. Drop in react, build out the api side and use it as a source for other projects, etc
All this assuming you have reasonably reliable network access, and even then you can build it as a clever PWA falling back to local storage if you need to (I think, prototyping that is still on my todo list)
Heck, save yourself $5/month and stick it on a raspberry pi at home.
It’s truly a golden sweet-spot for personal software tools. The only external dependency that irks me is needing a domain name.
All of the constituent parts are easy. It's when you tie it all together that it starts to get complex. There is no doubt there are many more moving parts in a modern web app compared to desktop. I did a few VB projects and I needed know two things, VB6 and a database.
Of course we can't go back, enterprises are rightly presenting their systems directly to the customer, you can't do that with a desktop app. None the less it does feel more complex than it needs to be.
Desktop apps are relatively simple if you only need to target one platform. Both windows and macOS have good options accessible from managed languages. But if you want to do cross platform then the complexity rockets.
In descending order of importance.
When choosing between any technology choose the one that is most stable.
If multiple options are on a stable release, choose the one that is best documented.
If multiple stable releases have excellent documentation, choose whichever is oldest.
I don't think this framework is always (or even often) right. But it works for me
Each situation necessarily results in different priorities and tools. I wouldn't TDD a gamejam project, and I wouldn't start a multi-year project in zig - at least, not yet.
For infrastructure projects I want well written deps which are simple, easy to use and have good documentation. When I'm evaluating something I often read bits of its source code (eg to figure out how to do something not listed in the examples). You get a sense of where to put things that way - actix (the actor library, not the web library) is very carefully designed, but seems to go a bit overboard inventing new concepts (+ associated traits). Tide feels pragmatic - its a bit sloppy with allocations, but it doesn't seem to really care. It wants to be fast enough and good enough while being simple to use.
For hobby projects I like to follow my nose and pick whatever seems shiny. Over the last few years I've learned svelte, typescript, snowpack, rust (and some rust libraries), zig, wasm and other stuff. I like to make some risky bets and then just play the hand out and see what happens. And I use that as fuel for when I make longer term projects. I'm making a little database at the moment and I'm using rust - which is much slower for me to write (compared to nodejs) but it matches the values of the project I'm working on to a tee.
But new tech should be the last resort.
If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness