Hacker News new | past | comments | ask | show | jobs | submit login

One thing to note... he doesn't bother himself with pretty websites, community building of any kind, splash pages... It's just plain html. Not even github as far as I could tell. He just works on the tech and puts it out there with benchmarks as proof of his claims.



His humility (and general lack of "marketing wank" on his site) is certainly another aspect I admire. There's far too much "look at my absolutely amazing $trivial_app with best-in-class X and high-quality Y and gorgeous Z and ..." out there, that just seeing the equivalent of "This is a JS engine I wrote." and a simple enumeration of features without all that embellishment feels very refreshing.


Yes that's true in general, but ... I hate to be the party pooper here, but ....

What makes this JS implementation deserve the name "Quick"?

I noticed it doesn't appear to do JIT compilation or any of the fancy optimisations V8 does. So whilst it may start up quickly, and may interpret quickly, it won't actually execute JS quickly relative to V8, unless I missed something huge in the linked web page.

I got the sense there are several performance claims here that sound impressive but won't actually matter for nearly every JavaScript user.


It seems to be relatively very fast in the space of small javascript interpreters meant for embedding. That's a different niche with different constraints.


But "embedding" is a very vague term. You can embed V8 too. It's just a C++ library, it can be linked into other programs. It can run on relatively small devices. If you're going to say, but what about even smaller devices than that then sure, maybe this implementation can squeeze into a certain class of rare device that can't run V8. But then why would such a constrained device be running JavaScript at all. That would seem to be the issue there!


You certainly can embed V8, but it's a more involved affair. It's not the use case that's prioritized.

It's not at all my field of expertise, but my guess is that problems with V8 are that it's an order of magnitude larger, that it's written in C++ rather than C89, that it's more likely to make large changes to the way it works, and that it uses more memory.

All of those are good decisions to make for a component of Chrome that helps run webpages. But sometimes you'll only want to make it possible for users of your less than massive technical application to script its behavior using a language they might already be familiar with, and then those properties are undesirable.

"Quick" calls to mind something that's not just fast, but nimble.


QuickJS also compiles to machine code.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: