TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

JavaScript Containers

177 pointsby 0xedbabout 3 years ago

22 comments

beeandapenguinabout 3 years ago
There&#x27;s a lot more to unpack from this concept than Ryan&#x27;s post is letting on. I&#x27;m seeing a lot of negative sentiment, largely focused on negative opinions towards JavaScript.<p>This is entirely besides the point. The emphasis is mostly on V8, which we all know is first and foremost a JavaScript engine. But it is also a WebAssembly engine, meaning several languages beyond JavaScript can execute with the approach he&#x27;s talking about.<p>What the post doesn&#x27;t really go into detail on is how V8 is arguably the most secure runtime in the world. The browser runtime is one of the most battle tested pieces of software ever built. At its core, it enables remote code execution <i>on anyone&#x27;s machine</i>. It has a robust security model. Your program can&#x27;t do whatever it wants on the host operating system, unless granted by the user.<p>Docker Containers were an improvement over Virtual Machines by enabling dependency snapshots and compiled programs on top of an OS. V8 Isolates (translation: chrome tabs) are an improvement over Containers. Cloudflare&#x27;s discovery here is what enabled them to build their edge network. With a containerized server deploy, you can execute dozens of concurrent, isolated V8 programs without needing to spin up a new container for each of them. The server also has complete control over execution time and memory. If a V8 program consumes more than its budget, it can easily be terminated.<p>Runtime performance concerns about JavaScript are also misguided. With Rust, it&#x27;s easier than ever to write native functions that can be executed in JS or WASM. Extending the V8 codebase has historically been so difficult that most people don&#x27;t even consider it a possibility. With Deno&#x27;s V8 bindings, snapshots, and core crates, anyone can extend the language ecosystem with relative ease. Programs operating in this model on the edge have already shown to be significantly more performant than their traditional server deploy counterparts. End-to-end latency is all but eliminated, until that edge program needs to fetch data from a datacenter. And for that, the &quot;global state&quot; problem is aggressively being worked on by the major edge providers (sorry Cloudflare KV, we&#x27;re having a hard time <i>relating</i> with you). Once this has been solved, the web is prepared for some serious optimization.<p>If you still think &quot;the edge&quot; is a fad in 2022, I&#x27;d recommend spending more time learning about it. It&#x27;s not just JavaScript. Ironically, this architecture is the <i>solution</i> to the web&#x27;s JavaScript problem, and will be the demise of heavy clients and SPAs.
评论 #31274725 未加载
评论 #31274788 未加载
评论 #31276484 未加载
评论 #31276284 未加载
评论 #31275382 未加载
sam0x17about 3 years ago
&gt; The future of scripting languages is browser JavaScript.<p>No. I&#x27;d wager it&#x27;s much more likely _any scripting language but JavaScript_. Statistically speaking it&#x27;s probably Python, though I wouldn&#x27;t love that universe either, being a Rubyist.<p>Browser JavaScript has 30 years of technical debt in the form of the general inability to make non-backwards-compatible breaking changes lest half of web pages stop executing properly. This has been a boon for legacy code, but the language itself has languished for so long and in so many ways. It shouldn&#x27;t be anyone&#x27;s North Star, especially given a choice. Web Assembly gives us real choices, and I think it will eventually result in the end of JS&#x27;s dominance in frontend when we all come to our senses and support improves a bit more.
评论 #31273409 未加载
评论 #31273516 未加载
评论 #31274487 未加载
评论 #31290894 未加载
评论 #31276378 未加载
评论 #31277179 未加载
评论 #31275375 未加载
languagehackerabout 3 years ago
I&#x27;d love to learn more about the concept of JavaScript containers, but all I&#x27;ve got so far is several paragraphs about language supremacy (ick) and a veiled hiring advertisement.
评论 #31277207 未加载
rowls66about 3 years ago
&gt; Scripting languages allow business logic to be written faster and cheaper. The scripting languages (Python, Ruby, Lua, Shell, Perl, Smalltalk, JavaScript) are pretty similar.<p>That is a pretty bold statement to that scripting languages allow business logic to be written faster and cheaper. I think that it depends completely on the size and complexity of your business logic, and on whether you factor in the cost of maintaining that software over time.
评论 #31274107 未加载
评论 #31275801 未加载
评论 #31273903 未加载
ramesh31about 3 years ago
The modern web browser as a universal VM is the single greatest technical achievement in the history of personal computing. I think Ryan is spot on here. There&#x27;s plenty of reason to be critical of the web as a platform, but the reality is that we have finally achieved what people dreamed about in the 80s and 90s; a true write-once-run-everywhere platform. And Javascript (more specifically, V8) is core to that.
franciscopabout 3 years ago
&gt; The future of scripting languages is browser JavaScript. The fundamental mistake of Node.js was diverging from the browser as new APIs were standardized, inventing too much. In 2010, we didn’t have ES modules, but once it was standardized it should have been brought into Node<p>Everyone likes s**g on JS&#x2F;Node.js, but things are a lot more nuanced than this. In Javascript it&#x27;s been normal that first there&#x27;s some user-land fix to some problem, then it&#x27;s implemented within the language core, and then things move over, including (not surprisingly) ESModules. The problem is that the way ESM was implemented was totally incompatible with CommonJS, making the transition a really painful one. On the other hand and TBF, Node.js innovation has slowed significantly and instead focused on stability, which is good to some but not to others (see the founder creating Deno with an implementation closer to the browser).<p>So what has happened is, effectively, what has always happened: Node.js (&quot;userland&quot; for the standard) introduces new concepts, then the ECMAScript body makes it a standard that it&#x27;s similar but not the same, then Node.js has to change everything to adapt to that standard, and it&#x27;s a PITA and leaves everyone scalded and burned out. Node.js in particular had to innovate a lot since it&#x27;s running the same language in a different context, so all of these have followed that path: AJAX, fetch(), crypto, pipes, promises, request handling, Buffer, ESM&#x2F;commonjs, etc. Most of the things we use day-to-day.
评论 #31273546 未加载
PaulHouleabout 3 years ago
It&#x27;s completely wrong that performance doesn&#x27;t matter for the server side, in fact it&#x27;s the complete opposite.<p>Javascript is a fine language for client-side software because the client is paying for it (and the client&#x27;s computer, tablet or phone is running idle most of the time anyway)<p>Firms that run web services pay dearly to run their servers on the cloud, expect to run at a high utilization fraction, and if they ran their infrastructure on a slow language like Ruby they would be paying cloud bills 10x what they&#x27;d get for infrastructure written in Go.<p>The people who make the decision are paying the bills and that means they make a very different decision.
评论 #31272784 未加载
评论 #31273228 未加载
评论 #31273248 未加载
评论 #31274245 未加载
评论 #31263681 未加载
评论 #31277206 未加载
评论 #31272883 未加载
评论 #31275093 未加载
jacknewsabout 3 years ago
&quot;To summarize: scripting languages are useful, but they’re all pretty much the same, &quot;<p>Yeah ... I&#x27;m just going to have to go ahead and um disagree about that.<p>But I agree with the point that a higher level and well defined universal container&#x2F;vm can be valuable. I think it&#x27;ll be wasm-based though, not js.
评论 #31273966 未加载
评论 #31321495 未加载
评论 #31274165 未加载
DeathArrowabout 3 years ago
For me using scripting languages like Javascript and Python for everything they were not intended for like backend, desktop apps, mobile apps is just a crazy train.<p>I do believe scripting languages are terribly useful for scripting the browser, a game, a tool, for writing glue code, small tools and use once code. But not for everything.<p>People should try to learn and use more than one programming language.
fwsgonzoabout 3 years ago
The awful performance you can be stuck with when you can only use emulators and v8 is going to come back to haunt some of you, I believe. It is indeed easy to sell something like this, as it looks easy to work with, the same way that no-code looks easy. But inevitably even native performance is not nearly enough and you need to employ algorithms that use 256- and 512-bit vector operations. At that point, we are talking about running natively on the CPU, and for that you need something that isn&#x27;t just a web app.<p>I remember I recently saw a lecture by an industry professional who took a Python algorithm and improved it 100 000x, in parts. That is, in stages he explained how to utilize the hardware on that particular machine, to improve the algorithm so much that it was hard to believe. Anyone have a link? I looked and I could not find it. It was a recent thing that I believe I saw on this site.<p>When it comes to configuring web services: It is extremely important to configure them in such a way that you can fully or partially cache content, reducing costs. I get it, if you are a startup you need to move fast, but with the way things are going these days, you should have someone on your team who can at the very least deal with the basics of caching.<p>You also cannot pre-initialize v8 as far as I know, so you inevitably end up putting it inside an emulator anyway, and guess what happens to the performance then? I could be wrong.
评论 #31272723 未加载
评论 #31272432 未加载
评论 #31272649 未加载
评论 #31273399 未加载
评论 #31273379 未加载
cocochanelabout 3 years ago
“Any application that can be written in JavaScript, will eventually be written in JavaScript.”
评论 #31273874 未加载
boutellabout 3 years ago
My question is about the implementation. Are you running a Node.js executable in a Docker-style container for each of these? Or are you attempting to achieve the constraints that containers provide at a higher level of abstraction? How do you restrict access to network, disk, excessive RAM, and excessive CPU in a high level JavaScript container — is there an actual JavaScript runtime that supports constraining all of those?<p>I also wonder about applications where WebAssembly isn&#x27;t the most performant thing — image resizing, one of your examples, is also an example of a situation where you get significantly better performance with SIMD instructions. The experiment was tried here:<p><a href="https:&#x2F;&#x2F;www.libvips.org&#x2F;2020&#x2F;09&#x2F;01&#x2F;libvips-for-webassembly.html" rel="nofollow">https:&#x2F;&#x2F;www.libvips.org&#x2F;2020&#x2F;09&#x2F;01&#x2F;libvips-for-webassembly.h...</a>
pcj-githubabout 3 years ago
Ryan Dahl is totally on-point here. It&#x27;s one of those things that will be obvious in 10 years or less. Only SASS providers need bother with linux containers or &quot;real&quot; operating systems, the vast majority of everything else will be glued together over emerging runtimes like Deno&#x2F;CFW, HTTP, and WASM.
btbuildemabout 3 years ago
Reading this makes me think of a five-year-old confidently explaining how something works to their parent.
jFriedensreichabout 3 years ago
the birth and death of javascript is a perfect primer for this article in case anyone did not see it yet (<a href="https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;talks&#x2F;the-birth-and-death-of-javascript" rel="nofollow">https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;talks&#x2F;the-birth-and-death...</a>)
Paddy3118about 3 years ago
Stick to a detailed comparison with... Shell !? So that&#x27;s the context for universality he&#x27;s touting.
brrrrrmabout 3 years ago
This is an incredible API I wish existed in the browser (maybe over WebRTC?)<p><pre><code> addEventListener(&quot;fetch&quot;, (event) =&gt; { event.respondWith(new Response(&quot;Hello world&quot;)); });</code></pre>
评论 #31276255 未加载
评论 #31276481 未加载
ninjuabout 3 years ago
&gt; Technology is difficult to predict, but certainly the World Wide Web <i>will be here</i> in 10 years.<p>I thought the WWW was already here<p>Probably should say &quot;the World Wide Web will STILL be here in 10 years.&quot;
WolfOliverabout 3 years ago
Some more technical details would have been lovely.
tengbretsonabout 3 years ago
Gary Bernhardt is a prophet.
ushakovabout 3 years ago
JavaScript is the next scripting language?<p>what happens to Lua then?
评论 #31273486 未加载
DeathArrowabout 3 years ago
&gt;Scripting languages allow business logic to be written faster and cheaper.<p>You can cat business logic to &#x2F;dev&#x2F;null. That&#x27;s even faster and cheaper.<p>Correctness? Reliability? Speed? Extensibility?