However (and this is just me talking), I don't see the point in a javascript-based compiler. Surely any file format/DSL/programming language you write will be parsed server-side?
JavaScript is a full programming language. Why wouldn't it be a fine choice to write a compiler in? People have a funny idea that compilers are more complex software or are somehow something low-level? In reality they're conceptually simple - as long as your language lets you write a function from one array of bytes to another array of bytes, then you can write a compiler in it. And for practicalities beyond that you just need basic records or objects or some other kind of structure, and you can have a pleasant experience writing a compiler.
> Surely any file format/DSL/programming language you write will be parsed server-side?
JavaScript can be used user-side, or anywhere else. It's just a regular programming language.
Typescript, sass, jsx... There are a lot of languages running on top of js. Or you might want to do colorizing, autoformating on input in the browser?
Along with all that, there's as mentioned nodejs, deno for running server side.
But at any rate - lots of front-end problems involve various kinds of parsing/validation and transformation (eg: processing.js).
Javascript doesn't seem suited to compiler construction because it lacks lots of features that make compiler construction pleasant (e.g. strong rich types, algebraic data types, etc.)
It might be "fine" but it's not "good".
“If I send someone an executable, they will never download it. If I send them a URL, they have no excuse.”
If someone interested in a compiler doesn't download it, it's not a excuse, it's a filter. Or a warning sign.
> If someone interested in a compiler doesn't download it, it's not a excuse, it's a filter. Or a warning sign.
You're so invested in gatekeeping that you're confusing the point of research with technofetishism.
Here's what Joe Armstrong had to say in "The Mess We're In":
"I downloaded this program, and I followed the instructions, and it said I didn't have grunt installed! [...Then] I installed grunt, and it said grunt was installed, and then I ran the script that was gonna make my slides... and it said 'Unable to find local grunt'."
Looks like someone needs to go dig up Joe and let him know that the real problem is that there was a mistake in letting him get past the point where he was supposed to be filtered out.
If it's a decently large project, sure. But if it's a small project with only a couple contributors who I've never heard of? There's the potential for that to be hiding malicious code. Plus the potential complexity of getting a project that's only ever been built on (say) 2 computers to successfully compile and run on my system. Plus figuring out whatever build system and weird flags they happen to use. And potentially wrangling a bunch of dependencies.
All that just to take a quick look at a language that might not actually be of interest to me in the end. The browser offers huge benefits here - follow a link and play around in a text box. It just works. (This is also why I use Godbolt - I don't want to bother with a Windows VM or wrangle ten different versions of Clang and GCC myself.)
The choice of language often matters a lot less than how familiar you are with it (and its ecosystem(s)). I think it's totally reasonable to want to use JS for a compiler in, e.g., a Node project if for no other reason than to not have to learn too many extra things at once to be productive with the new tool.
I also don't think it's fair to assume everything will be parsed, tokenized, etc server-side. Even assuming that data originates server-side (since if it didn't you very well might have a compelling case for handling it client-side if for no other reason than latency), it's moderately popular nowadays to serve a basically static site describing a bunch of dynamic things for the frontend to do. Doing so can make it easier/cheaper to hit any given SLA at the cost of making your site unusable for underpowered clients and pushing those costs to your users, and that tradeoff isn't suitable everywhere, but it does exist.
It's interesting that you seem to implicitly assume the only reason somebody would choose JS is that they're writing frontend code. It's personally not my first choice for most things, but it's not too hard to imagine that some aspect of JS (e.g., npm) might make it a top contender for a particular project despite its other flaws and tradeoffs.
But I’m standing my ground because I’m not even writing a proper “compiler” - in my case, the output is JSON. So it just kinda feels like it makes sense to stick with JS.
Tons of brilliant people and huge companies have made software in X and found out it would have been better in Y. There's always tomorrow, as long as you learned today.
(and you can always decide that you need more speed - if you have a grammar defined, it's almost trivial to feed it to some other parser-generator)
Well, Javascript has been used for over a decade heavily on the server side, with Node, WASM and other projects.
And as far as raw speed goes, something like v8 smokes all scripting languages bar maybe LuaJit.
So, there's that...
There is a world of difference in accessibility between a tool that requires installation and a tool that you can use by following a hyperlink.
My CC is Javascript based (well it was initially, then TypeScript, now a lot of it is written in itself).
99% of the time I use the actual languages I make in it server side (nodejs), but I am able to develop the languages in my browser using https://jtree.treenotation.org/designer/. It's super easy and fun (at least for me, UX sucks for most people at the moment). There's something somewhat magical about being able to tweak a language from my iPhone and then send the new lang to someone via text. (Warning: Designer is still hard to use and a big refresh is overdue).
My recent fun public focus now is to power Scroll, (https://scroll.publicdomaincompany.com/). "Scrolldown" now powers my blog (an example post: https://github.com/breck7/breckyunits.com/blob/main/insist-o...). I think from what I'm seeing so far Scrolldown may be one of the first Tree Lang breakouts. Simple but powerful from extensibility.
TreeBase is used extensively at a few moderately successful websites. I think Tree Notation (or 2D langs generally) will be used OOMs more in this domain. It integrates so incredibly seamlessly with Git.
At Our World in Data Tree Notation is used for the researchers to build interactive data visualizations (https://www.youtube.com/watch?v=vn2aJA5ANUc&t=145s). That one uses it's own implementation called "GridLang" because I didn't want to depend on jtree, which is a bit too R&D for a site with that kind of traffic. The 2D lang/Tree Notation ideas are so simple that it's easy to roll your own code and you don't have to use "jtree". I view the "jtree" project in a way as just an experiment to confirm that yes, you can do anything/everything without any visible syntax characters. Space is all you need.
On the contracting side I'm helping a crypto group with a shockingly ambitious 2-D crypto.