Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from TypeScript to Rust / WebAssembly

nicolodavis.com

Post reply on HN
Print view View original

301–310 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#301

Post by vorpalhex »

entha_saava wrote: post #141
aphextron wrote: post #67

Earlier quoted context omitted.

This really nails why languages like PHP and Ruby have won out over static typed, compiled ones for application level web development. The web is a massive collection of disjointed, loosely coupled APIs that all (just barely) interoperate to provide a massive array of functionality. Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you…

> This really nails why languages like PHP and Ruby have won out over static typed ... Real reason is lowering the bar of entry, and that explains why web is horribly broken. The "bootcamp webshit" meme exists for a reason. That's not gatekeeping - lowering the bar to entry below a certain level leads to drastic decrease in quality.

You realize the web started with just HTML at first right?

The web was always meant to be a platform anyone could easily build on, whether they were experts or someone's little old grandma who barely knew what a keyboard was.

Not only is it gatekeeping, it's historically wrong and betrays a flawed understanding of the platform. The web has always been about ease of use and there have always been people who went out of their way to teach others how to make good use of it.

Yes, the web is broken, but the web is broken because it's no longer about everyone running a little shoebox of a server and instead now we depend on giants who see us as cattle.

Re: Moving from TypeScript to Rust / WebAssembly

#302

Post by cs702 »

hardwaregeek wrote: post #29

Whenever I write Rust, I have a lot of fun, but I'm still not sold on it for most web dev. The analogy that comes to mind is that Rust is a really nice sports car with a great engine. It handles like a dream and you can feel the powerful engine humming while driving it. With the right open road, it's a great time. You can really optimize code, make great abstractions and work with data easily. Unfortunately, web dev…

> The analogy that comes to mind is that Rust is a really nice sports car with a great engine. It handles like a dream and you can feel the powerful engine humming while driving it. With the right open road, it's a great time. You can really optimize code, make great abstractions and work with data easily.

I prefer a different analogy:

Rust is high-end automated industrial equipment for machining high-precision metal parts that will fit perfectly with each other and which you can use to build anything you want, with high confidence that it will work and last a long time. But if you're under pressure to build lots of small, partially documented, constantly changing parts every day, you might be better off using more flexible equipment and materials (balsa wood, bailing wire, masking tape, etc.) to get the job done, even if the result will be messier and more prone to breaking.

Re: Moving from TypeScript to Rust / WebAssembly

#303

Post by azakai »

bluejekyll wrote: post #19
melling wrote: post #2

I don’t know Rust and haven’t done JavaScript for years but isn’t JavaScript a bit more of a higher level language, which would make a developer more productive? Rust being closer to the hardware should require more code, and effort, to accomplish the same task.

This is complicated. I’m no expert with WASM, but I’m fairly familiar with Rust and have toyed around with Rust and WASM. With Rust and WASM you pay an expense of FFI between the languages. There are tools that minimize this, but there’s still a cost. Transferring data is limited to very primitive data types today, which adds a cost to translation between Rust and JS. I expect this to reduce in cost as WASM gains abi…

This is an important point.

Languages compiled to wasm have an FFI cost, and we will never fully remove it because it just uses different types than Web APIs do. This isn't a Rust problem or a C problem, it's just how wasm is.

Wasm also can't use the JS standard library, and usually ends up shipping some runtime support, like malloc or string handling, which increases download size.

Both of those limitations are why wasm won't make sense for the great majority of web dev work. But wasm shines for "engine" type code, like in this post - pure computation, without lots of links to the outside JS/DOM world.

Re: Moving from TypeScript to Rust / WebAssembly

#304

Post by nicolodavis »

Asooka wrote: post #299

One thing articles like this always miss, and what I'm most keen on, is how exactly the bridging works. Is there a standard Rust wasm crate that exposes the DOM? Do you pass some struct with function pointers? Is the Rust code exposed as a black box with no connection to the outside world and you just call a few entrypoint functions? Can you call Rust from JS and JS from Rust? If you go JS->Rust->JS->Rust->JS and the…

The Rollup plugin linked to in the article produces JS functions that call into WASM code. JS objects are automatically converted to Rust structs via Serde and vice-versa.

I use TypeScript / Svelte for DOM interactions and only call into Rust code for the state updates (treating it like a black box).

