A small but complete JavaScript engine • Hacker News Board

Re: A small but complete JavaScript engine

#71

Post by moonchild » Sun, Oct 25, 2020, 5:26 AM UTC

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.

> in terms of bang for buck it's unbeatable

Luajit packs a similar punch, and actually has performance comparable with v8.

Plenty of things with performance and size similar to quickjs, though; regular lua, micropython, chibi scheme, s7 scheme...lots of great options.

Re: A small but complete JavaScript engine

#72

Post by saagarjha » Sun, Oct 25, 2020, 5:26 AM UTC

PrinceKropotkin wrote: post #43

saagarjha wrote: post #23

Earlier quoted context omitted.

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.

Python and Perl don't run natively in the three major browser engines.

Re: A small but complete JavaScript engine

#73

Post by chii » Sun, Oct 25, 2020, 5:27 AM UTC

Macuyiko wrote: post #6

iamvnraju wrote: post #2

Frabrice Bellard truly works in God mode. Ffmpeg, Qemu, Tiny C Compiler ... many others .. and now this!

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.

Many people don't have the misconception that they can compete athletically at the level of olympics. And yet, somehow, a lot of people mistakenly believe they could perform intellectually at that same high level!

Re: A small but complete JavaScript engine

#74

Post by sieabahlpark » Sun, Oct 25, 2020, 5:28 AM UTC

chii wrote: post #70

mhh__ wrote: post #61

Earlier quoted context omitted.

He's in his 50s keep in mind. Most people of his productivity get shoved into management long before his age. He's very good but it's not like he did ffmpeg last week and QuickJS this week. Some people are just born to be able to work all day all week, if you are one of those people please don't throw it away (I am not one of them). I think I have the knowledge to do most of his projects e.g. I have the mathematics,…

> get shoved into management long before his age. Problem is that management pays so much better than a contributor of code. Society has collectively decided that management is worth more economically, than individual contributors.

Because good managers are hard to come by so you have to give some sort of incentive to attract and retain the good ones.

Good managers increase the output of their team, bad ones try to make themselves look the best.

Re: A small but complete JavaScript engine

#75

Post by chii » Sun, Oct 25, 2020, 5:29 AM UTC

userbinator wrote: post #52

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

Rather than trying to figure out which of dozens of files has what you're looking for, you can just search one or two large ones. On the other hand, I hate finding a project that looks useful, but then the code is scattered across many files which are barely one screen long, or worse, also spread throughout different deeply nested directories. Regardless of whether the organisation makes sense, navigating directory t…

> you can just search one or two large ones.

if the LOC is similar in size, i don't see why having them in different files vs same file makes any difference at all.

Also, your IDE should be able to navigate you to definitions and usages etc. If it doesn't, it's not a good IDE. So the problem of understanding code reduces understanding the abstract structure, not how that structure is represented on file.

Re: A small but complete JavaScript engine

#76

Post by coder4life » Sun, Oct 25, 2020, 5:32 AM UTC

bigyikes wrote: post #58

userbinator wrote: post #52

Earlier quoted context omitted.

Rather than trying to figure out which of dozens of files has what you're looking for, you can just search one or two large ones. On the other hand, I hate finding a project that looks useful, but then the code is scattered across many files which are barely one screen long, or worse, also spread throughout different deeply nested directories. Regardless of whether the organisation makes sense, navigating directory t…

> Rather than trying to figure out which of dozens of files has what you're looking for, you can just search one or two large ones. Why is this a good thing? The same amount of code and same number of results need to be scanned either way. With many files, you at least have the file name to give you some small amount of context without needing to read the code.

Working with 1 or 2 large files is vasty more productive/faster (for me) than working with 50

Seeing as Bellard is very prolific and has done more than you me and three others in a lifetime, there must be some merit to his approach.

Re: A small but complete JavaScript engine

#77

Post by mschuster91 » Sun, Oct 25, 2020, 5:38 AM UTC

Just... wtf? How much can one person reasonably know or have the time to actually do extremely deep dives?!

Fabrice Bellard truly is one of a kind in the programmer world.

Re: A small but complete JavaScript engine

#78

Post by tonyedgecombe » Sun, Oct 25, 2020, 5:38 AM UTC

jiggawatts wrote: post #48

> An online demonstration of the QuickJS engine with its mathematical extensions is available at numcalc.com. It was compiled from C to WASM/asm.js with Emscripten. Turtles all the way down!

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: A small but complete JavaScript engine

#79

Post by andykx » Sun, Oct 25, 2020, 5:54 AM UTC

bigyikes wrote: post #58

userbinator wrote: post #52

Earlier quoted context omitted.

Rather than trying to figure out which of dozens of files has what you're looking for, you can just search one or two large ones. On the other hand, I hate finding a project that looks useful, but then the code is scattered across many files which are barely one screen long, or worse, also spread throughout different deeply nested directories. Regardless of whether the organisation makes sense, navigating directory t…

> Rather than trying to figure out which of dozens of files has what you're looking for, you can just search one or two large ones. Why is this a good thing? The same amount of code and same number of results need to be scanned either way. With many files, you at least have the file name to give you some small amount of context without needing to read the code.

Yeah. This seems like something that the industry decided was a bad practice many years ago.

My best guess is that this is more of a fun project than anything and spending too much time on such concerns would detract from the fun. I do the same with my side projects.

Re: A small but complete JavaScript engine

#80

Post by z3phyr » Sun, Oct 25, 2020, 6:00 AM UTC

chii wrote: post #75

userbinator wrote: post #52

Earlier quoted context omitted.

Rather than trying to figure out which of dozens of files has what you're looking for, you can just search one or two large ones. On the other hand, I hate finding a project that looks useful, but then the code is scattered across many files which are barely one screen long, or worse, also spread throughout different deeply nested directories. Regardless of whether the organisation makes sense, navigating directory t…

> you can just search one or two large ones. if the LOC is similar in size, i don't see why having them in different files vs same file makes any difference at all. Also, your IDE should be able to navigate you to definitions and usages etc. If it doesn't, it's not a good IDE. So the problem of understanding code reduces understanding the abstract structure, not how that structure is represented on file.

Your IDE should be able to split a single file codebase into different readable modules. If it cannot do that, its not a good IDE.

And slippery slope...