Hacker News Reader

Comment by muglug | Hacker News Reader

Every so often a language comes out that allows frontend developers to put something other than "JavaScript developer" on their CV.

First CoffeeScript, then Flow and TypeScript, then ReasonML, and now Rust with WASM & web macros.

Of these only TypeScript has been successful, partly because it's backed by Microsoft, but mostly because the code you end up writing is very close to JavaScript.

This is not a dig at Rust (which I love) but God help any developer inheriting a frontend codebase with random bits of Rust in 2024.

View on HN

"Rust with WASM & web macros."

It's not really that; it's really just WASM. There's going to be a flood of this sort of thing from all sorts of languages, even multiple per language. It's early days yet and the ground is still being felt out, but eventually the Javascript qua Javascript foundation in the browser is going to be breached and a day will come when it is a minority language (still many years from now), for exactly the same reason that never in the whole history of computing has one general purpose programming language "won". Per https://www.destroyallsoftware.com/talks/the-birth-and-death... , Javascript is going to "win", but it's going to be Javascript in its incarnation as WASM, not the Javascript we know today.

"random bits of Rust in 2024."

And that's "the ground being felt out", not a fundamental problem. I expect to see WASM frameworks develop that are shipped out to the world as WASM and bind to any language. Decent odds they'll be developed in Rust for several reasons (performance not least of all), but you won't need to know that to use it in your Python WASM front-end app or some new WASM-primary language that is nothing more than a gleam in its creator's eye right now. If you don't want the chaos, hey, great. Even people who live on the cutting edge can't be cutting edge in every dimension. By all means sit back and watch from a distance. But these problems will certainly be fixed.

The enemy of this entire thesis is the layers of additional complexity required by such “innovation”. Each layer has its own API and update mechanisms, all of which slow down developer productivity (especially when inheriting a project you did not build).

In some cases that complexity is worth it — Figma, for example, squeezes a lot of value from WASM. I myself have used WASM to create a browser-based testing environment for a Rust-based static analysis tool I’ve built, so my colleagues can quickly repro issues. But for most web development, it’s not worth it.

In the long term, I expect WASM to start blowing away layers of the browser, precisely because of this problem. It may be another 20 years, but it's going to happen.

To put it another way, no, you're not wrong, and yes, the resistance to large-scale changes to the web stack is huge, arguably the largest resistance of all time. Nevertheless, the amount of metaphorical amperage flowing through is even larger and is large enough that it is already "short circuiting" and blasting a new circuit through. It's going to take a while, and the backwards compatibility will be with us for a while, but we're already seeing flashes of websites where you don't need to know the old CSS and HTML and such because they're actually WebGL and WASM. As more capabilities are exposed to WASM and they become more efficient, more and more stuff will be moved into it.

That will cause its own explosion problem, but it'll be handled. It's not like every website is going to write its own bespoke text renderer every single time. And in the end there are some technologies that will fade out and become legacy, then irrelevant. I may yet outlive the HTML/CSS/JS stack.

but once you blow away the layers you are left with a virtual machine with a number of low level APIs. Most people won't want to use them.

Yes, I can see the advantage of rewriting those layers in terms of the lower level APIs, for example if the DOM API were to implemented in WASM, you could keep it out of the browser, and download only when/where needed (with a number of caveats, of course)...

The main issue is that even if you do that, I don't expect an API designed with JS in mind to be a good fit for Rust, and vice versa. The risk is that you end up programming not against the "Web Platform", but "WebJS platform", "WebRust Platform" etc."

My company did an initial evaluation of Rust web development just to see what the options were. Put out some feelers to our web developers to see if they had any opinions about it. It was almost universally negative. Not because the ecosystem or technology is immature, but because our JavaScript/Typescript devs simply could not grok Rust at all. It was too different, or too difficult, or whatever. So we didn't really pursue it any further. At some point though we'll probably just have to hire Rust engineers instead of trying to convert JS devs.

Rust engineers coming from a different niche than frontend development will just LOVE web development.

Maybe the web ecosystem will finally get some sane tooling... or not because those devs will probably be driven to madness.

Funnily enough, web ecosystem has tooling most languages can't even dream of.

- Instant hot reload of application

- Inspect app/page structure in runtime

- Runtime debugging

- Monitor all network requests

- Tools to monitor time spent in functions, painting, redrawing...

- Runtime changes instantly applied

...

At expense of browsers complexity rivaling operating systems.

And now there is essentially one browser who can afford such complexity. Until Google discontinues it.

> at expense of browsers complexity rivaling operating systems.

That's a feature, not a bug, as open source browsers have loosened the importance of the operating system (freed us from the MS monopoly) and enabled an multi trillion dollar web app industry to flourish.

If Google ever discontinued Chrome support it would be picked up by the community in a flash. That's the beauty of open source.

> If Google ever discontinued Chrome support it would be picked up by the community in a flash.

Of course it wouldn't. The number of people capable of managing and developing a full-blown browser is minuscule. Even Microsoft gave up and went with Chrome in the end.

Case in point: how many people picked up Servo? Hell, even Firefox?

To be fair, the number would increase a lot if Google stopped making the web hostile for other software.

What?

Google had long list of oopsies where Google services stopped working because of user agent rejecting non-Chrome browsers.

What does it have to do with the number of people forking and developing their own browser? Agent string sibstitution/emulation has been a thing since time immemorial.

You make your own browsers and issue correct UA (User Agent) only for GMail to stop working. But works fine when issuing Chrome UA. I guess Google is staffed by Howler monkeys, or malicious.

Source: https://archive.is/tgIH9

Pushing for whatever feature they fashion, pushing against stuff that they didn't create, doing things differently for no reason, making sure their software works badly on competitor platforms...

What Google is doing isn't much different from the MS from the 90's, except that they didn't stop improving their browser. At least yet.

Microsoft contributes to Chrome core now, as a result. So does Node.js, Brave, and a litany of other organizations that depend on Chrome/v8.

Yes, they do. And your point? That they are "a community that will pick up Chrome dveelopment in a flash"? That's not how it works.

Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?

> And your point? That they are "a community that will pick up Chrome dveelopment in a flash"? That's not how it works.

Yes it really is how it works. You see, Chromium is used by numerous teams and products already. Developers from these projects already contribute support and patches to Chromium on the regular. That's exactly how open source development works.

> Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?

Microsoft (especially Ballmer era MS) sucks at a number of things. That internet explorer was a bloated piece of trash beyond all repair is hardly an indication that browser development is beyond the capabilities of an open source community. It wasn't that it was "too expensive" for Microsoft to maintain IE. It's just that IE could not possibly compete with Chromium, because they were saddled with too much technical debt from years of bad decisions.

Entire operating systems and databases are maintained by open source foundations. Have you ever heard of Linux? MS cannot compete with Linux at the server game. They waved the white flag on that battle a long time ago as well.

Besides, when you fork a project, you don't have to instantly rebuild everything from scratch. A foundation would kick things off by prioritizing bug patches, security fixes, etc. The RFC process for deciding new web features is already handled by a consortium: https://www.w3.org/

Browsers are now so essential, that there is little incentive for Google to drop out and very much incentive for everyone else to continue or increase their involvement.

With Firefox there is even a viable alternative that isn't controlled by Google in any form. I'd agree on many projects that would be the case. For Chrome, no.

Servo never had significant market share of any kind, but it has recently been picked back up by a foundation. Firefox has been outcompeted by Chrome and Mozilla has made a number of strategic blunders over the years. But by and large people stopped using Firefox because Chrome/Chromium was better on most metrics users care about. Even developers tend to use Chrome/Chromium because of the superior native debugging tools.

But last I checked Firefox is still very much maintained by Mozilla.

The original statement was "If Google ever discontinued Chrome support it would be picked up by the community in a flash."

Why doesn't community pick other browsers in a flash?

What other open source browsers have been left without maintainence? Ones with no market share? As mentioned, Servo was never really finished and yet it has recently been scooped up by the Servo Foundation. Mozilla still very much maintains Firefox.

We have plenty of examples of open source databases, operating systems, libraries and languages leaving the major companies they were created at and being scooped up by a foundation or consortium to maintain.

WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.

But there's plenty of other examples in the open source world. Chromium is far too important, and there's already thousands of eyeballs on that code base. There would be a Chromium Foundation established very quickly if Google abandoned.

> We have plenty of examples of open source databases, operating systems, libraries and languages leaving the major companies they were created at and being scooped up by a foundation or consortium to maintain.

We have just as many left to die. We just don't know or don't talk about them anymore.

> WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.

Ah. So the mythical "community" that will scoop in and continue developing is a compani with a 60-billion yearly revenue. Got it.

> Chromium is far too important, and there's already thousands of eyeballs on that code base.

