General advice: when smart people are investing time and energy into a solution, and your alternative solution involves the word "just", it's usually a code smell that you're not giving the people doing the work enough credit.
Citation needed. E.g.
2010: AngularJS, Backbone
2011: EmberJS, ReactJS
2012: MeteorJS
2013: HexoJS
2014: CycleJS, VueJS
2015: MithrilJS, PolymerJS, Serverless Framework
2016: Angular2, AureliaJS, NextJS, Svelte
Those are a lot of the most popular ones, and some not very popular. Do you really consider this an endless stream of new JS frameworks popping up every day?
It's such an outdated stereotype. And it's especially funny considering how "greybeard oldschool" stuff like Linux distros, utils and packaging seem to have a lot more of an "endless stream of new stuff" right now.
I think I'm also a pretty smart person in certain areas, or at least I should be by now having been doing this stuff for almost 30 years.
While I definitely always want to check myself, it's also part of my job to help the newer/younger engineers remember the golden rule of business technology:
Innovate in the business domain, not in the technical one. Keep technology simple and boring.
It's great to experiment, and sometimes the results of the experiments are winners. But generally you can tell winners from losers based on whether they make everything less or more complex.
NodeJS, for example, reduced complexity because it's one language everywhere and has a very simple single threaded execution model. Now with es6 modules, commonjs fading, we simplify even more.
Rollup/vite reduce webpack's complexity, but will also be replaced as native solutions emerge.
REST reduced SOAP/xml-rpc's complexity.
HTML5 replaced flash (and most of the browsers plugins), because flash had grown too complex with a massive attack surface and was impossible to properly secure. Remember ActiveX controls that would load and run in the browser with full permissions? I do. I wrote several.
Linux as an app server reduced Windows' cost and complexity.
Anything that adds needless complexity to the stack, no matter how interesting, will end up being a fad and replaced within a few years.
Containers as VMs is usually peak over-engineering. It’s unnecessary most of the time. In fact, there’s only a few use-cases where it’s desired to have that isolation:
- different clock rates in the container than outside (deliberate skew)
- high security applications
- require certain kernel modules that you don’t want installed in all containers
Isolation can already be guaranteed by the kernel (excepting some bugs), so I don’t think that is a valid use-case, but I could be wrong.
Cgroups and kvm are basically the same age (kernel support in 2.6) so saying “cgroups is newer so it must be more insecure” is fairly false.
Firecracker is, in fact, quite new, and may or may not be more vulnerable as it is a completely new implementation of a kernel.
I did not say that.
> as it is a completely new implementation of a kernel.
Firecracker is not a "completely new implementation of a kernel", whatever that means.