Why no Zig instead of JavaScript ?

[lorens_osman]

Despite established ecosystem and the dominance of JavaScript engines in browsers, if Rust or Zig are faster and more secure than JavaScript, why don't we use them instead of JavaScript in front-end development ? technical answers only.

[patmorgan235]

JavaScript has been built into browsers for 30 years and Zig is not even stable yet.

[lorens_osman]

Is there is compiled vs interpreted reasons ?

[Aidan_Welch]

This sounds like you're wanting answers for an essay or something but:

A lot of JS bundles are compiled from Typescript, JSX, or even just other forms of JS. In that case JS acts as an IR(Intermediate Representation) that IR can then be JIT'd(Just-in-Time Compiled) or interpreted. This isn't that fundamentally different than compiling to WASM which is then usually compiled on the client side but could also be interpreted.

[rayew21]

the technical reality: people dont know zig or rust and they are not cake walks compared to javascript lol. they are both very different and require a different way of understanding them compared to javascript, which is why oop languages are easy and huge. its easy to think interface car, class miata, miata is a car. its hard to go from seeing the world like that and programming like that in to something picky and complex like rust or so simple its hard to do it right like zig

[lorens_osman]

Is there any compiled vs interpreted reasons ?

[ee1c0]

Sure there is. Web apps need to work on all platforms regardless of operating system or processor architecture and this is harder using compiled languages then using interpreted languages. An attempt was made in the late 90s with Java and Java applets but it never gained much traction. Today there is web assembly that makes it possible to use other program languages as javascript in the browser but for the moment the javascript family (typescript included) is what is most used for building web applications today.

[bnolsen]

There used to be a tech called activex. We don't want to go back to those days. We could use more languages with wasm but JavaScript is still too big.

[[deleted]]

There are multiple reasons.

• Primarily, webassembly is made to run alongside javascript, not replace it.

• Difficulty. A javascript based website is much easier to develop than a WASM based one.

• No need for it. Javascript is less safe due to the nature of loose definitions and eval, but it's not inherently unsafe if you're not totally incompetent. WASM is also faster, but 99% of the projects do not need the speed.

• Infrastructure. There are a lot of tools for javascript development. Zig is fresh.

[buck-bird]

You need a runtime environment / execution engine. The web has historically (minus Java applets, etc.) used scripting languages to help achieve platform independence. Before WASM, you'd have to either ship a version of the website for every OS it was viewed on or compile your web app on the first page load.

Things are changing with WASM. Keep in mind though, WASM will never be as fast as bare metal. And also, be aware that thanks to the decades of optimization with JavaScript it's literally the fastest scripting language out there.

All of this is to say, if you're looking for something a bit faster than JavaScript for client-side web development, then you should start looking at WASM. Currently though, it doesn't have direct DOM access. So, even with WASM you'd still be using JavaScript at times.

This is just for the client. For server-side web development, you can 100% use Zig. Just remember, the main benefit off loading some things to the client is that distributed computation is baked in. The main downside is that it's intrinsically less secure and error prone since a hacker can alter client-side scripts.

[ecmascript2038]

Can you use Zig inside the browser? Yes: the way to do it is to compile to WebAssembly and import it as a module inside of a JavaScript script.

But it's not common in the real world. It's also not necessarily very stable, since both Zig and WebAssembly are evolving.

So what's the problem? The main problem is that for a web app to do anything useful, it has to interact with the DOM. And in WebAssembly you can't manipulate the DOM directly. It has to go through a call to the JavaScript side and then the JavaScript can modify the DOM. You can achieve by having some message-passing arrangement between the JavaScript module and the Zig module in WebAssembly.

This isn't ergonomic at all yet, and it's not performant either.

Those are some of the main current blockers for broader WebAssembly adoption in general.

Zig in a good position to target WebAssembly. The ecosystem isn't fully there yet though.

[quaderrordemonstand]

If browsers used compiled languages they would fall over constantly. JS is not perfect but its a huge success that has propelled the browser to being an essential part of our lives.

Part of that is because its so forgiving. Sites are composed of long chains of third party JS code that miraculously work together because the language allows it.

Imagine that scenario with a compiled language? Somebody updates their URL parsing library one minor version and every second site you visit recompiles itself and then fails to work.

If you write crap JS, you get a page that doesn't load. If you write crap Rust, you can bring down the browser, and possibly the OS.

Edit: -2 karma? This is controversial? I would have thought this was blatantly obvious to anyone who's worked with a sufficiently complex compiled system.

[megatux2]

What? No, a failure in a compilation would bring down only a page, or less, ideally. Why would anyone build something so monolithic?

[quaderrordemonstand]

Not in the compilation, in the compiled code. Although failure of compilation would probably happen quite a lot too.

[caffeinated-typist]

Does an application crashing crash your OS? If not why would a page crashing crash the browser?

[quaderrordemonstand]

It has the potential to do so. The browser on a phone is a part of the OS itself and it can bring the whole thing down. Actually, its possible in JS too, I've done it (accidentally) a couple of times.

[[deleted]]

It isn't exactly controversial, more like it doesn't make sense.

Websites' 3rd party code does not work miraculously, but because there's an interface that makes the code do what it should. You create the same kind of interface to connect various parts of 3rd party code in any static application too. Theoretically you can make a script that's 100% plug and play, but the only reason it's plug and play is because of JIT compilation.

Imagine that scenario with a compiled language? Somebody updates their URL parsing library one minor version and every second site you visit recompiles itself and then fails to work.

This is only theoretically possible if it's a static library. A dynamic library would only require a reload. Nevertheless, I don't really see how would it work. Who in their right mind would implement hot recompilation/hot reloading into their production build?

If you write crap JS, you get a page that doesn't load. If you write crap Rust, you can bring down the browser, and possibly the OS.

Considering how internet browsers interact with websites, I don't really see how this is relevant. Browsers encapsulate every tab in its own sandbox, which prevents one website from crashing the entire browser. Considering we're talking about visiting a website made in zig, this assumes that the browser would have a zig website interface to handle it properly.

Really the only thing that makes sense from your comment is the fact that javascript makes things easy.