Eyeballs rarely, if ever, translate into understanding the codebase, or being able to do anything about it.

> There would be a Chromium Foundation established very quickly if Google abandoned.

Can I interest you in Apache Foundation where great amazing projects no longer supported by their original company go to slowly slide into oblivion?

> We have just as many left to die. We just don't know or don't talk about them anymore.

Yes, irrelevant products that no one uses eventually die. At present, Chromium is not one of those, and is installed on billions of devices and used every single day on mobile and on desktop. Entire businesses and derivative ecosystems have been built on top of Chromium (Edge, Brave, Node.js and all of its dependencies, Electron, etc.). If there's an economic incentive to keep an open source product going, it will keep going. Anyway, here's the repo if you're interested in contributing: https://github.com/chromium/chromium

> If Google ever discontinued Chrome support it would be picked up by the community in a flash.

Browsers cost a bunch to develop. Just CI for Servo was 10k per year.

While there are some admirable efforts (Ladybird), browsers complexity means your only specification is Chrome source code.

All that stuff that could be done with a Java (or probably .net or php) server side webapp stack two decades ago...

Instant hot reloading without even recompiling/refreshing the page? Sorry, try again.

Flame charts in Visual Studio 2003? Sorry, try again.

Javascript hot reloading requires a "recompile", you just don't notice it. Import a plain js file without any node tooling and see what you get for free.

> Import a plain js file without any node tooling and see what you get for free.

I get F5 to refresh the page when source code changes. All the other tooling remains the same: https://developer.chrome.com/docs/devtools/

I mean, Chrome even has an animations debugger

> I get F5 to refresh the page when source code changes.

Really? That's surprising but so overkill. How does it know what files to poll and which not to, I assume file:// and localhost but more specific? Does it do it for a webpack/vite app which has its own hot reloading setup?

What do you mean?

F5 refreshes the browser page. This has been the way to develop pages since the first browsers.

And the original question was "Import a plain js file without any node tooling and see what you get for free." You don't get hot reloading but you get all I wrote in my original comment and much more for free.

Yes, I know I was just surprised it even checks for changes without being prompted, but I guess that's where all the resources go. The point I was trying to make was a response to your claim that hot reloading magically happens without "compiling", it doesn't (I know I know, it's transpiling in js).

It usually goes something like this: some tool watches the file system for changes > trigger build > another tool in the chain injects changes into session > picked up by client to reflect changes, if done well without resetting state.

These are many tools in a toolchain working well together. This DOES exist in other languages, incremental builds exists. You can save and restore a binary at a certain state, and it's less hassle than it is in js.

One thing the systems development world has that I haven't seen in browser tools is radare/ghidra to follow code paths but it probably exists as a browser extension. The web is just reinventing and repackaging tools that have existed for decades.

> you get all I wrote in my original comment and much more for free

Yes, but `apt install gdb` is just as "free" as `apt install chrome` no? Everything you mentioned exists in systems development, you just haven't used it.

It's not a "recompile". JS doesn't get compiled, it may get transpiled or minified. Node.js is only used for sending data over a local websocket from the file system to the browser. You can totally also achieve this effect on a local offline webpage that wasn't even being served if you added an input on the page (ie the React docs: https://react.dev/learn).

Yes. But the difference in this context is nitpicking. The browser needs to know what file was changed, and what to do with those changes right? And preserve state. That doesn't magically happen it's the tooling that supports it.

I could probably set up a simple environment to watch for changes, run make, reload the binary at $current_state in gdb with a one-liner. But it doesn't really fit the work flow, and GDB already gets all changes after I run make.

Most backend frameworks can just route new requests to the updated code - so a refresh is all you need (though there are tools that simply make that refresh automatic, which is pretty much how js frameworks work as well. Intellij can also make the whole recompile-replace code function happen on window defocus, so by the time you switch to your browser, it is already refreshed. And nowadays the compile of something like Java can well be faster than whatever that npm monstrosity does)

Many languages have all of that tooling and more. For example C# and Java.

I think Rust has all of that except the hot reload and runtime changes.

> Many languages have all of that tooling and more. For example C# and Java.

Instant hot reloading? Runtime introspection into apps, and into strucutre of the apps, direct view into what the app sends over the network etc.? Open up development tools in your favorite browser, you'll be surprised :)

Don't know of current state but Blazor should check most of them.

Because Balzor piggy-backs the existing web tools ;)

