Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JIT-Less V8

v8.dev

Post reply on HN
Print view View original

51–60 of 117 posts

Re: JIT-Less V8

#51

Post by schuay »

bastawhiz wrote: post #49

I'm curious if the runtime flag to enable JITless mode could also be enabled at compile time, removing the JIT compiler from the binary entirely. That could be really useful for projects where memory comes at a premium (and performance is not a major concern), like micropython but for JavaScript. I assume this also doesn't support WASM when the JIT is disabled (or rather, when you can't write to executable memory), b…

> I'm curious if the runtime flag to enable JITless mode could also be enabled at compile time, removing the JIT compiler from the binary entirely. That could be really useful for projects where memory comes at a premium (and performance is not a major concern), like micropython but for JavaScript.

Theoretically yes, but this is not implemented. It should not be too hard to drastically reduce binary size with a build-time flag.

> I assume this also doesn't support WASM when the JIT is disabled (or rather, when you can't write to executable memory), but if it did it could be a neat way to write decently performant software for tiny systems with just some JavaScript "glue".

Correct, wasm is currently unsupported. Interpreted wasm is possible in the future, but would likely be very slow.

Re: JIT-Less V8

#52

Post by mises »

I keep wondering what the deal is with JS on the backend? Why does everyone love it so much? Let's not forget the 10-day design, dynamic typing (and weakly typed, compared with python), slowness, null vs. undefined, etc. JS is a scripting language; they're supposed to be for controlling the behavior of applications (i.e. browsers), not writing applications in and of themselves. Not to mention the dependency hell, NPM insecurity, etc. I see the purpose for limited use in websites, but definitely not the PWA or backend stuff.

Can someone who uses it happily on the backend talk about why they like it and why it's good?

Re: JIT-Less V8

#53

Post by bpye »

xuejie wrote: post #34
cromwellian wrote: post #17

For very security sensitive embedded applications, this could be a huge boon, since it reduces attack area surface, both from the point of view of executable pages, to the simplicity of the interpreter vs full JIT. Granted, there are many JS interpreters already available, like Ducktape, that fulfill the same benefits, but the immediate upside of this is compatibility with the full Node/ES6+ ecosystem and Chrome Dev…

Definitely agree duktape is a decent attempt at low memory situation, but one additional point is that duktape is very slow compared to modern JavaScript engines. Hence I wonder if we can split ignition off v8 to create a standalone fast JavaScript interpreter at the cost of (possibly) more memory consumptions than duktape, that could prove to be useful in many scenarios.

I quite like Duktape because it is really simple to embed as well. The V8 API is comparitively pretty complicated.

Re: JIT-Less V8

#54

Post by atoko »

mises wrote: post #52

I keep wondering what the deal is with JS on the backend? Why does everyone love it so much? Let's not forget the 10-day design, dynamic typing (and weakly typed, compared with python), slowness, null vs. undefined, etc. JS is a scripting language; they're supposed to be for controlling the behavior of applications (i.e. browsers), not writing applications in and of themselves. Not to mention the dependency hell, NPM…

How is it slow? [Citation needed]

The async model is easy to use so you get good performance before even optimize it. It comes out of the box with good json serialization/parsing, so that’s one less dependency. Not really sure where you’re coming from.

Re: JIT-Less V8

#55

Post by curtis »

mises wrote: post #52

I keep wondering what the deal is with JS on the backend? Why does everyone love it so much? Let's not forget the 10-day design, dynamic typing (and weakly typed, compared with python), slowness, null vs. undefined, etc. JS is a scripting language; they're supposed to be for controlling the behavior of applications (i.e. browsers), not writing applications in and of themselves. Not to mention the dependency hell, NPM…

People were using Ruby and Python (and before that Perl and PHP) on the backend in many cases. I think it's likely that those are the kinds of projects which are using JS on the backend now, while the Java and C# people are continuing to do their backends in Java and C#.

One of JavaScript's big advantages over Ruby and Python was performance, both because the standard runtime is faster (JITing JavaScript turned out to be a lot easier than JITing Ruby and Python) and because its fundamentally asynchronous nature was a better match for webservers.

And although NPM sucks in a number of ways, I've always found it easier to use than Python's dependency management.

Re: JIT-Less V8

#56

Post by efdee »

mises wrote: post #52

