When I first read the source for his original QuickJS implementation I was amazed to discover he created the entirety of JavaScript in a single xxx thousand line C file (more or less).
That was a sort of defining moment in my personal coding; a lot of my websites and apps are now single file source wherever possible/practical.
Is there any as large as possible single source (or normal with amalgamation version) more or less meaningful project that could be compiled directly with rustc -o executable src.rs? Just to compare build time / memory consumption.
Yes, that's why I've asked about possible rust support of creating such version of normal project. The main issue, I'm unaware of comparably large rust projects without 3rdparty dependencies.
I believe ripgrep has only or mostly dependencies that the main author also controls. It's structured so that ripgrep depends on regex crates by the same author, for example.
I honestly think the single file thing is best reserved for C, given how bad the language support for modularity is.
I've had the inverse experience dealing with a many thousand line "core.php" file way back in the day helping debug an expressionengine site (back in the php 5.2ish days) and it was awful.
Unless you have an editor which can create short links in a hierarchical tree from semantic comments to let you organize your thoughts, digging through thousands of lines of code all in the same scope can be exceptionally painful.
C has no problems splitting programs in N files, to be honest.
The reason FB (and myself, for what it is worth) often write single file large programs (Redis was split after N years of being a single file) is because with enough programming experience you know one very simple thing: complexity is not about how many files you have, but about the internal structure and conceptually separated modules boundaries.
At some point you mainly split for compilation time and to better orient yourself into the file, instead of having to seek a very large mega-file. Pointing the finger to some program that is well written because it's a single file, strlongly correlates to being not a very expert programmer.
The file granularity you chose was at the perfect level for somebody to approach the source code and understand how Redis worked. It was my favorite codebases to peruse and hack. It’s been a decade and my memory palace there is still strong.
It reminded me how important organization is to a project and certainly influenced me, especially applied in areas like Golang package design. Deeply appreciate it all, thank you.
I split to enforce encapsulation by defining interfaces in headers based on incomplete structure types. So it helps me with he conceptually separated module boundaries. Super fast compilation is another benefit.
Reminds of one time when I was pair programming and the other chair said “let’s chop this up, it’s too long” and when I queried the motivation (because I didn’t think it was too long), it was something like, “I’m very visual, seeing the file tree helps me reason about internals”. Fair enough, I thought at the time, whatever makes us more productive together.
On reflection, however, I’m unsure how that goes when working on higher-order abstractions or cross-cutting concerns that haven’t been refactored, and it’s too late to ask.
It may not be immediately obvious how to approach modularity since it isn't directly accomplished by explicit language features. But, once you know what you're doing, it's possible to write very large programs with good encapsulation, that span many files, and which nevertheless compile quite rapidly (more or less instantaneously for an incremental build).
I'm not saying other languages don't have better modularity, but to say that C's is bad misses the mark.
Unironically JavaScript is quite good for single file projects (albeit a package.json usually needed)
You can do a huge website entirely in a single file with NodeJS; you can stick re-usable templates in vars and absue multi-line strings (template literals) for all your various content and markup. If you get crafty you can embed clientside code in your 'server.js' too or take it to the next level and use C++ multi-line string literals to wrap all your JS ie- client.js, server.js and package.json in a single .cpp file
Bravo, been looking forward to this but AnimeJs v3 has just been so solid for so long honestly you did amazing on v3 that v4 is just icing on top; excited to try this out on my next project.
async/await + animation (ie- with AnimeJS) is highly underrated.
And mad props for skipping the now dying trend of refactoring entire codebase to TypeScript :)
Refactoring your entire codebase just to use that one ES module that is incompatible with CJS is a big pill to swallow if your codebase is ... big (or you have many).
True, but if you just do it, even if it's a large undertaking, the benefits of ESM-only code are bigger than being able to use more packages. And someday you will have to move to ESM anyway.
On the flip side we have other amazing devs who are also active with cutting edge libraries and simply do the small amount of extra work to make their modules available in both ESM and CommonJS to this day:
Not sure about realtime voiceover and not in emergency services myself but having an LLM fed the call audio to generate supplmentary summary of what was discussed could certainly be beneficial in situations where the operator needed clarity or there was a mistaken address or important detail that needed double-checking after the call.
It has its quirks and even some annoying bugs but where it excells its IMO way better than what any competing/proprietary design tool can do (vector and bitmap exporting, vector+bitmap combined layering, shape/colors/text layout, PDF editing/creating, vector pen tool, etc). I use it to create UI for games & apps and more generally to build sprawling UX scenarios and concept flowcharts.
In more recent builds its performance has become quite good which was a problem it had before. Granted, lots of room for improvement still particularly wish it had more natural flowcharting capability.
Inkscape is amazing, and it's had incredible growth. I remember using it 5+ years ago and it was incredibly buggy and the UX was terrible. I now use it extensively and it rocks.
Concurring that Inkscape today is awesome, while it definitely was not a decade ago (how the time flies... and decade ago it was already... ten years old or so!).
Disclaimer: I'm an engineer not a UX/UI designer, and I use Inkscape mostly for graphic designs and the odd super-simple CAD stuff where I don't think starting qcad is worth it. Still, I'm immensely happy that I can just get stuff done in Inkscape and that everything inside makes sense and is generally discoverable "solely by logic".
Another vote for Inkscape here - amazing tool. I probably use less than 1% of it's functionality, but it is far and away the best PDF editor I've come across (I work with a lot of design drawings that started life as DWG/CAD files, are exported to PDF and sent around for proofing/review and need to have changes marked up on them).
Indeed, that is primarily where it excels. Your layered source files are SVG and you can export to SVG (and you can import in SVG obviously). The bitmap selection/exporting is also excellent as such you can have these massive vector canvases (with any number of bitmaps and vector shapes/graphics mixed in) and quickly export any slice or selection you make without having to resize the canvas or copy/paste somewhere - and it will remember the export path when you click on the object or layer again later (aside from a bug with symlinks on Linux); ideal for iterative work/exporting revisions to clients or colleagues.
Yeah it's great for SVGs. I still use illustrator because the type tools are a lot easier to work with for constant use,I already have a CC subscription grandfathered in at a cheap rate, and some things in it I'm just plain-old used to... But I could deal with Inkscape if I decided to dump Adobe. Gimp not so much. I'd definitely be buying affinity's photo editor or something for raster work.
Amazon's repo here is open source at least so perhaps this could be remedied with an edit to their README and a PR - go for it !
Agree with you there should be credit where credit is due - I have been using QuickJS for some time and its awesome. For the cost of about 1MB you can get entire modern JS in your C/C++ binary.
It's good for quick things and prototyping cause you can always swap out those calls with native later. It's API is generally easier to remember/less typing that most native equivalents. You can also use its API serverside via Cheerio to do parsing & manipulation of html without a dom.
edit: also its way more lightweight than React/Vue/Svelte i don't necessarily disagree you shouldn't reach for jQuery if you have a dynamic page (something like uhtml+preact signals would be good if you have fair bit of rendering logic going on) but I would say you should totally try seeing how far you can get with jQuery instead of Svelte/React/Vue on simple pages.
Is it really way more lightweight than Svelte? Svelte has more tooling (of course) but it ships no runtime and only sends the user the JS they actually need to interact with your page.
That was a sort of defining moment in my personal coding; a lot of my websites and apps are now single file source wherever possible/practical.