Personally 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.

I 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.

JS 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.

The worse is when your CLI tool depends on some random runtime[1] being available on your system, most notably cloud provider CLIs relying on python being available in the system (GCP CLI still does this, AWS CLI used to).

When step 1 of your tool is "install ruby/python/nodejs/JVM"[2] it means you do not care about your users. Either bundle[3] the runtime with your tool or make it in a statically linked binary.

Like why am I, as a go/nodejs developer, need to figure out how to install python2 and pip and make them work just to have the privilege of paying you money to host my code.

[1]: Some runtimes come pre-installed in some OS (like Ruby in Macos) so tools often rely on it, that is NOT okay either. OS gets updated, versions change and tools break.

[2]: The only runtime under this sun that is acceptable to rely on is Bash and even that it is not great because Windows.

[3]: I think the cloud providers specifically don't bundle like that because the CLI gets too big to download which makes it hard to use in automated process (like CI pipelines). But this is no excuse, just make your tool in a different language.

Unfortunately, "JS tooling in JS" is a dead end.

Countless people before me have tried, and I myself have written and maintained a (proprietary) JS toolchain that has caused a some trouble with users over the years.

In the end, using a systems language is what I've settled on.

> Further, you double the dependencies

I'm acutely aware of this problem. Which is why if you look at Jam now, it has zero dependencies. Not even libc (which is mostly thanks to Zig).

The only "dependency" is a Unicode property detection library I wrote for Jam itself. And it is currently the fastest implementation for Unicode identifiers to exist. This simply isn't possible in JavaScript.

Same story with the Parser, etc. Parsers for JS already exist, but it's already known how far one can go, stitching together existing tools that aren't meant to work with each other.

Some dependencies can't be avoided in the long run, But I try to be very cautious, and vet every dependency thoroughly before considering it an option.

Ultimately, the dependence on two languages is a tradeoff that I've accepted, and the problem you mentioned with dev environments is one I'm going have to live with.

I think it ultimately is a sign of the need for better languages. Of course, there are always engineering compromises. But I think a better world is possible, in which we don't have massive software projects written in JavaScript or Python.

> You effectively increase the tech debt exponentially.

You're generally right, but the JS eco system has true culture problems, a barrier like Zig brings lots of virtue to such a project, there is space for a good tradeoff on that front.

While i can agree, Js is such an inefficient beast that using more efficient languages is IMHO mandatory.

No JS written tool will ever be faster than, for example, esbuild (Go).

esbuild is a bit unfair example because Go is really great fit for this kind of job, it does a lot of I/O, it allocates a lot, and then it just dies. evanw even tried to use Rust at first but it was slower than Go version.

IMHO, if JS had struct types, the difference could be much smaller. Dead proposal here: https://github.com/rbuckton/proposal-struct

Zig is becoming a strong ecosystem for JS/TS tooling.

Not sure if it started with Bun but there's good momentum.

Maybe 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.

I 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.

The 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.

You'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?

Talk is cheap, they coded it.

I 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.

Might 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.

The 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.

JavaScript should stay confined to the browser, people are solving the wrong problem.

JS is eating the world. You can fight it like so many people before, but you will lose like everyone else

Grandparent is making the case that it shouldn't have this role, which is independent of it having the role. It seems contrary to "the hacker spirit" to use the is-ought fallacy to discourage innovation. Is it wrong to have a contrary, if probably doomed to fail, stance to the mainstream? But of course a contrary idea would fail if everyone seeks the mainstream instead of it. To justify sticking to the mainstream, you have to weigh its costs against the benefits of the alternative too.

Same 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.

You are not paying attention. WASM's ecosystem is moving slowly but surely in the direction of JS being thrown away for good. Ain't happening anytime soon -- sadly -- but especially with WIT used to specify various modules and collections of modules plus having more or less uniform function specification, the days of JS' monopoly are numbered. The writing is on the wall. There are successful WASM web apps not written in JS today.

JS is being tolerated. Not adored.

Frontenders are living in a bubble and don't see it.

> There are successful WASM web apps not written in JS today.

Such as?

> JS is being tolerated. Not adored.

Can you prove it? I’ve seen enough people of JS being adored. I am one of them (maybe because I use it mostly for hobby projects).

If you haven't coded serious projects in at least 5 very different languages, you likely adore one language because you just don't know better.

There is such a variation between js, perl, python, rust, C#, lisp, bash, haskell, erlang and sql that the blind spot is huge.

It's like eating hot dogs all your life and debating food merits with people that tasted japanese, indian and french food.

I’m mixing Python, C++, Java, Kotlin and shell scripting professionally. Used to work on enterprise C# project. Experimented on a hobby level with Elixir, Haskell, OCaml, Ruby, TypeScript, JS, Dart.

I'm recently enjoying F# a lot. What really sold it was partial application and absolutely bonkers type inference with gradual typing. You just write code and let type system infer the signature of the functions, only specifying the types when necessary. It's so much cleaner and I'm sorely missing it in C#.

It's a bit off-topic but if you liked Elixir it's kind of like Elixir but fast, and like OCaml but widely usable in production. It could also be familiar after Python due to mostly indentation-based scoping and not having to define signatures (except you go from something terrible and untyped to Hindley-Milner).

Python, C++, Java, Kotlin and shell scripting are all globally mutable procedural / imperative languages. Of course you'll also like JS.

Spend several years with LISP, Elixir, Haskell, OCaml, then you'd be in a better position to say you keep loving JS.

You are sticking to the same type of languages. This warps your point of view.

What an obnoxious and condescending response. They said they've used those languages. Consider that these languages have huge flaws of their own. Elixir doesn't even have a proper language server. Using niche languages does not automatically make you special on internet forums.

Elixir has two fully functional language servers and it's very far from niche, or I've been spending imaginary money for the last 9 years.

What I said still applies, the guy seems to have a familiarity bias and said nothing to show otherwise.

As for being condescending, your reply seems like a textbook example.

Oh yeah, that's not obnoxious at all. :D

Lost on your way to Reddit, I see.

you can dish it out but you can't take it, I see... :)

I said was that I believe the poster lacks the perspective to criticize certain languages. That was and still is the topic.

You are free to interpret it any flame-bait ways. I ain't biting though.

Peace.

did you actually read the post? where from his post do you get "poster lacks the perspective to criticize certain languages?"

and of course even more pertinent - which languages did he even criticize other than to point out things that are not possible in Scala/Rust (certainly not a critique, each language has its pros/cons...)

I believe all of Zig, Rust and Go have been around for long enough to not deserve the moniker "cool compiled language of the month" though.

I do agree that it's time to write frontend not in JS. It has been time for 10+ years even but oh well.

On the contrary, it's time to move to JS for the UI of desktop applications as well. We've seen this approach become more and more popular with Electron over the last 10 years.

It's also possible to use JS (or TypeScript) on the desktop, without having the need for a browser or a webview. That's for example what we're trying to do with Slint https://slint.dev Then you get the good part of javacript for your application logic, without the bloat and attack surface of a browser.

If you say so. Take a look at Slack and Teams and tell me that's what a performant and lagless UI feels like.

...Oh? What's that? I am hearing something faint in the distance, like... "their devs are not using JS well", maybe?

Tell you what. If a technology can be held wrong, then it's a bad technology. Which, yes, encompasses most technology nowadays. You heard me.

I use Discord daily and can't really call it slow and laggy, it feels adequate if anything.

Can't really comment on Slack and Teams - I've obviously used both, but haven't been a heavy user of Teams and never was in a large "corporation-wide" Slack instance. I have, however, been a heavy user and developer of a Slack competitor. Not surprisingly, it had a lot of problems, but most of them stemmed from a) clumsy handling of megabytes of chat logs, b) a codebase that grew organically out of a startup project and needed a major rewrite, c) misallocation of resources (for the longest time, everything Electron-related was handled by a single developer in a satellite office). In my opinion, we would have had the same performance issues and bugs if it had been developed in any other language. We actually had some Qt apps that we deprecated and rewrote in JS as part of the main client - there was no user-noticeable performance drop, but significantly fewer crashes.

...OK?

It was already mentioned that people can do better apps with Electron than others. Not surprising.

My objection is that the possibility to make laggy and bad apps exists. It should not exist.

As for what problems a Slack competitor faces, well, I am not interested. That's the dev team's problem and not mine. I want a lagless Slack.

> the possibility to make laggy and bad apps exists. It should not exist

I see. Then the only way forward is to stop all software development altogether and enjoy memories of apps that we used 20 years ago when we were much younger, and fantasies of apps that we could build with newly acquired wisdom, but will not.

Funny, still not what I said.

Progress is way too slow and blindly follows local maximii. That's not OK. That's the part I am expressing displeasure with.

But can you point to an app that has the same UX functionality as Slack that's been successfully implemented using Qt or another native toolkit?

I'm building a chat app - well, a client for LLMs using Qt (QML + C++). It's highly performant with beautiful animations: https://rubymamistvalove.com/client.mp4

I also created a native block editor (like Notion's) in QML and C++: https://get-notes.com

I really hope that I can show that Qt with QML is a viable alternative to the inefficient resource hogs that are Electron/web apps.

Wish I could but many people gave up and started using Electron due to employability. And we're stuck with crappy laggy UIs. I remember the MirandaIM multi-messenger from 20+ years ago very fondly... 50MB RAM usage and I was signed to 4 services, on a computer that my smartphone today can emulate 16 of, simultaneously, and it was still running faster than you can blink. Ehhhh, good times.

Electron/JS is a herd just running in one direction, personified.

The fact that something is popular does not imply quality, not at all. Most of the time it implies that everybody settled on it and does not want to hear otherwise for various reasons (in this case: money, as employers are never going to give you the requisite time to build stuff with Qt or others).

It could be that Qt would work better and no-one is using it for the sorts of reasons that you mention. But I think the more plausible explanation is that no UI library can compete with what the browser offers anymore. This would hardly be surprising. The person hours invested in HTML+CSS rendering vastly exceed those invested in Qt or any other UI lib.

The kind of argument you're making would be much more convincing if there were relevant examples of Qt-based apps that provided a superior user experience to the Electron apps you're criticising.

I don't personally find Electron apps laggy in general. VSCode is very responsive, for example.

Probably because you're using a very performant machine (M1-M4 are extremely capable), but other than responsiveness (which even on an M1 isn't perfect), you got 3 more issues with Electron apps:

1. High RAM usage.

2. The bloat will accelerate as more abstractions are added to web frameworks.

3. Battery usage - the most noticeable issue for me. I've yet to empirically test this, but my guess would be that Electron apps use substantially more power than native apps. I will test this theory eventually.

Yeah VSCode is fine, I agree. But as mentioned above, if one can screw up their Electron app to be as laggy as Slack then the tech is not good. I stand by that statement.

> The kind of argument you're making would be much more convincing if there were relevant examples of Qt-based apps that provided a superior user experience to the Electron apps you're criticising.

That's arguing in circles and it's the chicken-and-egg problem. Toolkits like Qt get less and less mindshare because Electron is desired and is encouraged by employers. I can't speak for Qt in particular btw, just using it as an example here, but my point is that it could be the best UI toolkit ever but since it takes a little more time to spin up an app with it then the business will want you to not use it.

Hence, I can't show you those Qt apps.

I feel that in these discussions people just blindly trust popularity to be an indicator of quality. I have a huge problem with that mindset and my career has seen the exact opposite, many times. Hence my comments. And if you want to take away just one thing from our discussion, it's this: please don't mistake Electron's popularity with the idea that Electron is the best UI toolkit.

It's not arguing in circles. It's just asking you for evidence that an app like Slack would be better if it were implemented in Qt or a similar library. If there is literally no example of this having been done successfully, how can you be so confident that it would work great?

>Toolkits like Qt get less and less mindshare because Electron is desired and is encouraged by employers.

But why is it desired? I've used Qt before (a long time ago) and know enough C++ to be dangerous. I'd still avoid using Qt simply because I already know how to make UI's in HTML+CSS. I can't say that replacing those tools with a manually-constructed C++ object graph – or with an unfamiliar markup language (QML) – strikes me as an appealing option. Most of the people carping about Electron apps on HN don't want to make a UI in Qt either! It is becoming one of these legendary magical technologies (like Lisp) that is much praised and yet too little used for its flaws to be common knowledge.

> If there is literally no example of this having been done successfully, how can you be so confident that it would work great?

Past experiences. I've seen much smoother and faster apps more than 20 years ago. Surely they weren't using black magic.

> But why is it desired?

Because it is slightly quicker to start an app with it and because people want to have a web variant of it (runnable in the browser) if/when necessary. Those are actual selling points and I agree with them wholeheartedly -- I object to Electron's lagginess however. They can and they should do better.

> I'd still avoid using Qt simply because I already know how to make UI's in HTML+CSS.

Well yes, that's one of the factors -- people default to what they already know. But zero mention is given to the numerous problems with the DOM model of making UIs as well... a topic way too big for me to have any desire to delve in, again.

Inertia. A bad thing starts being used widely because of 2-3 desirable traits, and when it gains enough critical mass nobody wants to criticize it.

Well, I do.

>I've seen much smoother and faster apps more than 20 years ago

Me too, but they didn't have all the whizzbang UI features that you get for free from a web stack. I could live without most of those, but users do expect all that stuff to work these days.