I keep wondering what the deal is with JS on the backend? Why does everyone love it so much? Let's not forget the 10-day design, dynamic typing (and weakly typed, compared with python), slowness, null vs. undefined, etc. JS is a scripting language; they're supposed to be for controlling the behavior of applications (i.e. browsers), not writing applications in and of themselves. Not to mention the dependency hell, NPM…

It sounds like you read a lot of articles about why JS is bad, but don't have a lot of experience with it.

* 10-day design? Nobody is using Javascript 1.0 anymore.

* Typing is available to various extents thanks to Flow and/or Typescript.

* Slowness... I don't know what you're referring to. Javascript isn't slow.

* null vs undefined. What about them? They are two different things with different meanings.

* Dependency hell. I assume you refer to the many small modules on NPM with dependencies on other modules. Not sure what the problem here is per se. Avoid them if you don't like dependencies.

* NPM insecurity - what?

I like JS on the backend because it's a nice, flexible language to work with, with a healthy and cheap (cost-wise) ecosystem. I get a lot of stuff done very quickly, and I can run my stuff pretty much everywhere.

Re: JIT-Less V8

#57

Post by efdee »

curtis wrote: post #55
mises wrote: post #52

I keep wondering what the deal is with JS on the backend? Why does everyone love it so much? Let's not forget the 10-day design, dynamic typing (and weakly typed, compared with python), slowness, null vs. undefined, etc. JS is a scripting language; they're supposed to be for controlling the behavior of applications (i.e. browsers), not writing applications in and of themselves. Not to mention the dependency hell, NPM…

People were using Ruby and Python (and before that Perl and PHP) on the backend in many cases. I think it's likely that those are the kinds of projects which are using JS on the backend now, while the Java and C# people are continuing to do their backends in Java and C#. One of JavaScript's big advantages over Ruby and Python was performance, both because the standard runtime is faster (JITing JavaScript turned out t…

Anecdotal, but as developer who has done mainly C# for the last decade-and-a-half, I've switched to Node.js for -a lot- of my non-enterprisey work.

Re: JIT-Less V8

#58

Post by sharpercoder »

cromwellian wrote: post #17

For very security sensitive embedded applications, this could be a huge boon, since it reduces attack area surface, both from the point of view of executable pages, to the simplicity of the interpreter vs full JIT. Granted, there are many JS interpreters already available, like Ducktape, that fulfill the same benefits, but the immediate upside of this is compatibility with the full Node/ES6+ ecosystem and Chrome Dev…

But is the increasing complexity (an interpreter added to the codebase) not introducing also another - new - attack vector?

Re: JIT-Less V8

#59

Post by spacenick88 »

sharpercoder wrote: post #58
cromwellian wrote: post #17

For very security sensitive embedded applications, this could be a huge boon, since it reduces attack area surface, both from the point of view of executable pages, to the simplicity of the interpreter vs full JIT. Granted, there are many JS interpreters already available, like Ducktape, that fulfill the same benefits, but the immediate upside of this is compatibility with the full Node/ES6+ ecosystem and Chrome Dev…

But is the increasing complexity (an interpreter added to the codebase) not introducing also another - new - attack vector?

The interpreter has always been part of the codebase since it is used during startup and while the code is still being JITed

Re: JIT-Less V8

#60

Post by whatshisface »

efdee wrote: post #56
mises wrote: post #52

I keep wondering what the deal is with JS on the backend? Why does everyone love it so much? Let's not forget the 10-day design, dynamic typing (and weakly typed, compared with python), slowness, null vs. undefined, etc. JS is a scripting language; they're supposed to be for controlling the behavior of applications (i.e. browsers), not writing applications in and of themselves. Not to mention the dependency hell, NPM…

It sounds like you read a lot of articles about why JS is bad, but don't have a lot of experience with it. * 10-day design? Nobody is using Javascript 1.0 anymore. * Typing is available to various extents thanks to Flow and/or Typescript. * Slowness... I don't know what you're referring to. Javascript isn't slow. * null vs undefined. What about them? They are two different things with different meanings. * Dependency…

>NPM insecurity

NPM packages can contain malicious code. There's no NPM review process, and you can't point to specific versions to lock in your own reviews (package administrators can change whatever files they'd like). There's no such thing as a verified-safe dependencies list because the file you reviewed last month might not be downloaded today.

Post reply on HN