Focus on speed, not disk size. We're still in stonehenge, surrounded by extremely slow and un-optimized hardware and software.
I thought ts matters when it runs on RAM and embedded environments
A small but complete JavaScript engine
141–150 of 151 posts
Re: A small but complete JavaScript engine
#142Earlier quoted context omitted.
Http is not part of JS engine, because it has nothing to do with JS. I kinda like large files (vs splitting the code), because they are easier to navigate in vim. I have no idea about why the choice was made for QuickJS, aside from ease of inclusion into other projects, mentioned in the docs.
The original comment was about separating components out for reuse in other projects. He wasn’t wondering why http wasn’t part of the js engine, that was just the example he chose
I don't see how any part of quickjs engine itself can be used in other projects. It all looks highly tailored to quickjs, aside from things that are already separated.
Re: A small but complete JavaScript engine
#143Earlier quoted context omitted.
The original comment was about separating components out for reuse in other projects. He wasn’t wondering why http wasn’t part of the js engine, that was just the example he chose
I don't see how any part of quickjs engine itself can be used in other projects. It all looks highly tailored to quickjs, aside from things that are already separated.
Lots of parts can be used separately! The parser for code analysis or refactoring tools, the JIT to accelerate programs (anything state machine based for example is pretty much like a VM), the garbage collector to embed in other programs (especially interpreters). I mean… these are just the most obvious, there are many more use cases.
Re: A small but complete JavaScript engine
#144Currently 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!
Oh man. I had to deal with programs organized this way when you were my manager and I had tons of maintenance concerns :D
Fun to run into you, Geo!
Re: A small but complete JavaScript engine
#145Earlier quoted context omitted.
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!
Oh man. I had to deal with programs organized this way when you were my manager and I had tons of maintenance concerns :D Fun to run into you, Geo!
Mate. You didn’t have to do anything. You got to do whatever you wanted and you wanted “smarter coworkers” who didn’t use PHP.
But I stand by what I said now and nearly a decade ago, and now try to be blunt: Fabrice Bellard didn’t organise quickjs this way because he isn’t as smart as you. He did it because it makes things easier for him to write quickjs and qemu and tcc and ffmpeg and all sorts of other stuff used by all sorts of other people. And if you ever figure out how to learn from watching people who can do things you cannot, I think you could be an amazing programmer.
All the best.
Re: A small but complete JavaScript engine
#146Earlier quoted context omitted.
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.
Sure, but that doesn't speak to the language.
Re: A small but complete JavaScript engine
#147Earlier quoted context omitted.
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.
Being event-driven and simple and hot reloadable and forgiving does make it well suited for the task at hand. You should really think about why javascript is the de facto standard for web scripting. Other alternatives have appeared but even the likes of Google, which control the entire web stack and can pretty much dictate what the world uses, decided against it.
It's the de-facto standard for web scripting because browsers forgot to build anything other than the bare minimum to ship new features incrementally. There's nothing about the languge itself that is preternaturally suited to the task at hand; in fact I'd argue it's the largest single impediment to scripting the browser outside of political sources (e.g. browser vendors).
Re: A small but complete JavaScript engine
#148Earlier quoted context omitted.
Oh man. I had to deal with programs organized this way when you were my manager and I had tons of maintenance concerns :D Fun to run into you, Geo!
Mate. You didn’t have to do anything. You got to do whatever you wanted and you wanted “smarter coworkers” who didn’t use PHP. But I stand by what I said now and nearly a decade ago, and now try to be blunt: Fabrice Bellard didn’t organise quickjs this way because he isn’t as smart as you. He did it because it makes things easier for him to write quickjs and qemu and tcc and ffmpeg and all sorts of other stuff used b…
Oh, I would never compare myself to him and can only learn (a ton) from someone like him who can indeed do many things I cannot. Just something I found curious, I'm sure he has a good reason for it.
Re: A small but complete JavaScript engine
#149Earlier quoted context omitted.
Mate. You didn’t have to do anything. You got to do whatever you wanted and you wanted “smarter coworkers” who didn’t use PHP. But I stand by what I said now and nearly a decade ago, and now try to be blunt: Fabrice Bellard didn’t organise quickjs this way because he isn’t as smart as you. He did it because it makes things easier for him to write quickjs and qemu and tcc and ffmpeg and all sorts of other stuff used b…
Oh, I would never compare myself to him and can only learn (a ton) from someone like him who can indeed do many things I cannot. Just something I found curious, I'm sure he has a good reason for it.
> who can indeed do many things I cannot
No. This is exactly my point.
You can do it too, you just might need to organize your code this way to do it.
Re: A small but complete JavaScript engine
#150Earlier quoted context omitted.
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...
Is there a term for this type of refactor? Often I might end up with 2 exported classes in one file, both being used across other files. I then want to separate them into 2 files and update the imports. I feel like my IDE should be able to do this, I just can’t seem to google the right term.
Ah, in VS Code it is just:
1. Click class name (or any other top level identifier).
2. Click light bulb.
3. Click move to a new fie.