
Single Page Applications using Rust - rkwz
http://www.sheshbabu.com/posts/rust-wasm-yew-single-page-application/
======
bob1029
From the article:

> Building UIs by composing components and passing data in a unidirectional
> way is a paradigm shift in the frontend world. It’s a huge improvement in
> the way we reason about UI and it’s very hard to go back to imperative DOM
> manipulation once you get used to this.

IMO, UI structure and state management of the UI are orthogonal concerns.
Trying to make these part of the same problem - a 'Component' \- is how you
wind up in the Angular-style trap where you can never quite cover 100% of the
use cases, so you have to keep adding new leaky abstractions to compensate for
prior ones. Passing events back up the chain is a particularly egregious
constraint when you are trying to do things with the UI that the modeling does
not agree with on paper (i.e. modals, status bars and nav menus are children
of whom? One big global component?).

I have made this realization recently when working with Blazor. The
statefulness of a UI is a completely different thing from the visual
presentation of the UI. We do one-way binding into UI (e.g. foreach over
collections to build table rows). But, stateful concerns are injected as
scoped services (i.e. per user session/request). UI events are passed into the
state service methods directly, and the UI is redrawn on top of the updated
state. Each state service can only be mutated by way of one of its public
methods.

This approach allows for us to build & test our UI state machines to
deterministic levels of correctness without a single line of HTML/JS/CSS or
manual user testing being involved. Once we have the state machine figured
out, we can build whatever arbitrary UI we want on top of it.

~~~
nicoburns
Have you used React? It also uses a "Component" approach, but it doesn't
suffer from the same abstraction issues as Angular. Your approach seems
basically equivalent to the "redux" approach except with an OO flavour rather
than a functional one.

Personally I've found a mix of "component state" for things like UI state
(e.g. is that modal open? is that checkbox checked?) and "external state" for
actual product data (e.g. array of users) works pretty well.

~~~
bob1029
I have not played around in the React space at all. I do agree that what you
describe sounds similar to my ideology. The part that I would disagree with is
the coupling of _any_ state with a UI component.

What happens if you want to move the confirmation checkbox from the modal back
to the main view? Do you have to edit 2 state machines or 1?

~~~
nwienert
I’d go further in pushing back and actually say I think the single global
state store (or stores) like redux and others are an anti-pattern.

You actually do want your state to live inside components. The examples are
numerous, but it basically all comes down to composability.

Here’s a recent example:

You build a nice “autocomplete” for your site. In redux, you’d have it all in
some namespace perhaps. But now you realize you need a second autocomplete
somewhere. What do you do?

In the component model, you’d have already written the state such that there’s
an “autocomplete state managing component” that accepts the right props to
initiate it. Adding the next autocomplete widget now is as trivial as adding a
component. But in the global/redux model, you would be far more likely/prone
to not only couple the initial props and logic to the initial data, but you
may not even have designed any aspect of it to be composable because you never
considered it to be independent. How do you extract your autocomplete and
publish it for other teams to use? It’s not possible, unless you do a lot of
work and force them to use redux as well.

This may sound overly architected, but in fact it’s less so in the React
world. Redux is the additional dependency, and additional and different layer
of logic. Keeping within the component model is simpler and grows and composes
more easily. Especially once you get into things like parent/child components
that want to share state specifically for that sub-tree.

My take here is global stores are a bad solution for UI where the goal is
tree-specific composability and generally building flexibly re-usable lego
blocks is the goal. Redux is an anti-pattern that is simpler initially but
encourages bad patterns, calcifies your stack, and ultimately slows you down
as the app grows.

~~~
nicoburns
Agreed. But redux is useful for some things like data on the currently logged
in user, or the state of feature flags. These are bits of data that you may
well need all over the place, and pulling them in from redux is easier than
threading them through components as props.

~~~
viklove
Redux works through a first-class React feature -- the context api. You can
utilize the context api yourself to create modular state wrappers that can
exist side-by-side rather than being restricted to a single global store.

