Will JavaScript Containers Overtake Linux Containers? (tinyclouds.org) 94
"Developers of the Deno JavaScript and TypeScript runtime are exploring the possibility of JavaScript containers — and the JavaScript sandbox itself — as a higher-level alternative to Linux containers," reports InfoWorld, citing a blog post by Node.js and Deno creator Ryan Dahl:
Dahl also noted that Docker popularized the use of Linux containers, with operating system-level virtualization for distributing server software. Each container image is a dependency-free, ready-to-run software package. But browser JavaScript offers a similar hermetic environment at a higher level of abstraction, he said.
Dahl said he expects JavaScript container technology to unfold over the next couple of years.
In the blog post Dahl says scripting languages are "all pretty much the same" — but that JavaScript is "by far more widely used and future proof." [A JavaScript sandbox container] isn't meant to address the same breadth of problems that Linux containers target. Its emergence is a result of its simplicity. It minimizes the boilerplate for web service business logic. It shares concepts with the browser and reduces the concepts that the programmer needs to know. (Example: when writing a web service, very likely any systemd configuration is just unnecessary boilerplate.)
Every web engineer already knows JavaScript browser APIs. Because the JavaScript container abstraction is built on the same browser APIs, the total amount of experience the engineer needs is reduced. The universality of Javascript reduces complexity.... In this emerging server abstraction layer, JavaScript takes the place of Shell. It is quite a bit better suited to scripting than Bash or Zsh. Instead of invoking Linux executables, like shell does, the JavaScript sandbox can invoke Wasm.... Maybe the majority of "web services" can be simplified by thinking in terms of JavaScript containers, rather than Linux containers.
At Deno we are exploring these ideas; we're trying to radically simplify the server abstraction. We're hiring if this sounds interesting to you.
Dahl said he expects JavaScript container technology to unfold over the next couple of years.
In the blog post Dahl says scripting languages are "all pretty much the same" — but that JavaScript is "by far more widely used and future proof." [A JavaScript sandbox container] isn't meant to address the same breadth of problems that Linux containers target. Its emergence is a result of its simplicity. It minimizes the boilerplate for web service business logic. It shares concepts with the browser and reduces the concepts that the programmer needs to know. (Example: when writing a web service, very likely any systemd configuration is just unnecessary boilerplate.)
Every web engineer already knows JavaScript browser APIs. Because the JavaScript container abstraction is built on the same browser APIs, the total amount of experience the engineer needs is reduced. The universality of Javascript reduces complexity.... In this emerging server abstraction layer, JavaScript takes the place of Shell. It is quite a bit better suited to scripting than Bash or Zsh. Instead of invoking Linux executables, like shell does, the JavaScript sandbox can invoke Wasm.... Maybe the majority of "web services" can be simplified by thinking in terms of JavaScript containers, rather than Linux containers.
At Deno we are exploring these ideas; we're trying to radically simplify the server abstraction. We're hiring if this sounds interesting to you.
Betteridge says "LOL nope" (Score:3)
Re:Betteridge says "LOL nope" (Score:2)
"Is Betteridge's law of headlines correct?"
Re:Betteridge says "LOL nope" (Score:2)
Re:Betteridge says "LOL nope" (Score:2)
Neither. The alternative to a "stupid question" headline is not a "bald faced lie" headline.
We'd prefer a world where the headline is "John Hopkins studies effects of chocolate on cancer." or "Promising results in cancer study using chocolate" or "Gates Foundation finds unexpected link between cancer and chocolate' or a million other things that simply state what the news worthy item actually was.
And if you want to write "shocking" in the headline then the chocolate better not only cure cancer after one easter egg, but also do so only if you are black and catholic, otherwise it causes your eyes to dissolve and melt out of their sockets. /rant :)
Re: Betteridge says "LOL nope" (Score:1)
"Chocolate may heal cancer" does the job somewhat better, without sensationalising or using a question mark.
Aren't Javascript containers (Score:5, Insightful)
called "browsers"?
Or as I call them, the OS within your OS.
Re:Aren't Javascript containers (Score:3)
Or as I call them, "bloated pieces of s...".
Definitely not more future-proof! (Score:5, Interesting)
Or as I call them, "bloated pieces of s...".
Yup, having inherited 5yo node.js apps before, I am confident JavaScript, as we know it today, won't dominate. TypeScript? Eh, that has some possibility, but JavaScript is a garbage language that proponents keep pushing because the lowest-end developers are familiar with it. That's not a good thing.
JavaScript is perfectly fine for UI or quick scripts. If you want complex code to change hands many times over 10 years, you will find the lack of compiler to be a liability, not a feature. Entire classes of errors that are automatically caught by compilers and frequently introduced by library updates require good unit test coverage in order to be found before your users do.
If you rely on users or your QA staff to find bugs, you're severely limited as to the depth of business logic you can or the complexity you can support.
I also think these proponents over estimate the quality of node.js code and underestimate the complexity of code handled by Linux. Node.js is a painfully inferior substitute to Java backends...it has been a "Java killer" for 10 years now and sorry...most shops that know what they are doing are not starting new complex apps in node.js, but Java, #NET, go, scala, or some superior language. And business programming is a fraction of the complexity and difficulty of the applications handled by Linux.
If node.js was meant to take over the world, it would have done so by now. It took Java less than 5 years to unseat mainframes AND Visual Basic as the dominant business platform. Node.js has had twice the time and has 10x the advantages of Java or C# and really hasn't managed to go very far. The reason, IMHO, is because while you can do amazing work as a prototype, once the app changes maintainers a few times or has been in production for 5 years, it becomes painfully clear how dangerous their weaknesses are.
Re:Definitely not more future-proof! (Score:5, Interesting)
If you try to use JavaScript the same way you use Java or C#, I can understand why'd you'd think that way. I used to think that way myself before I took the time to actually learn the language. Crockford might help you here. He's far from perfect, but should get you going in the right direction.
If you take the time to actually learn JavaScript, and how to use it properly, you'll find using it liberating. Prototypal OO is far more powerful and expressive than "class"ical OO. Add to that the easy mix of event driven programming (you think you know what this is, but I've found few developers actually do) and functional programming all in an elegantly simple package and it's hard language to hate.
Of course, once you understand the language, you'll come to hate just about everything done with ES6 as it goes completely against the language. That was done, of course, to appease people who can't be bothered to learn a new language, and just want C# in the browser. Pure foolishness on the part of the standards committee.
Really, just a little effort on your part and you'll find that your projects are smaller, more efficient, and significantly easier to read and maintain than they would have been otherwise.
you will find the lack of compiler to be a liability, not a feature.
Use a linter. You're welcome.
Funny thing, you'll find that a lot of complexity a lot of problems simply don't happen when you move away from OOP orthodoxy, but that's a whole different discussion.
I'm not sure I understand or agree with your Java/Node VB/Java comparison. This is the first I've seen anyone claim that Node was a "Java killer", though I do remember people claiming that it would overtake PHP. That's odd, because Node makes more sense as a replacement for server-side Java than it does for PHP or Ruby. I've said from the very beginning that Node would stay a niche solution because it has one fatal flaw, and it's not the language: It's deployment.
That time frame thing of yours is really baffling. You must not have been around back then, but computing was moving really fast. Five years in 1995 was a lot longer than five years in 2010. We're at a comparative standstill today -- 2017 was five years ago. Has anything really changed?
We're also a lot wiser now as well. Around the turn of the century, developing anything was a gamble. You had no idea what technology was going to stick around and what would disappear overnight. We have mature technologies now, and we don't need to hop from one fad to the next just to stay current. It would have been foolish to invest heavily in node early on. Let the kids take those risks. We should expect any new technology to have a comparatively slow adoption.
Re:Definitely not more future-proof! (Score:0)
Javascript's such a great and useful language that it even has built-in support for UTC. Wait, you need to download a library like Moment to get UTC and/or timezone support?
Bugger off.
Lots of advice for solo projects. (Score:2)
As an individual, I can learn any language really well and do great work in it. I have done AMAZING work in shitty languages back when I was forced to or I simply didn't know any better. However, most professionals get reassigned after a project is delivered.
I have about 100 developers I work with to some degree or another. I have about 20 I collaborate with routinely. Most don't write good unit tests. It's required by the company and the managers, but in the real world, no one is going to hold up a release because the quality was barely viable when it should have been professional-grade. So some dude pushes sloppy uncommented code with no unit tests over the finish line just 2 days after the deadline, the manager usually is happy enough and moves on to the next feature. Features make money. Quality...well, it's much harder to determine the economic impact of that.
A specific example, I inherited an node.js app that leveraged puppeteer. Google is infamous for their short attention span and completely changed the API between the release this code was written for and the day I got a notification there was a vulnerability in the library and we'd have to update to the latest version.
If you're a professional software engineer, you know this story. You've done it many times...some app that is in production runs afoul of backduck or another vulnerability scanner and you need to update the library. When Spring changes their APIs, which they seem to do for no good reason every major version release, I get errors QUICKLY. The app doesn't compile. If it compiles, the context fails to start and the app doesn't load. Even then, most rudimentary tests will find the vast majority of issues. When Google changed all their API signatures, the app still started and deployed. We had to find EVERY bug at runtime.
At that moment, I found out the original author didn't write very good unit tests and added several features without documenting them. How did I find this?...well, I didn't. Unfortunately, our users found these obscure workflows that weren't in our documentation nor did our QA dept know about it or have in their test plan.
ANY language is fine if you have:
1. World class talent
2. Enough time to do the job correctly
3. Professionals who are committed to doing good work and following best practices
4. Managers who ensure enough time and resources are devoted to each task
5. Enough coverage that your rockstars can take a vacation or go on leave.
We SHOULD have all those, but I have never seen nor heard of that. Every project is rushed. Every team has a few duds. Every company has professionals who either should have never been hired or seem to have checked out and stopped giving a fuck, but not bothered to leave yet. Every company has managers who make short sighted decisions.
You're an optimist. You're telling me great work can be done with JS. I don't dispute that. I am a jaded veteran of profitable large companies. I know that once money is involved, you need to prepare for sub-optimal conditions.
Some examples?: You do such a good job you get promoted...or get a job somewhere else...or relocate to another country...or your boss lets an intern write a new feature in your code...or it gets handed off to developers in another country for a year to add a new family of features.
There's a lot of chaos. JavaScript is SHIT in chaos. Java, C#, Scala, Go...handle chaos and complexity well.
I am paid to write code for a big tech company for their flagship product. I don't have fine control over the details. I am just one link in a chain. This is why I fear JavaScript and python doing serious work and why I find compiled languages more comforting. Software at scale thrives in a robust system. It cannot rely on every developer being a rockstar and knowing these wonderful skills you have.
My company has many teams that have done apps in node.js and python as well as plenty in Java and C++. The Java and C++ teams simply have a MUCH better record of meeting deadlines with fewer bugs in production. They also tackle more complex problem domains and have been in production much longer (so deal with more cruft, ancient practices, and legacy code and workflows) There are probably a few reasons for why the Java/C++ teams do so much better, but I think the languages and associated cultures with them are the biggest reason.
Re:Lots of advice for solo projects. (Score:3)
I don't have fine control over the details. I am just one link in a chain. This is why I fear JavaScript and python doing serious work and why I find compiled languages more comforting.
That seems more like a matter of training than anything else. We've taught a whole generation of programmers the same ways to deal with the mutli-trillion-dollar failure that is OOP, so dealing with the kind of messes it makes at least feels familiar. JavaScript is very different, so you can't expect the same base competency from the average developer. (I still have to explain closures, if you can believe that.) Universities don't teach it, or don't teach it well. A lot of training materials still make the mistake of trying to shoehorn classical OO into it. This is made worse by ES6, of course, which I see it as a failure of the industry. We also do a really bad job teaching people about dynamic languages in general. That may explain a little bit of your Python pain.
All that trouble means you do have to invest quite a bit in anyone you bring on who will write or maintain anything written in JavaScript. Not just teaching them about the language, but about the particular idioms and the like that they'll be expected to use. I'm okay with this as it usually pays dividends. JavaScript is very expressive and flexible, so it's wise to 'lock it down' by setting clear standards and enforcing them in code reviews. That might also explain some of the pain you've experienced as well, given that you work in chaos. Still, I think if we hammered certain concepts and practices in JavaScript the way we did for Java, you'd probably feel differently.
Oh, and a good linter is a good replacement for a compiler when you're using interpreted languages. It'll also do a lot of helpful things a compiler won't, so it's not a bad idea to use one in compiled languages as well. I get that you don't have much control, but that's at least something you can do to lessen the pain.
I'll agree that JavaScript has a culture problem, but it's more a problem with the broader programming community. It's a very poorly understood language, and it's very common to see people try to use it like they'd use Java or C#. This is why the standards committee, who do understand the language, thought it best to essentially ruin it by making it "easier" for developers coming from classical OO languages. Things didn't have to be this way, but JavaScript came on the scene when hype around Java and OOP was at its peek. That's how it got 'Java' in it's name. I have a few old books about JavaScript from that period and they're almost comical given how poorly the authors understood the thing they were writing about. Gotta get those books out fast to cash in on the hype, after all.
Things really didn't get much better until Doug Crockford, of all people, started writing about it. Still, it was too little too late as many developers already hated it, didn't care enough to learn about it, and hated when they were forced to use it. I hated it for years as well, until I started looking for reasons why the language seemed so bad. It turns out, it was because I really had no idea how it worked and there was a language almost as elegant as lisp hidden under a mountain of bad resources. I stumbled on Crockford's book around that time and while I don't completely agree with him, I did find his work helpful in shaping my own understanding of the language and how it should be used.
Now, none of that would have been necessary had there just been good resources in 1997. I'm not saying that everyone needs to be a "rockstar" to use it effectively, I'm saying they need to take a few days to actually learn the language. If it wasn't so poorly misunderstood and good resources for it had been produced early on, it probably wouldn't have been so maligned. It's actually really easy to use well and feels almost liberating.
You're an optimist.
I haven't been accused of that before. I have a friend who will get a real kick out of that. I'm the old guy now, and I should probably feel pretty pessimistic given the state of things, but I've been around long enough to know that we can do better and I'm just arrogant enough to think I know a way forward.
Re:Lots of advice for solo projects. (Score:2)
While I felt about JS the way you do before, the power of prototypal and just being able to overload everything in everything, I now feel that this power comes at the price of good static analysis. There is no way anyone can do static analysis with an object whose hierarchy can change at runtime, for very good reasons.
This gives an edge to compiled languages (which TypeScript is) over pure JS. Refactorings are easier. And when your app reaches a certain size, refactoring is what you do all day. This is why TS and ES6 moved the way of Java and C#, because they scale when you have 20+ people working on the same codebase. JS does not.
Re:Lots of advice for solo projects. (Score:2)
Something often overlooked is that OOP tends to rather dramatically increase the size of projects. A good bit of that comes from the typical failures of bottom-up design, which seems to demand clairvoyance. (I'm convinced that's also the reason that Forth isn't more widely used.) Projects stay smaller, are easier to modify and extend, and require less refactoring type maintenance when you move away from OOP orthodoxy. We know now that OOP is inherently anit-modular, but we've raised a generation of developers that don't believe there can be any other way.
Re:Definitely not more future-proof! (Score:2)
Do you have some examples of how the Protopal stuff you mentioned can be useful/powerful? I've inhereted a large node.js project and I'm struggling to understand why anyone would ever want to build something in this as it seems unutterably confusing, convoluted and esoteric to me (I am not highly proficient in JavaScript).
A lot of the code was written by juniors (almost all it) and I wonder how much was hacked together from stack overflow and does not take advantage of 'good' JS patterns like you suggest exist.
Re:Definitely not more future-proof! (Score:2)
Re:Definitely not more future-proof! (Score:2)
I think a lot of the power comes from the language's incredible simplicity. There really isn't a lot to know about the language, but quite a bit to know about how it can be used. You can try to think of the language like this: You have first-class functions and closures (very important) with objects that are really just hashmaps with a few simple rules for looking things up. Classes don't exist and types are bound to values, not variables. Reflection is cheap.
Each object has a prototype which is just another object that can itself have a prototype. When you try to access a member, the object is checked first, then it's prototype, then it's prototype's prototype and so on. This is the basis of the inheritance model. Add to that first-class functions, and some sensible changes to the 'this' keyword and you have a very simple and far more powerful mechanism for composition as well.
I can't do much in a slashdot post, but you'll find that a lot of the so-called design patterns you used to use aren't necessary as they just fall out of the language. The decorator pattern, flyweight, visitor, strategy & template, and builders and factories being the most obvious.
All this freedom does mean you need to be more disciplined. However, if you follow some basic principles of modular design, you'll find that your code becomes significantly smaller and easier to maintain over all. Granted, you do need to stop thinking in terms of classes. You can certainly write code that way, and it may feel more comfortable at first, but that will make things harder in the long run. I've seen very well disciplined classical OO in JS and it's almost painful to see all of the wasted effort in what would have otherwise been a well-designed program (by classical standards, of course).
Start with Crockford's book, try a few things out, and do some reading on functional programming and event driven programming. That should at least let you more easily follow what the copy/paste mess you've inherited is trying to do.
Re: Definitely not more future-proof! (Score:0)
Re:Definitely not more future-proof! (Score:2)
I think it fair to say that JavaScript got going because it is simple to implement. For small stuff, it gets the job done. Scripting built in to a web browser allows you to do things that would be cumbersome if all computation had to be server side, and the browser is a mere formatting and display mechanism. Opinions may differ on this subject, but quick and dirty scripts in a loosely typed language do not tend to scale well. Does this variable represent a number, or is it a string? I somehow managed to add a number to an Object, as a result of a typo. This was apparently not a logic error, but I still don't know what it actually did.
The idea of WebAssembly appeals. Basically, you can distribute portable binaries, executed in the browser. This was supposed to happen with Java bytecode, but did not really gain traction. I am not sure what went wrong there. I am no fan of Java as a higher level language, but the idea of portable bytecode, generated from a higher level language of choice, seems to be pretty good.
Re:Definitely not more future-proof! (Score:2)
Re:Definitely not more future-proof! (Score:0)
JS doesn't HAVE TO suck, but.... (Score:2)
If you want types you can use Typescript. You're even already aware of it, so this rant is pretty retarded.
So what you're saying is that a toolset that gives dangerous options and has no intrinsic benefits over its competitors and usually sucks, but doesn't have to suck...so I am mentally deficient?
A chain is only as strong as its weakest link. So long as one developer write a module in JavaScript, you're stuck supporting it until you rewrite it. It's going to be difficult to refactor and maintain as it gets more complex and has been in production for a decade and changed teams half a dozen times.
You COULD make it work, but why would you when there are superior options? That's like saying one COULD make an eBike really fast and even really safe. My argument is that if you want speed, get a motorcycle. If you want safety get a good car. JavaScript has fundamental issues which one could overcome, but why not use a superior tool in the first place? JavaScript was designed to be a UI language. It was NEVER designed for backend programming and certainly not designed to replace Linux. It's rather silly to think it can.
Also, cut the R-work bullshit. You just look dumb and inarticulate. There are plenty of good counter-points to my argument, but you chose to write 2 dumb and vague sentences, including a stupid term that only a complete asshole would use. Throwing around the R-word is the domain of the mentally deficient. It's cruel and just really sloppy, lazy, and inarticulate. You can do better.
Re:JS doesn't HAVE TO suck, but.... (Score:2)
Re:Definitely not more future-proof! (Score:2)
Re:Aren't Javascript containers (Score:2)
Indeed. These monsters seem to get worse and worse.
Re:Aren't Javascript containers (Score:2)
Where's a mod point when I need one?
Re:Aren't Javascript containers (Score:2)
Or as I call them, "bloated pieces of s...".
This is a perennial pain in the butt. I have to reboot my laptop every few days, because the browser uses so much RAM that the machine resorts to swapping, then grinds to halt when ir runs out of swap. I have 8G of RAM. Time was when that would be a good size of hard disk. It does not seem to matter what browser I use. I used Firefox for years. Vivaldi might possibly be more efficient, but really, it is just the same shite as everything else.
I may not be the tidiest of computer users, so I tend to have multiple tabs open, on news websites, Wikipedia pages, electronic suppliers, and so on. But slurping 8G? What for? My actual work stuff, which is mainly PCB CAD and circuit simulation, barely causes a ripple, when compared to the average ad-laden web site.
I have written a bit of JavaScript, which was probably not a typical use, being a mathematical model of climate change and ice ages, with some interactive gubbins, so you could see the effect of varying the model parameters. It actually performed rather well. So maybe JavaScript as a computing engine is not the problem. It is perhaps the lazy way that people use the language. Comments from experts would be welcome.
Re:Aren't Javascript containers (Score:2)
But slurping 8G? What for?
The sky's the limit. Slack is an Electron "app" (ie, javascript on embedded chrome) and it OOMed for me on 128G.
the average ad-laden web site
Get uMatrix (not the uBlock Origin poo that blocks pretty much just visual stuff), in default-deny mode. It speeds Firefox by an order of magnitude, and memory-wise makes it usable on 1G 32-bit with frugal tabs or 4G 64-bit with usual hundred-tab usage.
Re:Aren't Javascript containers (Score:2)
This isn't meant for desktops. They seem to want to set open source standard for stuff like Cloudflare workers. Except node.js/javascript centric, so bad.
Bit late to the party.
Re:Aren't Javascript containers (Score:3)
"When all you have is a hammer, every problem looks like a nail."
Computer languages are not one-size-fits-all affairs. I don't understand the incessant desire to shove JavaScript into every computational niche, even in places where it doesn't really make a lot of sense.
This seemed to be the trend for Java fifteen or twenty years ago, until everyone realized what a horrible idea it was to tack Java onto the browser. I guess it's JavaScript's turn now, until people realize what a horrible idea it is to build all your back-end server logic using a browser-based scripting language.
Re:Aren't Javascript containers (Score:0)
Computer languages are not one-size-fits-all affairs. I don't understand the incessant desire to shove JavaScript into every computational niche, even in places where it doesn't really make a lot of sense.
Like C/C++ has been shoved into places where other languages would be better.
Re:Aren't Javascript containers (Score:2)
Re:Aren't Javascript containers (Score:2)
> having to deduce bug reports from C or C++ core dumps aka from a contiguous hexadecimal sludge (instead of a nice stacktrace)
There's this thing called a debugger. You should learn how to use it.
Re:Aren't Javascript containers (Score:2)
Re:Aren't Javascript containers (Score:2)
Re:Aren't Javascript containers (Score:1)
"When all you have is a hammer, every problem looks like the back of my boss's skull."
FTFY
Re:Aren't Javascript containers (Score:3)
I'm not sure I agree that people are trying to use the language "where it doesn't really make a lot of sense". Sure, there are a ton of places where JavaScript is absolutely the wrong choice, but that doesn't seem to be the case here. Ignoring that, I'll offer two reasons why people want to use JavaScript in places that aren't the browser: 1) There are a lot of developers who are familiar with it, even if they don't really understand the language. That makes hiring easy. 2) It's actually a really nice language, once you take the time to learn it. The trouble comes from people who don't, and try to write software the same way they do in Java or C#. That will end in disaster, and often does.
until everyone realized what a horrible idea it was to tack Java onto the browser.
You know what's funny? That seems to be exactly what everyone here seems to want! The common complaint here is that JavaScript isn't a strongly typed, compiled, language designed for building applications. Well, That's exactly what Java is. No, the problem with Java in the browser that got people so upset was performance. In the dial-up days, Java applets were slow to download and very slow to use, annoying both users and developers. By the time computers caught up, and Java improved in performance, the damage was done. The orthodoxy was that Java applets "suck" and no heresy was tolerated.
People also didn't like how GUI's worked in Java. In many ways, Sun was very forward thinking with their layout manager concept, but people at the time didn't want that at all. They wanted pixel-perfect control over positing of everything. It was common for applications to target specific screen resolutions, usually 640x480 or 800x600. The web was no different, of course, and "Optimized for 800x600" would have been a familiar sight. While Java and the web had similar philosophies about layout, developers almost universally disagreed. It was mobile phones that finally forced everyone to adapt, though they did so reluctantly.
Now that's all in the past. Java is out of the browser, and isn't likely to return. Be careful what you wish for, I guess.
Re:Aren't Javascript containers (Score:2)
I can kind of understand the use case for this, the problem is that for serverless code execution cloud providers are currently typically using containers to deliver FaaS, the problem is even in the best case you still have sometimes unacceptable cold start times if no instance of the execution environment is cached and available to serve.
This means the promise of cloud based hyper-scalability through FaaS for web apps has some real problems, on both ends of the scale:
- At the bottom end, low rates of concurrent execution, FaaS suffers from the cold start problem, you can't realistically serve backend requests for a front end site using FaaS in this scenario because there's never an instance ready to serve the request, so each time a user visits the site and a call is made to your FaaS function the cold start means you could see response times as bad as on the order of seconds, that's too long for user interaction.
- At the middle range the cold start problem goes away some degree because you have enough frequency of requests to your service that there's always a warm instance to serve the request and don't have the cold start problem for all your users. You still have it for some of your users however as demand ebbs and flows; your functions still have to scale up and scale down appropriately and so it becomes a headache making sure you don't under or overprovision (note you can have this problem at the low end too using things like provisioned concurrency for AWS lambdas or Azure Premium functions).
- At the high end you have different issues, the promise of FaaS, serverless, and infinite scalability vanishes. AWS only allows 3000 concurrent Lambda executions in even their largest data centres for example, that's a reasonable load but I've worked on services where you need to go to say 50,000 concurrent requests and so AWS Lambdas just can't do it - your users get sporadic HTTP 429 errors as it throttles your requests. AWS can up this limit for you, but at that point again you're really fudging a solution into a cloud architecture that's straining to cope. Amazon's limits are because for all the hype, even Amazon having to fire up 3000 containers for a number of customers at once can become a strain on their capacity; forcing people to explicitly ask for a higher cap means they can better do capacity planning for customers on any given region.
So it's not entirely surprising therefore there's a push for a more granular type of container; one that's faster to spin up, whilst still be isolated from other execution environments, and has less overhead than even Linux containers. Such a thing is needed to get us closer to that goal of a cloud environment that can support both small and large web app back ends alike, because right now the issues above mean that FaaS is often limited to other types of workflow, like background order processing and that kind of thing.
I imagine therefore, that this is what this solution is oriented towards. The problem is it's not language agnostic, meaning you'd need a similar solution for other supported languages. Ideally you need an execution environment to be able to guarantee it'll spin up, process and respond to a request on the order of mere milliseconds in an isolated execution environment.
Disclaimer: I 100% agree with you around the usage of JS, I use it professionally day in day out at a FAANG scale company right now, but have worked with C, C++, Java, C#, PHP, and Python professionally in the past. Companies shouldn't be using JS like they are, it's genuinely leading to poorer quality code, but employers are being baited in by the hoards of cheap young code camp students getting taught JS. We also use TS, but unless you understand OO and types properly these devs just end up treating TS like JS; the second they encounter the need for a complex type they just resort to the any type and go back to the JS way of doing things and it rapidly becomes a clusterfuck once more. By the time you've taught them to code properly you might as well have just used a more appropriate language like Java, C#, Go, Rust, C++ or similar and trained people from the ground up yourself through an apprenticeship programme, so it's really a false economy using JS because of the "ease of use", or "cheap labour".
Re:Aren't Javascript containers (Score:2)
I guess it's JavaScript's turn now, until people realize what a horrible idea it is to build all your back-end server logic using a browser-based scripting language.
I think there is a very good case for browser-based computation. One example is the browser app, with buttons to click on, windows or boxes to enter text, and so on. Posting all this user input to a server, and getting a response, can be woefully inefficient.
I agree that using a quick-and-dirty script running in the browser is no substitute for properly developed server side code.
Re:Aren't Javascript containers (Score:2)
Re:Aren't Javascript containers (Score:2)
Will Feces Overtake Pizza? (Score:4, Insightful)
Re:Will Feces Overtake Pizza? (Score:4, Insightful)
Number of humans who eat pizza: ~7.9 billion.
Number of insects who eat shit: ~ 5 quintillion.
Clearly, shit is the most popular choice.
Re:Will Feces Overtake Pizza? (Score:2)
So... (Score:2)
Will JavaScript Containers Overtake Linux Containers
[A JavaScript sandbox container] isn't meant to address the same breadth of problems that Linux containers target.
Asked and answered -- no.
My eyes, my eyes (Score:3)
"It minimizes the boilerplate for web service business logic."
I feel dumber just having read that little piece of sales-speak.
"the total amount of experience the engineer needs is reduced."
Yeah, when we're talking about deploying and managing something that itself will be exposed to the world at large, what I'm looking for is people with less experience. But then, I can take comfort in the recent security track record of stuff like npm...
Re:My eyes, my eyes (Score:2)
Making complex inheritance models because they can't describe the business logic. They can only give you abstractions that they hope the code will magically make coherent...
Re:My eyes, my eyes (Score:2)
More and more people are finally waking up. It's good to see. It gives me hope.
Seeing how things are now makes you appreciate COBOL in a whole new way...
If the title is a question (Score:2)
Oh God, no! (Score:1)
Did anyone have to deal with the literal actual clusterfuck that is node.js? It constantly has security updates and is a rat's nest of a dependency fuck-land and was invented by the same idiots peddling javascript containers. I know node and javascript containers aren't the same .. but goddammit it, it is guilty by association fuck it. Not worth the risk at all.
Re:Oh God, no! (Score:3)
Google is pushing all kinds of updates to Chrome's Javascript, and has been doing for a while now. Since Chrome is dominant, websites are making use of these "features" and the Javascript "standard" has pretty much come to be whatever Google says it is.
Oh God, no!
Re:Oh God, no! (Score:2)
A webdev is NOT an engineer (Score:1, Troll)
They're the bottom of the pile in the programming world, the equivalent of go kart racers in motorsport. Sorry if this pisses of the script kiddies truth hurts.
Re:A webdev is NOT an engineer (Score:2)
I'm sure Lua [wikipedia.org] forgives you.
Re:A webdev is NOT an engineer (Score:3, Informative)
Developers, in general, aren't engineers. There is nothing about programming that is remotely similar to engineering. To compare yourself to an engineer is to disparage engineers across the globe.
Programmers like to pretend that they're a lot of things that they aren't. They aren't mathematicians. They aren't logicians either. The sure as hell aren't engineers!
Programming is just skill, like writing or painting. It's also a skill that anyone can learn. It's so easy, in fact, that young children can and often do teach themselves! You are not special because you can write computer programs. Many actual professionals, like scientists and real engineers, often pick up programming as part of their normal work. You'll see a lot of them humbly claim that they "aren't very good" but what they don't realize is that many programmers, particularly those who fancy themselves engineers, aren't any better.
It's also illegal in many places to call yourself an engineer if you're not actually an engineer. Keep that in mind.
Re:A webdev is NOT an engineer (Score:2)
Programmers like to pretend that they're a lot of things that they aren't. They aren't mathematicians. They aren't logicians either. The sure as hell aren't engineers!
Depends on the programmer.
Where I live there are programmers and:
* software engineers
* computer scientists
Etc ... I'm all 3 above, and depending what "certificate" you count: a mathematician and a physicist.
Re:A webdev is NOT an engineer (Score:2)
> To compare yourself to an engineer is to disparage engineers across the globe.
You're either ignorant, or a manager, or both.
This is not the correct analogy:
Makes blueprints Engineer Architect
Builds things based on blueprints Worker Builder Programmer
This is the correct one:
Makes blueprints Engineer Architect Programmer
Builds things Worker Builder Compiler/Interpreter
> Programmers like to pretend that they're a lot of things that they aren't.
> They aren't mathematicians. They aren't logicians either. The sure as hell aren't engineers!
Engineers aren't mathematicians, they aren't logicians either, and sure as hell aren't programmers.
> Programming is just skill, like writing or painting. It's also a skill that anyone can learn.
> It's so easy, in fact, that young children can and often do teach themselves!
Young children also like to paint, but most of them don't become Vermeer or Rembrandt or van Gogh.
> You are not special because you can write computer programs.
Then why is it that the average wage is seven times lower than what I make for writing computer programs ?
If everybody is able to do it, everybody should be paid the same, right?
> It's also illegal in many places to call yourself an engineer if you're not actually an engineer. Keep that in mind.
Yeah well, in Massachusetts it's illegal to tell fortunes without certification. ( https://www.goodhousekeeping.com/life/news/g4039/crazy-state-laws/ )
"There are two kinds of people in the world: the righteous and the wicked. Categorization is always made by the righteous."
Re:A webdev is NOT an engineer (Score:2)
There is nothing about programming that is remotely similar to engineering.
What a strange notion. As far as I am concerned, engineering is the business of making stuff work, which might involve some invention, but is mostly doing what people want, at a reasonable cost. When writing programmes, I use exactly the same principles as I use in designing electronic circuits. Writing in C++, you can build components, that are tested to make sure they work, and then are integrated to form systems. I am pushed to think of any programming language where this approach is not appropriate. If programming is not engineering, then what is it? Accountancy? Astrology? Ballet dancing?
Re:A webdev is NOT an engineer (Score:3)
Re: A webdev is NOT an engineer (Score:2)
If you dont think avionic systems get software updates then theres a bridge for sale with your name on it. Hell, even NASA update the software in their probes during the mission!
Re: A webdev is NOT an engineer (Score:2)
Re: A webdev is NOT an engineer (Score:2)
You mean like Boeings MCAS?
Its not nit picking at all.
Re:A webdev is NOT an engineer (Score:2)
Put another way, programming is programming, but programmers like to call themselves 'engineers' because the like the romanic image of it, but don't want to actually do the things engineers do.
Re:A webdev is NOT an engineer (Score:2)
Maybe I have been lucky, then, because engineering has been far from boring for me. Writing software, particularly embedded stuff, was just cool new things to make stuff work. Combine that with some RF circuit design and antennas, and you are in major fun territory. I did meet some useless plonkers who were titled engineers, who could do the paperwork, but not actually design something to meet a specification. I am not exactly sure these twits could actually analyse a circuit on paper, in the way my father taught me, when I was still at school. Engineering is fun.
Comment removed (Score:2)
Re:God no (Score:2)
No systemd?
Comment removed (Score:2)
Re:God no (Score:2)
Re:God no (Score:2)
Care to fucking show me a JavaScript-engine that's faster and more resource-efficient than e.g. Bash?
I came to the conclusion long ago that all Unix style shells are horrible, when considered as programming languages. I did do some big shell stuff for installing software on Linux. Not pleasant. JavaScript may be less evil than shell, but that is not saying much.
When it comes to resource efficiency, this really comes down to whether you care enough to even measure this. One interesting problem I dealt with recently was an electronic parts inventory, with each item having an in-house part code, a description, a manufacturer, and a part number. An ideal fit for a database, you might think. Or at least a dictionary data structure. Turns out the whole thing could be implemented in a text file, using pipe-delimited fields. A linear search for items, based on combinations of attributes, is fast enough that there is no benefit in a more efficient binary search. In fact, writing queries in SQL was a pain in the arse, compared to a bit of regex stuff. What I found with the stupid simple PSV format is that it dropped straight into LibreOffice Calc, and I could grep for stuff. Maybe this dumb system won't scale well, but there is the practical consideration that adding new items to the inventory requires some application of knowledge, and that is my job. As I am getting on a bit in years, and a lazy bastard, I think inventory search efficiency might be a non-problem.
Comment removed (Score:2)
Re:God no (Score:2)
What I found with the inventory application was that a dumb system actually saved a lot of trouble. I wasted a lot of time trying to implement the system in SQLite. Maybe the SQL searches were quicker, but the overhead was in entering the data, then extracting results for presentation in spreadsheets. There was a sound reason for using pipe as a delimiter, rather than comma. One of the fields I copy-pasted off a supplier website was a string comprising a comma separated list of attributes. The pipe symbol was never used in these strings. When I messed with SQLite, pipe-separated fields were the standard way to export data, and LibreOffice was quite happy with that too.
I would hardly call SQL "the newest fancy shit". I think what I was guilty of was optimising the wrong thing. Searching into a PSV file using regexes in Python proved to be adequate in terms of speed. Actually creating the data entries was much easier in a dumb text file format than it was using a smart database format. Another point is that PSV is easily analysed using general purpose tools such as grep.
Returning to the original topic, the question was whether JavaScript is more resource efficient than Bash. This strikes me as the wrong question. The point is which tool allows you make scripts that work, and in my experience, I have loads of Bash scripts doing useful things, and no JavaScript. I am not entirely sure how I would use JavaScript for my little scripting jobs. Python does fine for me if I am doing any kind of computation.
Re:God no (Score:2)
I hate shell, but it's one of the few things you can reasonably count on being on any reasonable system. Even Windows if wsl or cygwin is installed.
I used VBScript on Windows for many years for the same reason: on Windows, it's the one thing you can count on being on pretty much every Windows machine. (Though gradually being replaced with Powershell, which manages to be in some ways a more wretched language than VBScript.)
I'd love to ditch all of the above for Python, but it isn't on all systems, is sometimes grossly outdated (Python 2.x still default on some systems I support), and starts becoming a pain the moment you have to use any of the libraries not included with Python itself. Sure, you can use pip (or is it pip3, oh, and by the way, where is it?), or create venvs. Still way more complex than writing a shell script, at least to me. It's a really good scripting language, and I love to use it on my own systems, but really hate having to distribute it to other folks who might or might not be running Linux, might or might not have sudo privs, might or might not have a modern Python3, or might or might not be willing to drop to a command prompt.
(And, no, of course, this is not a problem specific to Python . . but it irks me since it's such a nice language otherwise.)
Re:God no (Score:2)
I hate shell, but it's one of the few things you can reasonably count on being on any reasonable system.
The same applies to many tools on Unix-like systems. They are not generally the best tools, but you can rely on them being there. One example of this is GNU automake and autoconf, which use very basic tools such as the m4 macro processor and loads of shell stuff, in order to make installation from source code portable. That might also be the reason why so many applications are written in C. I like writing in C for embedded firmware, where resources are limited, and you really need to poke at bytes and bits in detail, but I find C a total pain for desktop applications, which I generally write in C++. Rust is even better, in my opinion, but maybe still a bit new.
There are certainly better tools for portable compilation from source code than the typical autoconf/automake setup. I have had some success with Qmake. Cmake is pretty good, but I don't use it often enough to be fluent in using it. Having said that, I got precisely nowhere with autoconf/automake for my own projects, so I guess the new stuff has its advantages.
An interesting point, with regard to getting rid of nasty old shell, is the replacement of SysV style boot scripts with systemd. Some time ago, I ran FreeBSD as my home system, and one thing that impressed me was the neat and well-documented boot system. Before that, I ran Mandrake, which adopted the Red Hat startup scripts, if I recall. I spent many frustrating hours tracking down which files to poke in order to configure Mandrake, so FreeBSD came as something of a relief. It was unfortunate that FreeBSD could not provide drivers for some of my hardware, such as the TV receiver card, which worked fine on Linux. The basic problem I have with systemd is that it is not what I call "greppable". You have to learn new stuff to find things in logs, and I admit I am still not fluent. It took me ages to discover that the cleaner I recently employed had unplugged the Ethernet cable from the router.
That actually would make sense. (Score:4, Insightful)
Having a JS VM that can run in multiple instances on a given system without those interfering with each other would totally make sense. This container-fad is getting out of hand anyway, might as well just run a bundle of JS/TS services right away. And Deno is the perfect candidate for such a thing as it does away with all the shortcomings of Node. It's basically a new major release of Node doing some necessary breakage of old outdated Node shortcomings with neat features such as native TS support added in. Very nice.
As a dev who uses PHP for all server-side needs I am quite annoyed about this container fad that bloats every small web project into an overblown wannabe SOA-monstrosity that needs babysitting 24/7 like some 90ies Enterprise Java behemoth. I'm sick and tired of it, also because deciders who demand "Containers!" can't tell when they make sense and when they most definitely are a really stupid idea.
However if Deno does all this without container push-ups and I can just start and stop regular Deno daemons and have no hassle with kernel-namespacing, that would totally make sense for dynamic webapps, especially if you can use the same PL on the server as one does in the browser. Since Deno offers the entire regular browser API on the server-side that could make things really interesting in the web-development camp.
Re:That actually would make sense. (Score:2)
Re:That actually would make sense. (Score:2)
As a dev who uses PHP for all server-side needs
I would call that instant disqualification from commenting on anything dev related :D
Re:That actually would make sense. (Score:0)
As a dev who uses PHP for all server-side needs
You don't get to judge anything, go back to the little kid table please and let the grown ups talk.
286 protected mode (Score:2)
That's all I need for process isolation.
so many wrong things (Score:4, Interesting)
... and it's only in the summary, as i refuse to read the article.
scripting languages are "all pretty much the same"
strike 1
JavaScript is "by far more widely used and future proof."
strike 2
JavaScript takes the place of Shell. It is quite a bit better suited to scripting than Bash or Zsh
strike 3, you are out.
Re:so many wrong things (Score:2)
Well, "incompetent" is the new "expert". This article nicely demonstrates that, but it seems to be a general IT trend that fewer and fewer people undertstand how things actually work.
Re:so many wrong things (Score:2)
Re:so many wrong things (Score:2)
Totally agree with this. I have not seen any way in which JavaScript can be used on the command line, and thus be a replacement for a shell. It could be that a scripting language such as JavaScript could be better for writing scripts that start and configure a Linux system. It is a while since I ran FreeBSD. They experimented with Ruby, as an alternative to shell. This might be an inadvisable dependency.
I am inclined to the view that all scripting languages are dangerous. The first industrial strength scripting language I used was Perl. I made a fair bit of use of it, but its massive syntactical complexity became a liability. It is all vert well saving a bit of typing when reading a file line by line, but does the language need some special syntax for that specific purpose? Python is much simpler, and equally powerful. However, I still think the layout rules were a bad mistake. I don't have much of a problem with typing curly brackets. Trying to make computer code look like English is of course a mortal sin, and people should understand that computers don't think, and they most certainly do not care for the welfare of people. I have been on the receiving end of some cybernetic cruelty from my bank recently. I would have been much happier with a muscular Austrian armed with a shotgun.
Did node.js become an OS? (Score:1)
If not, then the whole exercise is just stupid. Containers already need an OS to run under, typically Linux or an abstraction of it. So it will always be Linux containers.
You can fit Linux on a floppy, so any modern server UEFI could contain a full container execution platform.
Re:Did node.js become an OS? (Score:2)
I wonder what is the difference in running node.js or this container version of javascript?
Yes (Score:0)
Containers are stupid (Score:3)
Seriously. Containers are a crutch for people that do not understand how to use conventional OS based isolation, i.e. for _incompetent_ people. As to updates, they make the problem worse: Suddenly you do not only need to keep the libraries in the base OS up to date, you also need to do this for the containers. Sure, a container may (or may not) get maintenance initially, but over time you end up with a problem that is far worse than the initial one.
The whole idea is bad and was obviously pushed by people that cannot think longer-term.
Re:Containers are stupid (Score:0)
Containers are conventional OS based isolation.
If you're talking about chroot/jails then those are containers.
If you're talking about user based isolation. Yeah, well, that has never been enough. It might partially work if all of the software has no bugs. Good luck with that. But even then there are certain things you can do in a container that are impossible when using the old ways.
We live in times where you have to have security in depth. That is, layers. The software is too poorly written to do otherwise. So you mix and match hoping to cover more cases. It's like when you have those plastic grocery bags that always have holes in them so you use 3 or 4 to make sure stuff doesn't leak out too much.
I've been impressed by the work done in JS (Score:0)
I've been impressed by the work done in JS. Like emulators, games, and stuff. But my god, how much slower do we want things to be? We keep layering piles of garbage on top of piles of garbage. Memory usage of browsers is ridiculously wasteful and poorly implemented.
Remember when you could run a complete operating system in a few K of RAM?
Hell, even Linux was bloated when it came out. Requiring a couple MB of RAM (actually 4MB RAM to be able to barely run X).
Now I know there has to be bloat otherwise we wouldn't get features but today's software is totally off the rails. People have no idea how much lighter, faster, more powerful, cheaper, and just better, that software could be if developers actually knew and cared about what they were doing.
Re:I've been impressed by the work done in JS (Score:2)
You mean operating system like C64 had, with static hardware and where most apps had to directly modify screen memory instead of using Kernal calls and there was no OS support for graphics etc. Nor for any peripherials, they came with ROM or every app using them had the drivers included in the app instead of in the OS.
yupp, we're doomed (Score:2)
Great idea. Let's put docker down the frontend. So instead of dependency hell, you now have "can't patch this or it'll break" hell. Ten years from now we'll cry because we just handed a huge bunch of security vulnerabilities waiting to happen to the hacker world.
Well, maybe it'll finally force the backend dev to REALLY not trust the client anymore.
Yuk (Score:2)
Behind the Times (Score:2)
Re: Behind the Times (Score:1)
Um the guy who wrote node also writes deno.
Just providing the info not trolling.
The notion is idiotic (Score:2)
Yes, because the Javascript engine is such a wonderfully hardened environment in which to attempt isolation. I mean it's not like anything's ever managed to escape that sandbox, is it?
Stupid headline is FUCKING STUPID. Anyone advocating for Javascript containers is - in the words of my people - a FUCKING moron.