Top 23 JavaScript Compiler Projects
-
NextJS is one of the most popular framework for building hybrid static & server rendered web applications which also uses React.
-
webpack
A bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through "loaders", modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.
I don't know how you do the build of your GUI or perhaps you haven't thought of that yet. If the latter then that is something to think about but not an absolute requirement. You could for example use Webpack.
-
Scout APM
Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.
-
GatsbyJS is the most popular framework for building static websites with a strong focus on SEO. It is fast, flexible, and helps you develop web apps using React. It has been continually staying up to date with the latest technologies over the years as well as applying best practices to search engine algorithms that are constantly changing.
-
If you write the JS in a modern way and use a build process, it isn't difficult. Parcel.js probably has the lowest learning curve. It can also work with purgecss to remove unused CSS.
-
Project mention: Favorite self-rendering Markdown tool in JavaScript | news.ycombinator.com | 2021-12-12
-
Have you considered something like this? https://github.com/vercel/pkg
-
-
SonarQube
Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.
-
Project mention: Reverse Babel? Turning Old Javascript to new? | reddit.com/r/learnjavascript | 2021-06-17
-
-
-
Project mention: Clio: a functional, multi-threaded programming language that compiles to JavaScript | reddit.com/r/functionalprogramming | 2021-10-11
I've been working on a functional programming language in the past few years and I'd like to share it with you, would be nice to have some feedback on it! The language is called "Clio" and you can find it here: https://github.com/clio-lang/clio or here: https://clio-lang.org
-
-
Project mention: webassemblyjs VS adawebpack - a user suggested alternative | libhunt.com/r/webassemblyjs | 2021-12-28
-
-
It also have the support for the the Duckuino converter of the RubberDuky scripts https://github.com/Dukweeno/Duckuino
-
Thank you!! If you don’t mind me asking what did you use to compile? I’m using https://github.com/benzino77/tasmocompiler
-
The idea of writing such article popped into my mind while working on my Webflow/React transpiler. All I wanted to do was to take a JS code string and transform it in such way that globals won’t be redefined if already so:
-
serverless-layers
Serverless.js plugin that implements AWS Lambda Layers which reduces drastically lambda size, warm-up and deployment time.
-
Project mention: What's something you do a lot in datapacks that you wish was easier? | reddit.com/r/MinecraftCommands | 2021-11-23
There's already things like MCScript and ObjD (both made by the same person), but I'm not really a big fan of their syntax, especially not ObjD. I want to go for something more C-like.
-
DataFormsJS
🌟 DataFormsJS 🌟 A minimal JavaScript Framework, standalone React and Web Components, and JSX Compiler for rapid development of high quality websites and single page applications.
DataFormsJS JSX Loader - Small JavaScript Compiler for quickly converting JSX to JS directly on a web page
-
Project mention: I want to learn D3. I don’t want to learn Observable. Is that ok? (2019-2021) | news.ycombinator.com | 2021-06-13
As someone building an in-browser notebook I have a lot of opinions on notebook environments. Notebooks serve different purposes, sometimes the notebook itself is the end-goal because the author is creating an interactive tutorial or explaining a complex concept with a bunch of visualizations. Observable is a fantastic tool for that, and the kind-of-Javascript reactive programming system it is built on is a great fit for that.
Outside of that use-case, I think notebooks are great for the first 20% of the effort that gets 80% of the work done. If it turns out one also needs to do the other 80% of the effort to get the last 20%, it is time to "graduate" away from a notebook. For instance if I am participating in a Kaggle machine learning competition I may train my first models in a Jupyter notebook for quick iteration on ideas, but when I settle onto a more rigid pipeline and infra, I will move to plain Python files that I can test and collaborate on.
This "graduation" from notebook to the "production/serious" environment should be straightforward, which means there shouldn't be too much magic in the notebook without me opting into it. Documentation in my eyes is not so different, I should be able to copy the examples easily into my JS project without knowing specifics of Observable and adapt it to my problem. Saying "don't be lazy and just learn Observable", or "you must learn D3 itself properly to be able to use it anyway" is not helpful. Observable being a closed, walled garden doesn't help: not being able to author notebooks without using their closed source editor is a liability that I can totally understand makes it a non-starter for some companies and individuals.
I think it's ok to plug my own project: It's called Starboard [1] and is truly open source [2]. It's built on different principles: it's hackable, extendable, embeddable, shareable, and easy to check into git (i.e. I try to take what makes the web so great and put that in a notebook environment). You write vanilla JS/ES/Python/HTML/CSS, but you can also import your own more advanced cell types. Here's an example which actually introduces an Observable cell type [3] which is built upon the Observable runtime (which is open source) and an unofficial compiler package [4]. I would be happy for the D3 examples to be expressed in these really-close-to-vanilla JS notebooks, but I can convince the maintainers to do so.
[1]: https://starboard.gg
[2]: https://github.com/gzuidhof/starboard-notebook
[3]: https://starboard.gg/gz/open-source-observablehq-nfwK2VA
[4]: https://github.com/asg017/unofficial-observablehq-compiler
-
Prior to version v0.11.0, Clio used JSON for serialization. JSON is available everywhere and it’s fairly fast, so at first, it might sound like a good idea to go with JSON. Unfortunately, as soon as we start serializing custom types with JSON, its performance degrades to the point that it’s not efficient anymore. To solve this issue, I created a serialization library for JavaScript named Sia, and to boost its serialization performance to the next level, I also designed a new text encoding which I called utfz. I spent over a year optimizing these two libraries, and as a result, managed to make Sia so fast that the pure JavaScript version of it beats even the performance of the native serialization libraries available for Node.js!
-
Method calls are nothing special, just calls which have the form .(). For example: const foo = { bar: function () { console.log(this); } }; foo.bar(); Enter fullscreen mode Exit fullscreen mode For method calls, this gets set to the object from which the method was called. Again, functions don't matter* for this, just the calls. function foo() { console.log(this); } let x = { bar: foo }; foo(); // Window x.bar(); // x let baz = x.bar; baz(); // Window Enter fullscreen mode Exit fullscreen mode Even baz will print Window. It's not a method call, it doesn't follow the method call format! 3. Constructor calls Or new calls (are calls too I suppose). In that case this gets set to the empty object {}. function Foo() { console.log(this); } new Foo(); // {} Foo(); // Window let x = { foo: Foo }; x.foo(); // x Enter fullscreen mode Exit fullscreen mode That's pretty much all there is to it......... ........or is it?! I apologize for this Remember how I told you this is all about function calls, not the functions themselves? Well, I lied. Ok look, let me remind you once again: They made javascript in 10 days! The this rules we've discussed above, they are a bit limiting. So there's three* ways you can override these rules. * don't you dare even mention apply 1. call The special call method on functions allows you to pass your own custom value of this to a function call (or the call's scope I should say). function foo() { console.log(this); } foo.call({ a: 42 }); // { a: 42 } Enter fullscreen mode Exit fullscreen mode 2. bind bind is another builtin method on functions. Much like call it too allows you to pass a custom value for this to the function call. Except unlike call, bind doesn't immediately call the function. It instead returns a special 'bound' functions. function foo() { console.log(this); } let bar = foo.bind({ a: 42 }); foo(); // Window bar(); // { a: 42 } Enter fullscreen mode Exit fullscreen mode 3. Arrow functions Arrow functions are the third way to override the call rules for this described previously. Arrow functions capture the this from the function scope in which they are created. function foo() { const bar = () => { console.log(this); }; return bar; } let bar = foo.call({ a: 42 }); bar(); // { a: 42 } Enter fullscreen mode Exit fullscreen mode So they're essentially the same as defining a normal function but then also binding it. // achieves the same effect function foo() { const bar = (function () { console.log(this); }).bind(this); return bar; } let bar = foo.call({ a: 42 }); bar(); // { a: 42 } Enter fullscreen mode Exit fullscreen mode In summary Yes, no pun in the heading this time (oops). The key takeaways are this: In JS this is associated with the current function scope, and since function scopes are associated with functions calls -- this is associated with calls. Those are the rules but they can be overridden. That is the reason why people are often confused when passing functions referencing this to callbacks. It's also why you were told to use arrow functions if you need to pass them to callbacks. I too was confused about this for a long time. Instead of taking the more sensible approach of reading an article such as this one, I instead decided to implement my own javascript. I wrote a subset of javascript. In that subset of javascript. If you want to go down that rabbit hole, then check out the repo: https://github.com/BlueBlazin/thislang If you want more posts on other javascript or computing related topics let me know on twitter: https://twitter.com/suicuneblue
JavaScript Compiler related posts
- Whats the best way to hide your node ja code?
- Is Next a good choice to rebuild my portfolio site with or would this be considered overkill?
- Build a video call app with Svelte in an afternoon
- Package your NodeJS Lambda functions individually with esbuild for faster cold-start times
- [AskJS] Do you also spend more time configuring tooling and resolving package problems than actually working?
- Developer Education – Don’t Underestimate Your Own Expertise with Megan Sullivan
- Auto-Currying In TypeScript
Index
What are some of the best open-source Compiler projects in JavaScript? This list will help you:
| Project | Stars | |
|---|---|---|
| 1 | Next.js | 79,914 |
| 2 | webpack | 60,261 |
| 3 | Gatsby | 52,188 |
| 4 | parcel | 39,958 |
| 5 | marked | 26,743 |
| 6 | pkg | 19,538 |
| 7 | compiler-explorer | 10,025 |
| 8 | Lebab | 5,481 |
| 9 | bytenode | 1,612 |
| 10 | pyret-lang | 894 |
| 11 | clio | 886 |
| 12 | sablejs | 691 |
| 13 | webassemblyjs | 635 |
| 14 | hyper-haskell-server | 356 |
| 15 | Duckuino | 281 |
| 16 | tasmocompiler | 238 |
| 17 | Appfairy | 209 |
| 18 | serverless-layers | 161 |
| 19 | mcscript | 154 |
| 20 | DataFormsJS | 119 |
| 21 | unofficial-observablehq-compiler | 81 |
| 22 | sia | 42 |
| 23 | thislang | 27 |
Are you hiring? Post a new remote job listing for free.
