Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming Cloud Linux

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.

This discussion has been archived. No new comments can be posted.

Will JavaScript Containers Overtake Linux Containers?

Comments Filter:
  • by K. S. Kyosuke ( 729550 ) on Saturday May 07, 2022 @01:37PM (#62512180)
    The Inner Platform Effect is strong with this one.
    • by fleabay ( 876971 ) on Saturday May 07, 2022 @01:55PM (#62512220)
      Betterridge proven wrong with a recent story called
      "Is Betteridge's law of headlines correct?"
      • by ffkom ( 3519199 ) on Saturday May 07, 2022 @03:50PM (#62512438)
        I honestly wonder whether those praising "Betteridge's law of headlines" would prefer living in a world where no article writer dares to express uncertainty or doubt in a headline. Question marks may be somewhat over-represented among click-bait headlines, but a headline "Chocolate heals cancer" is not preferable over one reading "Does chocolate heal cancer?".
        • by vux984 ( 928602 ) on Saturday May 07, 2022 @05:17PM (#62512654)

          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 :)

        • by AnonymousNoel ( 6972222 ) on Sunday May 08, 2022 @02:48AM (#62513424)

          "Chocolate may heal cancer" does the job somewhat better, without sensationalising or using a question mark.

  • by Rosco P. Coltrane ( 209368 ) on Saturday May 07, 2022 @01:38PM (#62512182)

    called "browsers"?

    Or as I call them, the OS within your OS.

    • by KiloByte ( 825081 ) on Saturday May 07, 2022 @01:46PM (#62512196)

      Or as I call them, "bloated pieces of s...".

      • by Somervillain ( 4719341 ) on Saturday May 07, 2022 @02:00PM (#62512230)

        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.

        • by narcc ( 412956 ) on Saturday May 07, 2022 @04:34PM (#62512540) Journal

          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.

          • by Anonymous Coward on Saturday May 07, 2022 @07:05PM (#62512854)

            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.

          • by Somervillain ( 4719341 ) on Saturday May 07, 2022 @07:12PM (#62512872)
            You gave a lot of advice for writing better JavaScript. Here's the problem. I'm employed. I am a professional. I work on large teams. I don't worry about me. I worry about everyone else.

            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.
            • by narcc ( 412956 ) on Sunday May 08, 2022 @12:57AM (#62513312) Journal

              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.

              • by Pieroxy ( 222434 ) on Sunday May 08, 2022 @04:08PM (#62514924) Homepage

                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.

                • by narcc ( 412956 ) on Monday May 09, 2022 @03:45PM (#62517714) Journal

                  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.

          • by trawg ( 308495 ) on Sunday May 08, 2022 @12:31AM (#62513276) Homepage

            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.

            • by jythie ( 914043 ) on Sunday May 08, 2022 @12:12PM (#62514342)
              Flexing? Fancy language features that are tricky to use and mostly do the same thing you could do before are a good way to tell the 'in' or 'enthusiast' programmers from the unwashed ones?
            • by narcc ( 412956 ) on Monday May 09, 2022 @02:24PM (#62517414) Journal

              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.

          • by ghrom ( 883027 ) on Sunday May 08, 2022 @03:55AM (#62513516)
            So many words to tell us you are retarded? HTTPS://unemployables.propercode.Co.uk
          • by WierdUncle ( 6807634 ) on Sunday May 08, 2022 @07:08AM (#62513712)

            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.

        • by h33t l4x0r ( 4107715 ) on Saturday May 07, 2022 @05:59PM (#62512746)
          If you want types you can use Typescript. You're even already aware of it, so this rant is pretty retarded.
          • by Anonymous Coward on Saturday May 07, 2022 @06:32PM (#62512798)
            Retarded to me is anyone thinking about using a shitty scripting language on servers and other mission critical systems.
          • by Somervillain ( 4719341 ) on Saturday May 07, 2022 @09:52PM (#62513110)

            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.

            • by h33t l4x0r ( 4107715 ) on Sunday May 08, 2022 @01:13AM (#62513326)
              Because you chose to complain about Javascript's lack of types while simultaneously acknowledging that yes it has types now. Yes it was originally something else and now it's not that thing anymore. It's 2022, ES6 has been around for 7 years and you need to find something else to complain about if you don't want to come off as a dinosaur.
        • by jythie ( 914043 ) on Sunday May 08, 2022 @12:08PM (#62514336)
          See, I think the problem isn't the language, but the ecosystem. Javascript itself is a fine language, even without a compiler to check things for you. When used in isolation is is pretty reasonable and I would not really describe it as better or worse than other common language. However, once you start brining in the rats nest that are the common libraries things go down hill pretty quickly... though TBH, I see the same issues with Java and its use in enterprise, so I chalk it up to the culture/industries that are using it and the things they think make sense to add.
      • by gweihir ( 88907 ) on Saturday May 07, 2022 @06:48PM (#62512824)

        Indeed. These monsters seem to get worse and worse.

      • by Bu11etmagnet ( 1071376 ) on Sunday May 08, 2022 @02:30AM (#62513398)

        Where's a mod point when I need one?

      • by WierdUncle ( 6807634 ) on Sunday May 08, 2022 @06:44AM (#62513702)

        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.

        • by KiloByte ( 825081 ) on Sunday May 08, 2022 @08:25AM (#62513816)

          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.

    • by Pinky's Brain ( 1158667 ) on Saturday May 07, 2022 @02:05PM (#62512238)

      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.

    • by Dutch Gun ( 899105 ) on Saturday May 07, 2022 @02:22PM (#62512278)

      "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.

      • by Anonymous Coward on Saturday May 07, 2022 @02:52PM (#62512330)

        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.

        • by kurkosdr ( 2378710 ) on Saturday May 07, 2022 @03:46PM (#62512422)
          Who said that was a good idea? I wonder if there ever be a rough estimate for the hours of developer productivity lost from having to micromanage memory, re-inventing Java's libraries, and having to deduce bug reports from C or C++ core dumps aka from a contiguous hexadecimal sludge (instead of a nice stacktrace), while working on C or C++ software that never needed C or C++ in the first place. Fortunately the business world has wisened up and moved to Java (and recently Python for some stuff) for business software.
          • by Bu11etmagnet ( 1071376 ) on Sunday May 08, 2022 @02:35AM (#62513406)

            > 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.

            • by kurkosdr ( 2378710 ) on Monday May 09, 2022 @02:28PM (#62517432)
              There is a thing called heisenbugs. Which may happen on production systems after the software has been running for years without issue, not on dev machines. I understand that this might come off as a surprise to you if you are a graybeard delivering code "AS-IS AND WITHOUT WARRANTY" (with that particular term always written in caps as to make it extra annoying), and if you close any bugs that do not contain step-by-step instructions on how to reproduce them as "cannot reproduce", but if you are dealing with financial or gambling regulators (I work for a company that deals with the latter), you can't exactly do that.
              • by kurkosdr ( 2378710 ) on Monday May 09, 2022 @02:41PM (#62517476)
                I mean, don't get me wrong, there are ways to dig through a core dump with a debugger, but none of them are particularly intuitive or time-efficient unless done on a dev machine with debug symbols and IDE tracing, that's why most C or C++ developers won't deal with a crash bug unless given instructions to reproduce it. Now imagine doing that while your employer wants an explanation for the bug and a fix ASAP. It's why most companies no longer do C or C++ unless they have some legacy codebase that they have to maintain. Or unless they do graphics, video compression etc, where they need every bit of performance they can get. Most corporate software has moved to Java with a bit of Python.
      • by Anonymous Coward on Saturday May 07, 2022 @03:57PM (#62512454)

        "When all you have is a hammer, every problem looks like the back of my boss's skull."

        FTFY

      • by narcc ( 412956 ) on Saturday May 07, 2022 @05:34PM (#62512696) Journal

        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.

      • by Xest ( 935314 ) on Saturday May 07, 2022 @07:00PM (#62512850)

        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".

      • by WierdUncle ( 6807634 ) on Sunday May 08, 2022 @07:26AM (#62513736)

        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.

      • by jythie ( 914043 ) on Sunday May 08, 2022 @12:14PM (#62514352)
        I always liked 'when all you have is a hammer, everything starts to look like a thumb'.
    • by AmazingRuss ( 555076 ) on Saturday May 07, 2022 @04:55PM (#62512596)
      no, this is a different bloated shitshow.
  • by organgtool ( 966989 ) on Saturday May 07, 2022 @02:06PM (#62512246)
    The day that such a ridiculous thing happens is the day I go elsewhere.
  • by fahrbot-bot ( 874524 ) on Saturday May 07, 2022 @02:08PM (#62512248)

    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.

  • by 93 Escort Wagon ( 326346 ) on Saturday May 07, 2022 @02:09PM (#62512250)

    "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...

    • by Kremmy ( 793693 ) on Saturday May 07, 2022 @02:49PM (#62512322)
      Business Logic, the age old problem looking for a solution, pushing languages that have so much abstraction you can't reasonably expect to actually break down the 'business logic' in a logical way.
      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...
  • by comodoro ( 4850881 ) on Saturday May 07, 2022 @02:23PM (#62512282)
    The answer is usually no while the article makes case for yes
  • by backslashdot ( 95548 ) on Saturday May 07, 2022 @02:24PM (#62512284)

    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.

  • by Viol8 ( 599362 ) on Saturday May 07, 2022 @02:27PM (#62512288) Homepage

    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.

    • by Ostracus ( 1354233 ) on Saturday May 07, 2022 @03:01PM (#62512340) Journal

      I'm sure Lua [wikipedia.org] forgives you.

    • by narcc ( 412956 ) on Saturday May 07, 2022 @05:52PM (#62512734) Journal

      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.

      • 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.

      • by Bu11etmagnet ( 1071376 ) on Sunday May 08, 2022 @03:57AM (#62513518)
        > 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.

        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."
      • by WierdUncle ( 6807634 ) on Sunday May 08, 2022 @07:53AM (#62513768)

        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?

        • by crobarcro ( 6247454 ) on Sunday May 08, 2022 @09:14AM (#62513904)
          There's a kind of programming that's a lot like engineering, and that's producing stuff that has to work right first time, and every time. Things like air traffic control, autopilot software etc. In engineering you generally get one shot to get the thing right (after prototypes obviously). Then you make the real one ( or million) and if you got it wrong, you're fucked. You can't issue an update, it really really has to work. The process of getting to that state is engineering.
        • by jythie ( 914043 ) on Sunday May 08, 2022 @12:22PM (#62514372)
          The problem with 'engineering' is over the years more and more professionals want to call themselves 'engineer', so the usage of the words has gotten pretty muddied lately... this has really accelerated lately because, well, to put it bluntly, engineering is a lot more tedious than the vast majority of people who like to call themselves 'engineers' would put up with. Engineering tends to be very formalized, it is a lot of planning and paperwork and calculation, with the 'make stuff' part being the 'fun' part that outsiders mythologize. One of the reasons you see so few actual 'software engineers' is CS majors tend to find all that process and validation to get in the way of making 'cool stuff'.

          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.
          • by WierdUncle ( 6807634 ) on Sunday May 08, 2022 @02:15PM (#62514634)

            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.

  • by account_deleted ( 4530225 ) on Saturday May 07, 2022 @02:51PM (#62512324)
    Comment removed based on user account deletion
    • by DontBeAMoran ( 4843879 ) on Saturday May 07, 2022 @02:58PM (#62512336)

      No systemd?

    • by WierdUncle ( 6807634 ) on Sunday May 08, 2022 @08:27AM (#62513820)

      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.

      • by account_deleted ( 4530225 ) on Sunday May 08, 2022 @09:35AM (#62513980)
        Comment removed based on user account deletion
        • by WierdUncle ( 6807634 ) on Sunday May 08, 2022 @01:38PM (#62514554)

          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.

      • by Joey Vegetables ( 686525 ) on Monday May 09, 2022 @09:03AM (#62516506) Journal

        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.)

        • by WierdUncle ( 6807634 ) on Monday May 09, 2022 @12:25PM (#62517054)

          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.

  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Saturday May 07, 2022 @03:05PM (#62512350)

    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.

  • by Gabest ( 852807 ) on Saturday May 07, 2022 @04:00PM (#62512470)

    That's all I need for process isolation.

  • so many wrong things (Score:4, Interesting)

    by Espectr0 ( 577637 ) on Saturday May 07, 2022 @04:02PM (#62512474) Journal

    ... 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.

    • by gweihir ( 88907 ) on Saturday May 07, 2022 @06:46PM (#62512820)

      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.

    • by Guignol ( 159087 ) on Sunday May 08, 2022 @04:08AM (#62513534)
      No no, let it happen, it will end as badly you can expect, in fact, likely more than we can imagine, but if it can take with it the whole container madness, then I'm all for it
    • by WierdUncle ( 6807634 ) on Sunday May 08, 2022 @09:22AM (#62513926)

      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.

  • by guruevi ( 827432 ) on Saturday May 07, 2022 @04:15PM (#62512514)

    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.

  • by kurt_cordial ( 6208254 ) on Saturday May 07, 2022 @04:25PM (#62512526)
    Twitter influencers will overtake federal agencies.
  • by gweihir ( 88907 ) on Saturday May 07, 2022 @06:45PM (#62512816)

    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.

    • by Anonymous Coward on Saturday May 07, 2022 @11:42PM (#62513218)

      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.

  • by Anonymous Coward on Saturday May 07, 2022 @08:08PM (#62512924)

    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.

  • by Tom ( 822 ) on Sunday May 08, 2022 @02:01AM (#62513362) Homepage Journal

    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.

  • by SuperDre ( 982372 ) on Sunday May 08, 2022 @07:04AM (#62513708) Homepage
    Javascript. Nope. It's time to dump the ugly language and embrace blazor.
  • by kopecn ( 1962014 ) on Sunday May 08, 2022 @08:00PM (#62515390)
    has either the author or Deno ever heard of node or lambda? or perhaps serverless? Do they live with their heads in the ground?
  • by Cryptimus ( 243846 ) on Monday May 09, 2022 @11:44AM (#62516910) Homepage

    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.

One can't proceed from the informal to the formal by formal means.

Working...