[https://reactjs.org/docs/context.html](https://reactjs.org/docs/context.html)

~~~
nwienert
At that point you now have the downside of writing reducers (verbose,
unintuitive) and the dependency on a large library with a lot of customization
to get it even close to syntax you'd prefer.

Namespacing doesn't solve what I'm talking about here completely, you'd still
be writing state away from the components that use it and in a reducer form,
plus there are numerous pitfalls to doing this in redux (you'd end up with a
whole toolkit of addons to get it to be what you want).

I'd recommend looking at something like zustand or recoil, both which are
headed in the direction we should be at. There are others, check out dai-shi's
work on a few different state systems (use-atom looks decent).

------
sharpercoder
The promise of Rust is safe and fast low-level development. What is the
primary selling point of using rust for webdev? Speed? I can mainly see
disadvantages when using rust for this scenario.

~~~
gavinray
> Speed?

As surprising as it might sound -- not really. There's a small-but-non-trivial
amount of overhead involved in calls between WASM code and the DOM API's, plus
(de)serialization.

It's more of a familiarity/existing tooling thing. Same as Blazor in C#
writing web apps in that. If your entire team only knows C# and you have all
your existing tooling there then it could seem an appealing option.

But there's also the argument for more stringent safety with Rust compared to
IE, Typescript.

~~~
paulgb
This is true if you are writing code that has a lot of UI interaction, but one
sweet spot for WASM I've found is if you just want to do a bunch of
computation on the client and surface it. For example, I wrote a SPA for
generating crossword puzzles[1]. Maybe I'm wrong, but I don't think I would
have been able to get the same performance in JS even with modern
optimization.

1\. [https://crossword.paulbutler.org/](https://crossword.paulbutler.org/)

~~~
jlbnjmn
That's really cool, thanks for sharing it. It found a 16x16 with a lot of
complexity incredibly fast!

------
nilkn
I am hopeful that Rust can achieve what Elm did not.

I really fell in love with Elm early on, back when it was an experimental
language for functional reactive programming that just happened to compile to
JavaScript. It was an outgrowth of failed experiments in FRP from the Haskell
world. I thought it got so many things right -- and it totally did. But then,
just as soon as it started gaining real traction, development on Elm went
silent and became siloed, staggeringly slow, locked-down, and unresponsive to
users. I understand why this happened and I don't even hold it against the Elm
team, but it certainly stunted the language's growth and adoption.

Rust has a much more expressive type system than Elm. The Rust world is much
more open, responsive, and caring about user concerns. Rust isn't afraid to
offer unsafe escape hatches even if they're not pretty or elegant. With Rust
you have the added advantage of being able to use the language for the entire
stack, both front- and back-end. That's especially compelling because Rust is
on its way to being one of the strongest languages for back-end development
due to its combination of type safety, expressiveness, and performance.

~~~
nickbauman
Clojure has been there as a fullstack language for a lot longer. It also
fulfills the story that Elm was trying to do for much longer. And Reagent is a
much needed improvement on React.

The borrow-checker in Rust is kind of silly tool to use in the context of a
managed language (that does GC) like Javascript. I don't get it. It's like
using a backhoe to plant a few geraniums. Am I just not getting this?

~~~
Scarbutt
Clojure is nice for heavy data engineering projects that require
robust/stable/mature tech like the JVM. But for a full stack language for a
web app it just adds a tons of complexity over just using JS.

In Clojurescript interacting with the JS ecosystem is painful cause of its
reliance on the closure compiler.

In Clojure, is almost the same, most Java libs are over-engineered and
horrible to use but you need to reach for them because Clojure lacks an
ecosystem.

So while Clojure is a better/nicer language than JS, the tradeoffs are not
worth it if you want only one language for your webapp (SPA and server).

~~~
pjmlp
What you see as negatives, I see as Clojure's main selling points.

I usually avoid languages that keep reinventing the wheel of established
libraries on the platform, "'cause it isn't idiomatic".

~~~
Scarbutt
Don't disagree with you but two things:

1\. Clojure doesn't have as good interop as Kotlin.

2\. For some heavy interop projects, it's simpler to write the thing Java.

~~~
pjmlp
What good interop does Kotlin have better than Clojure in what concerns
calling Java code?

And on the other direction is just as fun, try to call Kotlin co-routines from
Java without having to write wrappers for it, or Kotlin code without putting
@Jvm... annotations everywhere.

------
kibwen
I like how this post uses diffs to demonstrate how the code changes at each
step, it's much easier to follow along than with blog posts that just show the
complete code at each step and leave mental diffing as an exercise for the
reader.

~~~
lioeters
Dug in the source, I believe they're using Prism's Diff Highlight plugin:

[https://prismjs.com/plugins/diff-
highlight/](https://prismjs.com/plugins/diff-highlight/)

------
vlucas
It's worth noting that the WASM package takes up 476kb shipped and the wasm.js
loader is another ~25kb. So this bare-bones site is already sitting at > 500kb
of JavaScript shipped to the client.

I am glad to see things like this are possible now with WASM, but there is a
lot of room for improvement here that I hope gets captured by browser vendors
over time.

~~~
dstaley
Just to clarify, 476kb of WebAssembly != 476kb of JavaScript. Still, your
point stands in that wasm-based sites will likely never beat their pure
JavaScript counterparts in terms of data transfer; you'll need to make up the
increased cost of wasm somewhere else. One place that browsers attempt to make
up the difference is in the use of streaming compilers, where the browser can
start compiling wasm as it's coming in from the network, whereas with
JavaScript browsers have to wait until the entire resource is delivered before
the parsing stage can begin.

~~~
chrismorgan
To expound on this difference: 476KB of WebAssembly loads like 476KB of images
(that is, super fast) rather than like 476KB of JavaScript (which is pretty
slow and blocks the main thread). [https://hacks.mozilla.org/2018/01/making-
webassembly-even-fa...](https://hacks.mozilla.org/2018/01/making-webassembly-
even-faster-firefoxs-new-streaming-and-tiering-compiler/) explains more.

------
pedrocr
We're finally getting back to this point where you can choose whatever
language you want to program for the web. It only took us 15 years of being
flamed every time you pointed out you didn't like Javascript but were forced
to use it to be part of the modern web. One of the motivations for Viaweb was
being able to do Lisp, hopefully this gets the web back to that mindset of
only the behavior mattering and whatever language you want to use go for it.

~~~
root_axis
It's ironic because this is only possible due to the continued development of
sophisticated web tooling, which is the biggest complaint made by people who
complain about the state of web development.

~~~
learc83
People complaining about that are generally talking about the churn in front
end web frameworks and JavaScript development in general.

None of that eas necessary for WebAssembly to be developed. Unless you mean
that the annoyance of the constantly changing JS ecosystem motivated people to
push for it.

~~~
root_axis
Nobody wants to hand-write wasm, you need a tooling pipeline to make that type
of development workflow practical, its not any different from babel or
typescript in this respect; using rust instead of js is "churn" just as much
as any of the other options available for building web pages that you don't
have to use.

~~~
learc83
>Nobody wants to hand-write wasm, you need a tooling pipeline to make that
type of development workflow practical,

Yes and nothing about the Babel or typescript or node was required for the
creation of wasm or a wasm compiler.

People complain about churn in the JS ecosystem because of the rate that
frameworks and tooling rise and then fall out of favor.

I don't see the irony at all in people complaining about one ecosystem while
being excited that they are being given a way to bypass that ecosystem all
together.

~~~
root_axis
> _People complain about churn in the JS ecosystem because of the rate that
> frameworks and tooling rise and then fall out of favor._

And building web pages with rust is just another example of this phenomenon,
its ironic because somehow its viewed as a positive thing by people who
commonly complain about the introduction of new tools into web development
ecosystem, but the power of rust hype somehow obscures the fact that this is
exactly the same thing such detractors always complain about.

For the record, I love rust and wasm and think this is great, but I have
always been opposed to the framing that people creating new web development
tools is a bad thing.

~~~
danShumway
Agreed. I'm also completely onboard with what Rust is doing here. Language
choice is fantastic, I think opening up the web to multiple programming
languages is going to be very good for the web as an ecosystem.

But at the same time --

To all the people complaining that modern web browsers are too complicated for
small teams to build and maintain, do you think WASM helped with that at all?

To all the people complaining that Javascript's lack of an extensive standard
library makes it hard to quickly read/grok other people's code on Github, do
you think that situation is going to get any better when people are using
entirely separate _languages_ to program the same webapps?

To all the people complaining that there are too many frameworks and tools
being released for the web to keep up with, do you think that's going to get
any better when suddenly every programmer and their dog can start porting any
Open Source UI toolkit/framework to the web with low-cost DOM bindings?

~~~
Risord
> To all the people complaining that modern web browsers are too complicated
> for small teams to build and maintain, do you think WASM helped with that at
> all?

Kind of yes.

For simple browser as a general application platform you need a simple base
technology where much can be shipped as library level. It would be fun to see
WASM only browser with JS and CSS layouting solutions run as WASM compiled
libraries.

So in theory WASM could be used as a first step to more simple browser but in
practise it's propably just a fantasy.

------
fmakunbound
I'll do just about anything to avoid JavaScript, including learning Rust.

~~~
nobleach
While I do get annoyed at JS often, I get just as annoyed by Rust. Sometimes,
I really just want to read a CSV and create a Map<String, String> from a few
of the columns. But oh my god if Rust doesn't make that a nightmare. Is it a
String? an &str? Do I want to allocate that string on the stack? I won't know
the size of it at compile time, so of course not... right? So no to 'static?
Give me a nice middle of the road like TypeScript, Kotlin, OCaml/Reason...
Rust just goes SO FAR in the other direction that I don't find it a pleasant
experience. I get that it's the ULTIMATE in performance, I just always
question if I really need it for doing web work.

~~~
Yxven
I think this Rust complaint is just inexperience.

You wanted a Map<String, String>, and that's exactly what you should have
made. A String is a convenience wrapper for storing a &str on the heap, so
storing a String on the heap is redundant. The other options are for
performance concerns, which you haven't mentioned any.

~~~
eloff
Now make it a global thread safe hash map where the keys are references into a
mutable memory map that can move it's address (be remapped.) That's currently
where rust is making my life miserable today. In C++ this is quite
straightforward, albiet full of footguns.

Every time I need a static mutable thread safe map in rust for a cache or
registry or some such thing, I groan.

I have a love hate relationship with rust. I love a lot of things about it,
but sometimes I get so fed up with the borrow checker I drop into unsafe and
just write the problem off as something better not done safely.

~~~
Ankhers
Maybe I am misunderstanding your needs, but could you not just use a
RwLock[0]? For being global you will need to use the lazy_static[1] crate.
Admittedly, I have not tried doing this directly though.

[0] [https://doc.rust-lang.org/std/sync/struct.RwLock.html](https://doc.rust-
lang.org/std/sync/struct.RwLock.html) [1]
[https://crates.io/crates/lazy_static](https://crates.io/crates/lazy_static)

~~~
eloff
That's part of the solution I'm working towards.

I'm using 'static references for the map keys, but they're not really 'static,
so I use unsafe transmute to create them and I rebuild the map when the memory
map changes to a different address.

------
praveenperera
Great post.

I'd love to see one talking about building a full stack app using Yew and
Actix (or Rocket). And good ways of sharing types between the frontend and the
backend.

~~~
areille
You should have a look to this project built with actix, diesel and yew:

[https://github.com/saschagrunert/webapp.rs](https://github.com/saschagrunert/webapp.rs)

~~~
praveenperera
This is great. Thank you!

------
nojvek
Until we fix the wasm->dom bridge to be just as fast as the js->dom bridge, js
will still have a leg up.

AFAIK the hard bits are in bindgen which makes js structs look like wasm ones
and vice versa.

I’ve been doing frontend for over a decade and quite bullish on wasm once that
boundary isn’t so expensive.

It should be possible to make super performant apps with wasm. Figma sticks
out to me as someone really pushing the edge.

------
gwbas1c
I'm still baffled by the need for a boilerplate Javascript file to call into
rust. Why can't I just include the wasm directly from HTML?

Seems like someone's feelings will be hurt when they realize that many
developers want to skip JavaScript and just work with wasm.

~~~
steveklabnik
The browser API requires it.

~~~
gwbas1c
It's just two lines of JavaScript to call into wasm: 1 line to load the wasm,
another to call a function in it.

This adds latency, and is easily replaced by a single tag.

------
ori_b
This is a big reason that I think wasm is a step in the wrong direction. It's
basically nudging people into making things even more opaque.

How, for example, would you go about blocking ads in this kind of app?

~~~
jelder
If it’s actually harder to block ads in apps built like this, that’s a great
reason for site owners to choose wasm.

~~~
AnyTimeTraveler
You can still use normal adblockers with this. Most of them just have a
blacklist of domains that they block the requests for. Wasm won't change
anything about that.

The requests are still exactly the same as in JS, so blocking will work
exactly the same.

------
AlchemistCamp
I've been going through _Programming WebAssembly with Rust_ , from Pragmatic
Bookshelf and have been getting interested in the possibilities. Yew is just
one part of the book, but it's a good crash course and motivation for digging
in.

[https://pragprog.com/titles/khrust/](https://pragprog.com/titles/khrust/)

------
kuon
I was thinking of a project I wanted to start, but I don't know if it would
interest anyone.

Basically, I'd like to try to build all sort of app with program components
similar to the Elm architecture (init, update, step, subscribe).

Those programs would be a bit similar to objects in OO except with stricter
rules.

I did a proof of concept and it works very well for simple tasks (like
subscribing to HttpServer.sub and getting messages for requests to your update
function). The good side is that you can have very simple API (I'd really like
it to be usable by anyone), it's very easy to go massive multi-threading,
refactoring is easy, you never introduce hard dependency in your code and
having a very strict model helps organizing code.

I wanted to support wasm with a subset of the API (that's why I think of it
now).

But I stopped, because I realized it would certainly be of little interest
except for show.

------
devxpy
Can anyone please tell me how the author able to use html syntax in rust?

I get that there are macros, but how are html tags valid syntax? Is rust just
interpreting the html content as strings?

I've only ever seen C macros, and I don't remember seeing this kind of
wizardry happening there.

~~~
Ciantic
It's using this:
[https://yew.rs/docs/concepts/html](https://yew.rs/docs/concepts/html) and no,
just like JSX, it's not HTML strings. It's building HTML-like AST in macro.

One great thing about JSX (and Yew) is that it's way more secure way to build
an HTML, because you don't need to worry about escaping behaviors as much.
(Sometimes you still need, like injecting inline CSS etc. but not that often)

~~~
devxpy
whoa, so you can write like a DSL parser using the rust macro matcher syntax?

~~~
dgb23
Essentially yes. Macros in Rust are very powerful, similar to Lisp macros
(although they are naturally clunkier).

As you would expect, you will find macros for HTML, JSON etc. in libraries,
but there are also quite a bunch of smaller, frequent macros that simply
reduce common boilerplate.

~~~
db48x
And then there are the Rust macros that let you write code in Lisp syntax,
although I don't recall that any of them had a defmacro form…

~~~
devxpy
Oh god, what have I seen

~~~
db48x
I'm sorry; I should have thought about the more sensitive readers.

------
apiudit
Hate to be that guy but with a such small SPA I was expecting a better file
size, 136KB compressed with brotli 487KB uncompressed.

Being said that score in Page Speed Insights is pretty good (95).

Will be interesting how size increases with bigger/complex apps.

~~~
ChrisSD
I wouldn't assume the growth in binary size is anything like linear with code
size (i.e. there's probably a lot of fixed overhead). And they appear to be
using the "\--dev" compiler profile, which is unoptimized and meant for
debugging.

------
boltzmann_
waiting for a rails like framework that would let me use only one language
full-stack.

~~~
whb07
F# does this via Fable.

~~~
dmit
This is a tangent, but does Fable still require you to manually toposort your
module hierarchy in an XML file? That was my experience using the language
with VS Code circa a year ago.

~~~
whb07
I've actually not been an actual user besides running a random repo to see how
it all fits in nicely. But... i've been playing more with F# and it really is
a fun language to use and capable.

I was able to compile a number of F# applications to "native" or as close as
possible and they ended up getting significant performance improvements.

For instance a ray tracing application when compiled to native had
improvements of 50%.

------
tristanMatthias
Am I the only one that finds this REALLY verbose for doing some really simple
stuff?

Forewarning, I'm a JS dev trying to get out of the "JS" box. I'm super
interested in WASM for a lot of reasons (running ML models on the client in
python, etc).

This syntax (and maybe it's just Yew) feels like it has SO much boilerplate.
For you seasoned rustacians out there, is this something that could be
reduced? It feels overkill for me. But then again, maybe I'm a spoiled JS dev
with the wrong expectations.

Really curious to answers on this.

~~~
steveklabnik
It's hard to say without knowing what specifically you find to be verbose.
"verbose" is a very subjective measure.

------
jandrese
I remember back when people generated html with native code using CGI.pm and
it was considered a bad idea. Don't mix languages they said. The current
CGI.pm deprecated all of the HTML generating parts in fact.

The official justification:

    
    
      The rationale for this is that the HTML generation functions of CGI.pm are an obfuscation at best and a maintenance nightmare at worst. You should be using a template engine for better separation of concerns. See CGI::Alternatives for an example of using CGI.pm with the Template::Toolkit module.

------
pier25
Can you load WASM modules dynamically like we in do in JS with import()?

~~~
steveklabnik
In some sense, that's the only thing you can do in the browser, as you have to
execute JS to instantiate the wasm.

The code in this post actually uses import to dynamically import said JS that
imports the wasm.

~~~
pier25
Right, I guess the tooling would need to support code splitting into separated
wasm modules like we do with Webpack or Rollup.

------
batt4good
Frameworks like this and other similar non-standard approaches like Elixir
Phoenix and LiveView are awesome, however, I'm still lost as to how one should
go about styling and / or dynamically structuring styling?

Does anyone have recommendations for guides or simple approaches that only
focus on the pure UI side of the problem. I've never really "had" to learn JS
and honestly every time I have to dip my toes in it leaves a very bad taste in
my mouth.

------
deschutes
What is the size of the served wasm binaries?

~~~
M2Ys4U
Looking at the linked demo site[0] the wasm file is 476kb (133kb compressed
with brotli).

[0] [https://rustmart-yew.netlify.app/](https://rustmart-yew.netlify.app/)

------
doomedlung
What are the debugging tools like for this?

------
kissgyorgy
You build your website in Rust, I build 3 websites in that same time with
Python/JavaScript.

~~~
ioseph
In which time I build 30 websites using wordpress. Heaven forbid the author
does something for any reason other than productivity gains

------
raggi
136kb feels heavy for what this is

~~~
kinghajj
A lot of that comes from a few large libraries needed to provide base runtime
functions (like memory allocation).

------
bodhi_mind
Anyone know when all browsers will support 64bit wasm and allow >4gb memory?

------
BooneJS
Is blocking WASM a thing yet? I guess I wouldn’t know if I’ve launched a WASM
page, but I was curious if WASM was popular enough for IT security folks to
block on enterprise computers.

~~~
bob1029
Not to my knowledge. I don't see any reason for it to be blocked, even in
theory. It's not like you get access to a more permissive API surface or
anything. If someone is going to feed you malicious code to execute, all WASM
will do is make it harder to inspect.

------
merrvk
Cannot wait for the days where i no longer have to write JS

------
intelleak
I've been hearing good things about zig, and someone mentioned that zig has
better wasm support than rust, is it true? I wish rust had a js ecosystem too
...

------
truly_furqan
That's interesting. But, IMO it has a lot of room for improvement to compete
with frameworks like React, Vue, and Svelte.

Isn't it?

------
rriepe
Thanks for this. I was wanting to look into this, and this page is way more
than enough to get me started.

------
johannes1234321
Sorry for being the pedantic one, but the article early on states "without
writing a single line of JavaScript" and then, in the first code, after
showing configuration files, one can read

    
    
        <script type="module">
          import init from "/wasm.js";
          init();
        </script>
    

So two lines of JavaScript ...

~~~
arkanciscan
And some HTML as well. Yew seems to use a JSX-like template language, but it's
got to hit the DOM eventually. Then you're gonna need to handle Events and
style with CSS. How do you handle errors? What does all this look like in
DevTools? People act like JS is the worst part of web development which is
simply naive.

~~~
johannes1234321
About HTML they made no claims. For a SPA HTML also is essential (they could
use GL if they don't want to use (lots of) HTML)

And errors and events are handled in the Rust code.

------
svnpenn
> without writing a single line of JavaScript

Looks like 680 lines to me:

[https://rustmart-yew.netlify.app/wasm.js](https://rustmart-
yew.netlify.app/wasm.js)

~~~
steveklabnik
You do not write that JavaScript, it is generated for you by the tooling.

~~~
svnpenn
If the end solution relies on hundreds of lines of JavaScript... its
JavaScript. I will just write the whole thing in JavaScript instead of messing
with something like this.

~~~
steveklabnik
Sure, and you are very welcome to do so. That's not what the original post
said, nor what you said in response, though.

------
tus88
Whats the point. Javascrupt cannot have memory errors and has no threading, so
why bother with a memory safe language like Rust?

~~~
M2Ys4U
Well for one Rust has a very nice type system

------
millstone
The wasm on this page is 476 KB.

------
1vuio0pswjnm7
I was hoping "single page" meant all the code fit on one page.

------
hpen
Why create web apps in Rust? Won't that slow down development?

~~~
pettusftw
Depends who the developers are. My company has been acquired several times
over the past decade and it has been for our backend. The frontend has been
largely left to rot and is a seldom used nightmare at this point. Our backend
devs that use Rust may be asked to build a simple SPA for a client relatively
soon, so you can understand why they _may_ be happy to give this a try for the
POC. My initial impression is that it would require a lot less KT/overhead to
at least give them this option before shuffling another team in that really
doesn't have the roadmap bandwidth to begin with.

~~~
hpen
Fair point. I just don't know that right now at the beginning will be a good
time. A solid ecosystem can make all the difference.

------
arkanciscan
I eagerly await every single NPM package being rewritten in every single
language just so someone can post a ShowHN about it.

~~~
runawaybottle
It’s demo day everyday like kindergarten.

------
joshsyn
zero overhead on the web or just zero and overkill for the web?

Seriously I don't get the appeal of doing frontend in Rust? Isomorphic you
say, thought Json solved that problem? Hell, I'd rather choose typescript
even.

------
Naac
So as I understand it Rust is compelling because it is a safer alternative to
C++ ( and sometimes C but mainly a C++ replacement ).

We wouldn't usually create a single page app in C++ right? So why would we
want to do that in Rust ( other than, "just because" ). Right tool for the
right job and all that.

~~~
K0nserv
Rust is much more like Ruby than C++ while retaining the characteristics of
C++/C. The build system and ecosystem is also excellent, something that you
cannot say for C++.

In terms of WASM Rust and C++/C are in the same boat i.e. the few languages
you can realistically use because they don't require a heavy runtime or GC.

------
crazypython
Full-stack Dlang framework [https://github.com/huntlabs/hunt-
framework](https://github.com/huntlabs/hunt-framework)

~~~
NationalPark
No wasm stuff here though.

------
austincheney
I have never understood why people find UI challenging, aside from
accessibility and security.

State management is ridiculously easy. So easy that you are going to 10x
greater effort reading your favorite framework’s API.

To manage state store your state criteria in a central object. Save that to
storage somewhere, such as localStorage. To restore state read the stored
state object and apply each item to its respective area of the application.

Modules and components are ridiculously easy now too thanks to ECMAScript
modules.