Well, java in debug mode can hot swap class methods, for what it worth.

But the web is definitely the most used “GUI framework” ever, so there is no competition with that on tooling ground, even if there is nothing inherently that would block it, as a dom inspection is pretty easy to implement - just print out the tree of ui nodes.

Pretty much any lisp.

Except for the hot reloading (which you mention twice btw) the tooling for the popular languages has everything in the list, and most can be achieved with GDB and Wireshark alone, in any language that GDB supports.

Don't get me wrong the web pays my bills and I like it but there's no point exaggerating.

> Except for the hot reloading (which you mention twice btw) the tooling for the popular languages has everything in the list, and most can be achieved with GDB and Wireshark alone, in any language that GDB supports.

"Can be achieved" with some additional tools. I doubt you can easily expect the structure of the app, how it repaints, see all the relevant network requests, and also introspect and query the running app, emulate various hardware, inspect and debug animations etc. in most languages.

Yes, there are collections of tools that may give you all that in aggregate, but frankly, it's not close to an "out-of-the-box" experience.

> there's no point exaggerating.

It's not really exaggeration.

Have you used GDB? And network requests is what Wireshark was created for.

Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference. It seems you don't have much experience in the tools you're comparing against. In GDB you would connect to a running application on actual hardware or in a VM, if that's what you're testing. Screen sizes and network can be done locally.

As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser so it's still an "aggregate" as you like to call it.

For me it's the unixy way of doing things and just the way I like it. Do one thing and do it well.

> Have you used GDB?

I've used debuggers in general (IDEA, Resharper, Visual Studio), and even dabbled with disassemblers like IDA in my youth.

> Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference.

So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation).

And can emulate performance with different number of processor cores. Not bad https://developer.chrome.com/docs/devtools/performance/refer...

> As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser

Wat. The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling". So yes, hot loading is a part of tooling. I've yet to see anything outside the web manage hot reloading with any degree of confidence and speed.

You don't like the hot loading, and let's focus on non-moved non-goal non-posts. I hope you noticed the ellipsis at the end of my list?

What's that immediately available tool for GDB and Wireshark whatever that:

- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.

- examine and debug animations?

- analyze paint/re-paint performance?

- view and debug delayed background actions?

- record and replay user flows?

...

^ Note the ellipsis again.

The build tools for Web are undoubtedly atrocious. However, there are very few, if any, tools that come even close to the versatility and ease of use of the tools that exist for the web ecosystem.

> So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation).

The linux kernel has KVM, doesn't get more out of the box than that. Do what you want with it. Emulate ARM? Sure why not.

> The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling".

Not my comment, I'm addressing your claim of "tooling most languages can't even dream of". The ellipsis doesn't really matter I'm not here to guess what you're meaning.

- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.

Most debuggers including GDB can print and set state.

> - examine and debug animations?

> - analyze paint/re-paint performance?

I don't do GUI development but you'll have to use a tool specific to the environment you're working with (just like how the DOM is a specific environment). What tool do you use to debug webview? Not your main browser. Systems development is the same.

> - view and debug delayed background actions?

You can get the time spent on anything down to individual assembly instructions if you wish.

> - record and replay user flows?

rr (which is GDB compliant hence integrates well with termdebug in vim).

I don't disagree that there are many tools for web dev. But they're not always better or easier to use. The built-in nodejs debugger is shit compared to GDB for example. My point is that everything you can do in browsers that aren't browser specific exists for other languages as well. Many times very specialized with better features that the devtools version.

Again, I love web development, but I also live in the terminal and love those tools even more. I wish they existed for the web.

Any language with repl can have it . Python for example

You make a good point, I’ve been saying for years that hot reload is too fast. Rust compile times really give you time to meditate and reflect.

What sane tooling are you talking about? FE projects takes minutes to build while backend projects can take hours.

Yeah, the closest I'd come is writing a server less endpoint in Rust or Cpp.

What compelling reason do you have for wanting another team to use Rust instead of JS?

It was just an exploration to see if there was anything we were missing out on.

That:

> It was just an exploration to see if there was anything we were missing out on.

Doesn't square with this:

> At some point though we'll probably just have to hire Rust engineers instead of trying to convert JS devs.

Reads like rust exceptionalism.

If we find that at some point we're missing out on something great with Rust/WASM then we'll hire Rust engineers and not just assume that our javascript developers can do it. That was the point.

Rust on wasm is the same story as .net on wasm (aka blazor): it is nice if you have a single language developer workforce. But once you maintain a portal team, the benefit is gone.

IMHO, the more interesting niche is desktop/mobile apps using html as a toolkit. Because here you can combine raw computing/resource access with being more cross platform.

> then Flow and TypeScript

Neither one is a different language. Both merely add type annotations to an otherwise pristine ECMAScript code base.

Typescript has some very few and minor and no longer needed things, like enums or namespaces, that need to be transpiled and are not part of ECMAScript. But again, those are minor and you no longer need them (since ES 2015 one can use modules instead of namespaces, and marked "as const" object literals instead of enums).

I know some people want to argue definitions, "different language" etc., but it's really just a completely optional tooling layer that you can just strip. It's also evaluated purely during development time, for type checks, the actual code that gets executed remains the ECMAScript part.

Whenever there are changes in a new Typescript version it's either purely within the type system, or they add type support for new ECMAScript features, those proposals that reached stage 3.

You could just imagine the type annotations in a different layer than the actual code, like in Photoshop. A layer used only by the IDE and code checking tools.

Microsoft added greatly to the confusion by putting the type checker, like eslint usable standalone or continuously queried through the IDE, and the type annotation files (.d.ts) generation and the completely optional .js file transformation AND .js file transpilation - backwards compatible JS code for earlier runtimes - into one tool. But all of those are different things. If your traget is "esnext" or you don't use JS features that your target runtime does not yet support transpilation is just removal of type annotations (except, enums, namespaces, which are no longer necessary and only exist for historical pre ES2015 reasons).

> Neither one is a different language. Both merely add type annotations to an otherwise pristine ECMAScript code base.

This isn’t really a matter of debate — Microsoft describes TypeScript as a programming language distinct from JavaScript on its homepage.

It’s a programming language with a trivial transpiration step to another language, but a separate language all the same.

You completely ignored everything I wrote and merely responded with an assertion, ignoring all evidence. What a terrible way to have a discussion. Would you kindly not ignore the facts?

Oh and here is what it ACTUALLY says on the Typescript page (https://www.typescriptlang.org/):

> TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.

None of that contradicts anything I wrote.

As a recovered Haskell enthusiast, a can say that typescript is downright luxurious to work with for web development in a way that I think is hard to compete with in rust, because of how it types objects (like composable / decomposable sets), and the generic language to work with types really complements JavaScript instead of forcing you to do things differently.

You forgot ClojureScript, ScalaJS, Elm. All were moderately successful in their own niche (Clojure or Scala dev shops).

This should be present tense, at least in the ClojureScript case.

Recent cool developments on that side include Electric Clojure - generating transparently state passing front and backend code from a single DSL: https://github.com/hyperfiddle/electric

Electric Clojure is insane, having a ton of fun playing with it.

I would have said only TypeScript has been successful, despite it being backed by Microsoft. ;) (I like MS, but just know many who don't.)

Microsoft is the only company that developed multiple successful languages. They know how to create languages for everything.

No one is even close.

I guess MSVC is the worst compiler out of spite that they didn't create C or C++.

Microsoft has this exceptional engineer on payroll

Anders Hejlsberg, lead architect of C# and creator of Delphi and Turbo Pascal, has worked on the development of TypeScript.

> This is not a dig at Rust (which I love) but God help any developer inheriting a frontend codebase with random bits of Rust in 2024.

Why? Rust has a bunch of features built in to promote "good code", no?

The problem is not "bad code", but experience from teams and community. Browsing HN might make we think that Rust is everywhere and everyone knows it, but most of the frontend developers in the world are not prepared to inherit a project in such a foreign language.

My theory is that, you probably can see when a language its being picked by some community by looking into courses available, either free or on paid platforms

Rust is a unmanaged language. 99% of use cases do not need it and 99% of devs are unable to handle it's.

> Rust is a unmanaged language.

Not quite sure what you mean. I've written some pretty cool stuff in Rust and never had to do any free() / drop()?

Most modern C++ code bases also completely lack explicit frees/deletes, but not many would argue that C++ is a managed language.

Though a more objective distinction is hard to give on what is a managed language, I found the garbage collection handbooks’ quote on the topic the most illuminating (linking to my older comment): https://news.ycombinator.com/item?id=35332600

In Rust and in C++ memory layout is part of your public APIs and has to be refactored when it changes. This is not the case with managed languages.

Reply on news.ycombinator.com