Re: Moving from TypeScript to Rust / WebAssembly

#305

Post by XCSme »

heavyset_go wrote: post #184
blub wrote: post #100

Earlier quoted context omitted.

Most things thank goodness are not SPAs, nor do they have to be. The problem here is the concept of SPA itself - it's a complete hack which is plastered over with various tricks to make it halfway usable. This has been going on for years now. Websites on the other hand are slow because of the tracking and the ads which load tons of JS. Remove that and the web will be blazing fast.

> Remove that and the web will be blazing fast. With sufficient ad blocking and JS white listing, I can attest to this. After removing ads and analytics, sites that rely on JavaScript to render significant amounts of content are the slowest.

If you have A LOT of content (eg. a table with 10000 rows containing rich data) it will be faster to use a JS virtualized list than to just have all those 100k+ DOM elements computed at once.

Re: Moving from TypeScript to Rust / WebAssembly

#306

Post by steveklabnik »

Asooka wrote: post #299

One thing articles like this always miss, and what I'm most keen on, is how exactly the bridging works. Is there a standard Rust wasm crate that exposes the DOM? Do you pass some struct with function pointers? Is the Rust code exposed as a black box with no connection to the outside world and you just call a few entrypoint functions? Can you call Rust from JS and JS from Rust? If you go JS->Rust->JS->Rust->JS and the…

There are two low-level bridges: js-sys provides bindings to all the ECMAScript stuff, and web-sys provides bindings to all of the rest of a browser environment, including the DOM.

> Can you call Rust from JS and JS from Rust?

Yes.

I personally have written some JS code that returns a promise, wrapped in wasm that turned it into a Rust Future, then converted that Future into a promise that I've returned to Javascript.

> If you go JS->Rust->JS->Rust->JS and the innermost JS function throws an exception, is all that properly propagated up the stack?

Sort of. Rust doesn't use exceptions, but the binding converts a JavaScript exception to a Rust "result" type and vice versa at the boundary, so if you propogate it, it will get properly propagated.

Re: Moving from TypeScript to Rust / WebAssembly

#307

Post by ed25519FUUU »

zaphar wrote: post #269
The_rationalist wrote: post #212

Earlier quoted context omitted.

The dilemma: boilerplate vs dynamic languages is a thing of the past. Kotlin make code even clearer than in java while being the sexiest syntax out there. It's 100% compatible with your Java code so you can incrementally migrate starting now!

The dilemma was always a false choice. You don't need kotlin to get rid of your boilerplate. Java is just a capable of being concise as any other language. Java's verbosity is a cultural artifact not a technical one.

Don’t get me wrong. I use java every day and quite enjoy it, but when I compare it to writing in Go or Kotlin, java does sometimes feel a little like meta programming. Especially if it’s a spring app, which is quite common.

Re: Moving from TypeScript to Rust / WebAssembly

#309

Post by nicolodavis »

maerF0x0 wrote: post #308

@nicolodavis I would love to hear your thoughts and reasoning for not using go + wasm compile target? Not as a critique but to understand your point of view.

No reason except that I've written Go in the past and wanted to learn a new language :)

Comparing the two languages, I would say that Rust's enums and pattern matching make it easier to work with for my specific use case.

Re: Moving from TypeScript to Rust / WebAssembly

#310

Post by XCSme »

nicolodavis wrote: post #99
amitport wrote: post #98

Hi Nicolo, Here are my two (or more) cents: 1 - Javascript is fast enough for your use case. No one will notice the difference in a board game website. 2 - AI should probably be implemented in python anyway. As ugly as python can be, you shouldn't fight the world; there are too many free advanced AI algo implementations in python out there. 3 - Regarding "Limitations of TypeScript" (strict typing / data validation /…

Hey Amit, good to hear from you! > Javascript is fast enough for your use case. No one will notice the difference in a board game website. No, actually. Have you seen how long boardgame.io's MCTS bot takes to make a Tic-Tac-Toe move? Not the end of the world, but certainly in need of improvement.

I don't know about JS being slow, while working on https://curvefever.pro it was not too hard to make the game run at 4k, 60FPS for a 6 player multi-player game that renders dynamic geometry with collisions which changes multiple times per tick.

JS is pretty fast if you use TypedArrays, are careful with WebGL calls and pool objects (reduce memory allocations).

Post reply on HN