15 ms·
Why am I writing a JavaScript toolchain in Zig?
- hu3 2y agoZig is becoming a strong ecosystem for JS/TS tooling. Not sure if it started with Bun but there's good momentum.
- BiteCode_dev 2y agoMaybe zig will become what rust is for python. But JS needs a better compiled extension story for that to happen. The absence of a standard like wheels makes everything difficult.
- DecoySalamander 2y agoI don't think that compiled extensions are a good solution for any particular task. Projects that need some code outside of JS ecosystem can compile it to WASM, project that need a lot of it should be done in that language instead.
- BiteCode_dev 2y agoThe entire AI ecosystem, the scientific stack, the GIS crowd and 3D modeling community disagree with you. And they went for python, not js, because of this.
- DecoySalamander 2y agoYou're providing examples of "project that need a lot of it should be done in that language instead". What would these projects even gain from using nodejs on backend and packing most of their business code into extensions for node?
- BiteCode_dev 2y agoTalk is cheap, they coded it.
- preommr 2y agoI am getting the strongest sense of deja vu here. I could swear I saw this exact comment on this topic quite recently, but not as recently as the last few hours.
- meiraleal 2y agoMight be the case, I don't know why but sometimes HN gives a second shot to some posts and the comments that were made a few days ago appears as if written now. This was posted 3 days ago.
- nox101 2y agoPersonally I hate tooling for one language written in another. I hate python used to generate C++. I hate go used to generate C++ or JavaScript. Every added language adds more knowledge needed to contribute. For every 1000 JS developers and every 1000 Zig developers there are 25 that know both. Only those developers can modify the system. Further, you double the dependencies. JS pulls in library to do X that requires 50 dependencies, Zig pulls in a library to do X that requires 50 dependencies. You also have 2 toolchains to maintain. And you have 2 dev environments to maintain. Get all your editors/IDEs to understand both language. Get double your checkers, double your testing, etc etc. You effectively increase the tech debt exponentially.
- rizky05 2y ago[dead]
- hawski 2y agoJS culture is to pull a dependency for anything, in Zig land I assume it is more conservative like C or C++: pull one or two for your specific bigger picture or often enough none at all, because people pride themselves with projects having the minimal amount of dependencies. Otherwise there is truth to what you are saying. The thing about the tooling is often that most users do not have the ability to contribute even if it is in a language they are proficient in. Oh and until there is a good enough AOT compiler for JS there will always be a lot of tooling that is not in JS.
- BiteCode_dev 2y agoI get your point, but once in a while, you get a gem like uv for python. The fact uv is not in python means it's immune to the many bootstrapping problems the language suffers, which in itself is a huge win. Granted, it works only because it's well engineered. The python integration is fluid, it respects standards, you never actually feels you are dealing with a separate tech. This is rare. Usually the experience is more something like asdf which gets 70% there then left you hanging. However, when that works, it brings many benefits. An unconspiscious one for uv is that we now have a packaging tool compatible with pip that you can call from any other language with no need for a python runtime, and no risk of breaking if other runtimes exist and move.
- andrew-jack 2y ago[flagged]
- spiritplumber 2y agoWhy are you writing a JavaScript toolchain in Zig? For great justice? You know what you doing.
- injuly 2y ago> For great justice? You know what you doing. Not sure what to make of that. Can you elaborate?
- spiritplumber 2y agohttps://en.wikipedia.org/wiki/All_your_base_are_belong_to_us https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us Ancient meme.
- injuly 2y agoAh, I'd only know the title, "all your base are belong to us", haha.
- peutetre 2y agoYou might as well solve the whole problem and just compile to WebAssembly. Cut out JavaScript now as much as possible now and eventually altogether.
- ksec 2y agoDoes WebAssembly even have DOM access yet? Or in the next 2 - 3 years? There was a discussion about 1-2 years ago suggesting WebAssembly isn't here to replace JS hence access to DOM isn't even a priority.
- DarkNova6 2y agoIs calling a WA Wrapper around aJS function accessing the DOM this inefficient?
- peutetre 2y agoHere's a web framework in Rust: https://www.leptos.dev/ https://www.leptos.dev/ Here's Scheme in wasm calling JavaScript functions and DOM methods: https://spritely.institute/news/building-interactive-web-pages-with-guile-hoot.html https://spritely.institute/news/building-interactive-web-pag... As time goes on WebAssembly will keep displacing JavaScript. We've entered the era of Zombie JavaScript.
- esperent 2y agoI scanned the docs but don't have time to deep dive, and I couldn't see: how does this access the DOM? Does it call JS DOM API functions from rust? And what's the performance like for doing that?
- rendaw 2y agoNot specific to leptos. My understanding is very rough, but rust's wasm-bindgen generates a javascript translation layer for the wasm. (Roughly) Javascript objects are stored in a lookup table and rust gets the handle (a number). Rust makes calls with that handle, which get translated back into javascript calls using the actual object. Similarly (I think) proxy objects are created for rust objects so javascript can call rust. I was benchmarking some dom manipulation code and saw large GC pauses corresponding to the number of `element.classList` accesses I was doing from rust. I think the answer is that performance isn't great (compared to if browsers provided a wasm-native api that didn't have to go through javascript), but if you're doing a lot of calculation in rust or are writing a typically small UI it's not a significant cost... may be more important for graphics and visualization work.
- lenkite 2y agoThe ECMAScript committee really need to address the core issues of JS performance - native integers, structs, linear layouts, stack allocation, SIMD, memory arenas, etc. Javascript should ideally be capable of superb performance for its own tools.
- pjmlp 2y agoJavaScript should stay confined to the browser, people are solving the wrong problem.
- wiseowise 2y agoAs if those things don’t apply to browser.
- mu53 2y agoJS is eating the world. You can fight it like so many people before, but you will lose like everyone else
- datadeft 2y agoSame could have sad on any random subject. Examples: - High-fructose corn syrup is eating the world. . You can fight it like so many people before, but you will lose like everyone else - Cancer is eating the world. You can fight it like so many people before, but you will lose like everyone else Etc. I think bad things could be replaced with better things where we have this luxury. Taking a passive stance on this is pointless and lazy.
- meiraleal 2y agoThat's because you dislike JS and think it is a problem to solve. That's a you problem. JS is no HFCS, what an absurd comparison.
- pjmlp 2y agoUntil there are electricity bills from servers to pay. JavaScript on the server, only when I can't say no for whatever reason, like being forced to search for another job as consequence of it. Instead of rewriting JavaScript tools in Zig, Rust, Go, whatever cool compiled language of the month, use the said language directly.
- tacitusarc 2y agoPlease just don’t make the opinionated formatted use two space indentation. That is one of the craziest recent trends in the JS ecosystem.
- azemetre 2y agoCan you say what you’d prefer and why? I often use very large fonts, well large compared to my peers, when coding and really prefer tabs as I can define their width myself.
- tacitusarc 2y agoTabs, four spaces, hell even three spaces. I care very little about formatting as long as I can understand quickly what I’m looking at. So basically anything greater than two spaces.
- DecoySalamander 2y agoSpaces in indentation feel like an artifact of bygone era when we didn't have proper tooling and had to do everything manually, one keystroke at a time. Personally I just hit TAB and commit whatever is in default config of autoformatter utility.
- whs 2y agoNot OP, but I also tabs. Usually I set tab to 4 spaces as 2 space is too little to clearly see the indentation, but in frontend projects usually I'd need to set it to 2 as otherwise the JSX layout would easily overflow horizontally. JS also prefer callback-style code that requires another indentation, which might not always be possible to replace with await.
- arresin 2y agoSame here. It encourages deep indentation and at the same time makes the indents harder to quickly parse. Also single bloody quotes. Why?
- KPGv2 2y ago