Never bothered to learn GraphQL - anything being pushed by big tech companies usually in 80% of the cases works for them, but its an overkill for smaller scale projects.
Stick to tried and true - monolith, asp.net, angular or blazor front-end, relational database.
I have never had any major issues or problems with it.
Think of it this way: GraphQL, Docker, and Kubernetes solve problems that very, very, very few GIANT tech companies have, but not every app will scale to millions of users.
So you’re not familiar with AngularJS, the incompatible version 1? Angular 2 was effectively a complete rewrite - cleverly using the same name, thereby making it even more difficult for us - and the rewrite was done because Google Decided. Never again will I trust a Google front end library.
Because of my experience, I feel that your position is making a slim distinction based on your preferences. All the tech you use is built for big corporations, why pick on one set of tech just because you don’t have the specific problems it solves?
For me, for example, K8s properly solves a bunch of problems for my small SaaS business, not least of which is that I can upgrade my three piddly servers without taking my customers offline. My SSL certs get upgraded automatically without downtime. My CICD pipeline is simple. Logging is much easier. And so on.
I don’t understand the disdain for modern, managed K8s at all.
What do you think about how well uWebSockets.js performed in the TechEmpower benchmark? Just js is admittedly experimental, but it has the fourth highest score, and the highest score of any non-Rust framework as well which I found interesting. Elysia (a Bun framework) did pretty well too.
Deno would have probably scored well too (it uses Rust's Hyper crate under the hood), but they're only running a single instance of the server despite Deno supporting the Linux SO_REUSEPORT socket option, which is important because the test is run on three servers with Intel Xeon Gold 5120 Processors that have 14 cores and 28 hyperthreads [0].
Just go to its repo https://github.com/uNetworking/uWebSockets.js and see the uWebSockets submodule dependency that it's written in C++ (90.9%) and C (6.8%)...so sure, a "fair" comparison indeed with vanilla implementation!
Ok...Node is itself written in C++. The V8 and JavaScriptCore JS engines have no concept of a server (they were designed for web browsers), so under the hood JS runtimes implement servers in a lower level language capable of interfacing with Linux syscalls. Bun uses Zig, Deno uses Rust, Node uses C++, etc. I don't think that necessarily makes this an unfair comparison. The database drivers used in these benchmarks are also usually written in C++. Look at the repo for the native Postgres binding for Node: https://github.com/brianc/node-libpq
React and .NET/C# made sense to me but are nauseating abominations of mediocre corporate tech, and the more I saw people using them, the more it reconfirmed my belief that they were a no-go.
Usually, people win if they do the opposite of what the mass is doing :)
Around '96-97 I was playing with writing fire effects in Turbo Pascal, most of the tutorials used the asm with mode 13h, and all I had was Turbo Pascal 5.5, which didn't support the asm keyword. So, I dabbled a bit with it, and then in late 97, I found about C, and when I saw the for loop in C - I never touched Pascal again.
We have ZERO incentives to change these cars with electrics; why would I change my convenience to put gas in the established gas network with the dubious charging station availability (Eastern Europe)?
I drove a Hyundai Kona electric last year; well, when you drive it at 150-180 km/h - the battery dies quite fast :)
I am not convinced AT ALL in electric cars. Maybe in 20-30 years ...
Honestly, there’s something very Eastern European about your comment. You own two unnecessarily powerful SUVs, driving waay over the speed limit in Bulgaria seems somehow relevant to you and you still wonder why you should be inconvenienced by EVs while ecosystems are dying left and right beyond any doubt. With this mindset you actually might be one of the last people to understand, yes.
Agreed. I mean really in the spirit of get er done the AS400 is the pinnacle of UI for these sorts of things. I've worked with other things, even WinForm apps, Access things, Excel sheets that were turned into portable apps, and of course web pages. Green screen allowed 99% of things to get done faster with 1000% less fuss.
My first job required maintaining a very old informix 4gl app. The trained users could fly in that thing! Seeing clunky webapps with a bunch of clunky laggy UI components doesn't seem worth it for trained internal users
At my old job non-technical people would navigate about as well as they would with a mouse and a graphical-based interface, because the graphical interface didn't provide any additional value. For those people it took the same time whether read instructions and press key or read instructions and click button. Trained people were definitely faster, and often the user would type ahead of the terminal (with no ill effects) because they were inputting data close to their speed of thought about the process [0].
The point is, for this situation a text-based terminal offered no downsides and many benefits compared to a graphical UI. I suspect the same is true for a lot of other business solutions.
I've heard it argued before that graphical systems are easier to use, but in my day-to-day experience in the trenches with others who actually used the systems this argument was simply not true. I've also seen it hinted that graphical systems seemed more modern, so they got less emotional disdain. That rings more true to me. And really if I were in charge of such things I would acknowledge emotional disdain - even misplaced - may well count for something in the overall business picture.
Also, and maybe most importantly, if the green screen needed a new feature or bugfix, there was one person at corporate that would do that. They had about a half dozen devs working on other things but she was the go-to for the green screen features. So I imagine it's harder to hire people for those sorts of systems nowadays. However it was also interesting for me to note that one person didn't seem stressed out or overly busy and the system never had a major crash or bugfix. So, tradeoffs.
[0] The terminal was actually hosted inside a wrapper app inside Windows 7. So I ended up using AutoHotKey to great effect to get even more efficiency gains.
* edit: added footnote explaining how AutoHotKey could be talked about in same breath as green-screen dumb terminals.
Stick to tried and true - monolith, asp.net, angular or blazor front-end, relational database.