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: (Score:2)
"Is Betteridge's law of headlines correct?"
Re: (Score:2)
Re: (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 ea
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: (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.
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 de
Re: (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
Re: (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
Re: (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 devel
Re: (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 ex
Re: (Score:2)
Re: (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 a
Re: (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
Re: (Score:2)
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 CO
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Indeed. These monsters seem to get worse and worse.
Re: (Score:2)
Where's a mod point when I need one?
Re: (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 mult
Re: (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: (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: (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 buil
Re: (Score:2)
Re: (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: (Score:2)
Re: (Score:2)
Re: (Score:1)
"When all you have is a hammer, every problem looks like the back of my boss's skull."
FTFY
Re: (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
Re: (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 concu
Re: (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: (Score:2)
Re: (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: (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: (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: (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: (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: (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: (Score:2)
I'm sure Lua [wikipedia.org] forgives you.
Re: (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 a
Re: (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: (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 t
Re: (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
Re: (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: (Score:2)
Re: (Score:2)
You mean like Boeings MCAS?
Its not nit picking at all.
Re: (Score:2)
Re: (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
Re: (Score:2)
Re: (Score:2)
No systemd?
Re: (Score:2)
Re: (Score:2)
Re: (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
Re: (Score:2)
Re: (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 w
Re: (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 some
Re: (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
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: (Score:2)
Re: (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
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: (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: (Score:2)
Re: (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 scrip
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: (Score:2)
I wonder what is the difference in running node.js or this container version of javascript?
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: (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.