I am one of those users. I do my job as a programmer to the best of my ability and I am not allowing lags for as much as humanly possible (sometimes you can't do anything about a slow 3rd party API though). They should do the same. I have no sympathy for sloppy work, and Slack and Teams are in the top two spots there.

Sloppy work and bad code are orthogonal issues to choice of technology. There are some sloppily written Qt apps out there too.

If the Slack devs are as sloppy as you say, then we ought to be thankful that they’re writing JS and not C++!

Lag is something that some people care about a lot. I actually think that most users don’t notice it or care very much, up to a certain point.

> There are some sloppily written Qt apps out there too.

I specifically asked not to focus on examples but OK, I guess you really had to get it off your chest. ¯\_(ツ)_/¯

The topic was not "Electron vs. Qt" at all.

> I actually think that most users don’t notice it or care very much, up to a certain point.

Good for them, to me it's a mood and productivity killer. And no I'll not change my mind on this, ever.

Broader point is: the people who worked on Electron, Slack etc. should have really done better. But I have witnessed how job security almost always leads to sloppy work.

Actually, the people who created Electron (and the code editor Atom), themselves abandoned it to create a performant code editor called Zed - with its own GUI toolkit based on Rust.

Case in point / point proven then. :D

I didn't know they were the same. Fascinating actually, thanks for making me aware of it!

What kind of UI feature are you speaking of? I would love to see how easy it'd be to do in QML.

One obvious reason why Qt is less popular is the ability for companies to deploy web apps (non Electron, but in the browser). Many end users expect a desktop/mobile app to also be accessible using the browser.

I'd argue that QML is an order of magnitude easier to develop than any other web frameworks (yes, you do have to get familiar with it, and if you made some apps before you could re-use some essential, battle-tested components). I hope to maybe share/sell some of mine some day.

I'm not sure what to answer regarding the browser experience. WASM isn't really there, isn't it? I haven't had a chance to test it on my own apps yet tho. I recently had a thought that maybe that Qt Company should also target HTML/CSS/JS generation of a QML file. Another, more interesting thought would be for browsers to be able to process and render QML files natively (but that won't happen without substential market share).

> but that won't happen without substential market share

So again: the chicken-and-egg problem.

Basically, nothing is going to improve until somebody rolls up their sleeves and does all the hard work for free and do better than Electron -- or a corporation will push for it, it's always one of both. Then everybody else will flock to them.

That's what I observed several times during my life and career.

Completely agree. I'll try my best (:

Needlessly provocative. Sounds more like you felt attacked.

No reason for me to feel attacked, I pointed out that what you said doesn't make much sense in terms of how long have these languages been around.

Would be clear if it did not seem to me that you are including three languages that have been around for a while in the "whatever cool compiled language of the month" group.

If not -- then clear. If yes, then this is getting even more confusing.

It is called an enumerations of choices, 3 named ones, followed by a generalisation of whatever else might possible as option.

Given that boring languages like Java, C#, OCaml, Haskell are kind behind their times for cool kids to rewrite stuff, that leaves the unamed cool programming language of the month as option, whatever that language may be.

Hello, friend! Professional writer here.

An enumeration of three choices followed by a generalization reads like the three choices are examples of the generalization, not disjoint.

Honestly, you are not making this better. This comment also implicitly puts Rust and Zig in the "unnamed cool programming language of the month" group again unless I completely lost the ability to read English.

And seeing that a writer commented something similar to my comments upthread, I am not very inclined to assume I can't read English.

Still, your point is taken, I just can't help but think I am sensing some slight... shall we call it non-preference... towards a few programming languages.

As if those things don’t apply to browser.

You might as well solve the whole problem and just compile to WebAssembly. Cut out JavaScript now as much as possible now and eventually altogether.

Does 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.

Here's a web framework in Rust: https://www.leptos.dev/

Here's Scheme in wasm calling JavaScript functions and DOM methods: 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.

I 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?

Not 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.

> As time goes on WebAssembly will keep displacing JavaScript. We've entered the era of Zombie JavaScript.

Just like Java has been dead for 20 years, now it is JS turn.

Delusional.

Is calling a WA Wrapper around aJS function accessing the DOM this inefficient?

Why are you writing a JavaScript toolchain in Zig?

For great justice? You know what you doing.

> For great justice? You know what you doing.

Not sure what to make of that. Can you elaborate?

https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us Ancient meme.

Ah, I'd only know the title, "all your base are belong to us", haha.

Can 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.

Not 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.

Tabs, 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.

> Also single bloody quotes. Why?

Because double quotes requires two keystrokes. Single quotes requires one. The only defense of double quotes is an appeal to history.

Not everyone uses the same keyboard you do. With a German layout it's much easier for me to type double quotes.

That's not to say everyone should use them, but reality is more nuanced than you make it seem.

I can see why people may take issue with tabs VS spaces, that's as old a debate as programming languages themselves. But taking issue with single quotes is just on another level of bike shedding! WTF is wrong with single quotes???

Single quotes are quite a common English punctuation character. Particularly in the strings I tend to hardcode in programs, it is way more likely that I need to write a single quote than I do a double quote.

When that happens, I have to escape the quote (if the language even allows escapes in single quoted strings) or change the whole string to double quotes.

Because typing a single quote will break parsing, it's also hard for tooling to assist. If I put a single quote unescaped, the auto formatter will probably barf.

I prefer backtick.

The truly patrician choice.