Hacker News new | past | comments | ask | show | jobs | submit login

I would love to do frontend web development but the current high-churn Javascript ecosystem makes me dizzy; this is probably a naive question but will it be possible to do web-development without integrating in the Javascript ecosystem using WebAssembly and Rust someday?



Eventually there will be direct binding between WebAssembly and web APIs like that the DOM that will allow you to write performant web apps that circumvent JS entirely. There are already tools that https://webassembly.studio/ that making writing wasm-based apps a reality, albeit still with a binding layer that goes through JS.

However, such applications will still have the same constraints that drive the current JS ecosystem. As such, there's little reason to believe that frameworks like React, Angular, Vue.js, etc. won't have their wasm-based equivalents. And, if anything, I except more churn for quite a few years, as people use the freedom provided by wasm to build a new generation of frameworks in completely different languages. We may look back on the current era of web development as a relatively stable one compared to what's to come.

So if the current churn is what turns you off web development, I wouldn't bet on wasm being a salve.


Another (non-Rust) but still interesting attempt towards this is being done by Microsoft:

https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-start...

In their case they compile a small enough subset of the .NET runtime to WebAssembly, and they got some JS to do the interop (I imagine till that glorious day of freedom comes). It's amazing what they've got working so far honestly.


Oh wow, I didn't realize that wasm did not currently have any direct bindings to the DOM. How does it interact with the page then? I saw a demo where they ported UE4 - how does something like that work without DOM access?


It calls to JavaScript which manipulates the DOM for it.


> I would love to do frontend web development but the current high-churn Javascript ecosystem makes me dizzy

Learn the actual web: HTML, CSS, and JavaScript are stable and don’t require any tooling in modern browsers. It’s pretty civilized these days with native support for ES6 classes, modules, arrow functions, data structures, spread & destructuring, fetch, async/await, etc. and things like CSS Grid for layout (head over to https://developer.mozilla.org for anything unfamiliar in that list). Support for non-current browsers can wait, hopefully until someone is paying you, and that’s a great time to learn about polyfills and transpilers.

The nice part about that is that it also plays great with WASM: you can write clean JS and call back and forth easily rather than trying to get dreadnaught-weight frameworks to work differently. I’m enjoying that right now since I see substantial gains swapping Rust-based hashing code to replace pure-JS alternatives.


Actually, if you addopt a mindset where you don't care about the ecosystem as much, you don't need to wait for rust-wasm to mature.

For example, a friend of mine just shipped a web-app for a client, that wanted something to help them organize local chemists conference between few universities. He wrote it in Elixir. Didn't actually use Javascript, because it doesn't need to be a single-page-app, right? :) Few froms, nice theme. Ok, maybe there was few lines of jquery, where absolutely necessary.

I remember once using Vaadin, just because I already know Java and didn't really care that nobody uses Vaadin anymore :D

Or, if you don't actually have client to solve a problem for, but want to try out a cool tech, I would suggest playing around with PureScript. Inspired by Haskell, compiles to JS, has nice ecosystem and many of the libraries don't have JS dependencies. Or maybe Elm, if you want something simmilar, but more focused/lightweight? :-) Claudia Doppioslash has a nice overview of both: https://www.youtube.com/watch?v=9kGoaUqcq4A


There already is, see https://github.com/DenisKolodin/yew for example.

The "put Rust in your JS" workflow is the first one the working group is focusing on; once that's awesome, other ones will get some work as well.


> I would love to do frontend web development but the current high-churn Javascript ecosystem makes me dizzy; this is probably a naive question but will it be possible to do web-development without integrating in the Javascript ecosystem using WebAssembly and Rust someday?

there are 2 different things, there is the DOM/Web API and the language, Javascript.

Nobody forces you to use anything from the JavaScript ecosystem, not even node.js, in order to use the DOM. This complexity is totally unnecessary.

I personally settled on Typescript, nothing more. Its compiler gives me Javascript WITH static typing, and converts my code to a version of JavaScript that will run on the majority of the browsers, even internet explorer 8/9 or old Android browsers. No need for React,Angular, Webpack, Babel and all that stuff...

As I'm not writing games or photoshop in the browser I see no need to use Rust,C,C++ and the SDL just to write web apps.

IMHO some people ultimately miss the true usefulness and use case for WASM: making existing C,C++,... libraries available to Javascript developers, not replacing JS with language X or Z.


I'm excited at the prospect of compiling TypeScript directly to wasm in the future (see for example [0]). Someday you may be able to recompile that TS project and get substantial gains for free.

[0] https://github.com/AssemblyScript/assemblyscript


We agree that that use-case is useful, and that’s exactly why we’re focusing on it. Augment, not replace.


You can also just write plain, vanilla javascript and make a working web app. I have one, no npm is involved! It is nice.


You can already do frontend development pretty well, by just relying on the technologies that have proven to be backward-compatible (for instance: the JavaScript language, HTML, CSS).


Maybe, but this post is to tell you that such use cases are explicitly not the focus of Rust and WebAssembly working group.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: