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

A small but complete JavaScript engine

bellard.org

Post reply on HN
Print view View original

41–50 of 151 posts

Re: A small but complete JavaScript engine

#41

Post by maple3142 »

thamer wrote: post #34

Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones. I can't say I understand the reason for such massive files. Surely it would be easier to maintain if it was split into a few well-defined modules? In addition to the maintenance concerns, a JavaScript engine has quite a few parts that could be used as individual components.…

I think the main benefit of single file is that it will be easier to used in other projects, but this is just my assumption.

Re: A small but complete JavaScript engine

#42

Post by taf2 »

leetrout wrote: post #8
Macuyiko wrote: post #6

Earlier quoted context omitted.

Agreed. 10 years ago, I could still pretend I'd be able to come close to his productivity if I "just set my mind to it." Today (being older, slower, and having a family), I can only be humble.

I’m really starting to feel the age and competing priorities with family. Makes me really scared about ageism.

Maybe but as the kids get older you the time back and your more efficient with it as a result of those early years... I think at least I’m faster and smarter now then ten years ago... maybe I’m losing my eye sight and my hearing or maybe it’s true :)

Re: A small but complete JavaScript engine

#43

Post by PrinceKropotkin »

saagarjha wrote: post #23
kdtop wrote: post #19

Earlier quoted context omitted.

Serious question, why is this a joke? Couldn't javascript be just another language to replace bash?

People typically write small, short scripts in bash, not web applications. The same goes for JavaScript, but in reverse. They were designed for different things.

There's nothing about javascript that makes it particularly suited for "web applications". This doesn't seem any more ridiculous than, say, using python or perl.

Re: A small but complete JavaScript engine

#44

Post by hakcermani »

taf2 wrote: post #42
leetrout wrote: post #8

Earlier quoted context omitted.

I’m really starting to feel the age and competing priorities with family. Makes me really scared about ageism.

Maybe but as the kids get older you the time back and your more efficient with it as a result of those early years... I think at least I’m faster and smarter now then ten years ago... maybe I’m losing my eye sight and my hearing or maybe it’s true :)

Touche! i need some more focus too!

Re: A small but complete JavaScript engine

#46

Post by geocar »

thamer wrote: post #34

Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones. I can't say I understand the reason for such massive files. Surely it would be easier to maintain if it was split into a few well-defined modules? In addition to the maintenance concerns, a JavaScript engine has quite a few parts that could be used as individual components.…

If you learn how deal with programs organised this way, you won’t have “maintenance concerns” and you’ll be a better programmer. Win-win!

Re: A small but complete JavaScript engine

#47

Post by fiddlerwoaroof »

maple3142 wrote: post #41
thamer wrote: post #34

Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones. I can't say I understand the reason for such massive files. Surely it would be easier to maintain if it was split into a few well-defined modules? In addition to the maintenance concerns, a JavaScript engine has quite a few parts that could be used as individual components.…

I think the main benefit of single file is that it will be easier to used in other projects, but this is just my assumption.

I’ve always found that lots of definitions in one file is easier than splitting code over 100 files. It reduces reliance on complex, and often slow, tooling for analyzing directory structures and, most development tools support opening the same file twice at different offsets.

Re: A small but complete JavaScript engine

#49

Post by tomjakubowski »

untog wrote: post #29
pansa2 wrote: post #11

> Can compile Javascript sources to executables with no external dependency. Is QuickJS a viable way to write command-line apps in JavaScript? In particular, does it have enough of a standard library to work with, or would it be a struggle because (I assume) it can’t use packages from NPM? I know there’s the alternative of bundling Node.js and V8 into an executable, but the resulting binaries are large - it feels lik…

It has a very small standard library: https://bellard.org/quickjs/quickjs.html#std-module It would be enough for a good number of CLI tools, I'd think. But one big issue is going to be that every library on NPM is hardcoded to use Node's modules (e.g. fs) so you're not going to be able to use any external modules at all.

This is untrue. There are plenty of modules published to npm which don't use node APIs, often specifically so they can be used in many runtimes.

Here's one example: https://www.npmjs.com/package/squat

Re: A small but complete JavaScript engine

#50

Post by fiddlerwoaroof »

untog wrote: post #30

QuickJS is a really, really interesting engine because it's only ~200KB. Fits a lot of cases where you want to add scripting ability but without bulking out size unnecessarily. Unfortunately because it lacks stuff like JIT it'll never rival the likes of V8 in performance. But in terms of bang for buck it's unbeatable.

I sort of wonder if making browser JS engines slower would improve the web: fast JS engines enable complex JS apps but it’s far from clear that these apps are better for UX, especially compared to improving the built-in functionality of HTML
Post reply on HN