[HN Gopher] Seed - A Rust front-end framework for creating fast ...
___________________________________________________________________
Seed - A Rust front-end framework for creating fast and reliable
web apps
Author : ibraheemdev
Score : 194 points
Date : 2021-09-17 16:50 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| option_greek wrote:
| Is there a way to use standard frameworks like bootstrap with
| this or other similar wasm based rust frontends? Otherwise, it's
| hard to see how it will ever have enough rich components to
| really take off.
| dureuill wrote:
| I had some luck with yew + bulma.io. There's a crate called ybc
| they implements yew components using bulma classes. I had to
| reimplement a component myself though because I needed to hoist
| its state. Doing so wasn't very complicated.
| zackoverflow wrote:
| I have seen a few of these Rust front-end projects, they are all
| really great except for the fact that very few support SSR. This
| is especially important given the fact that it is much slower
| sending wasm over the wire and instantiating the module and the
| wasm environment vs plain js
|
| I'm not sure if this is because of the complexity of the
| undertaking (I imagine it would need some sort of virtual DOM) or
| just lack of interest
| brundolf wrote:
| What makes you think sending WASM over the wire is slower? The
| payloads should be smaller than JS, assuming you aren't
| shipping a runtime alongside your code (which Rust doesn't). I
| don't know about the bootstrapping side, but I know some people
| use WASM specifically for the small bundle sizes.
| rictic wrote:
| The Rust compiler and ecosystem are tuned more towards
| generating faster code rather than generating smaller code.
| In my experience, even small wasm apps that are careful about
| their dependencies end up shipping hundreds of KB of wasm
| over the wire, and if you're not as careful that easily tips
| over to MBs.
|
| Time and space are in tension, and the web is more sensitive
| to binary size than most other targets, including many
| embedded targets.
|
| To take one example that often contributes a ton to binary
| size, consider data serialization in Rust vs JS. JS will tend
| to just use JSON.parse and deserialize into a JS object with
| little to no data validation. The JS object is then
| exclusively accessed via dynamic field lookup (with a JIT
| doing its best to notice patterns and hopefully optimize the
| hot paths). The same code paths can handle many different
| message shapes. It's far from optimal in terms of runtime
| speed, but the code can be made very compact.
|
| Rust deserializers by contrast seem to use compiler-time code
| generation to produce a different optimized struct layout,
| parser, and validator for every message type. When I've
| played with writing very small Rust + wasm apps, the choice
| of serialization library and format made a huge difference.
| If I recall correctly, using BSON + serde would have
| increased my total binary size by more than 3x.
|
| This isn't a fundamental issue with Rust as a language, I
| think it's partly still early days for the tooling.
|
| There is, however a certain fundamental amount of tension
| there in what's optimized for. In most environments, 30%
| faster deserialization for a binary that's 500KB larger
| (pulling numbers out of my ass) is in the "obviously yes, do
| that" category, but on the web adding 500KB to your binary is
| a steep price to pay, particularly for mobile users.
| zackoverflow wrote:
| thanks for the correction, was formulating the sentence and
| somehow "wasm over the wire" injected itself in there. 100%
| transfering wasm in the binary format is a more efficient
| transfer than js.
| ironmagma wrote:
| I have been working on a virtual DOM library which will enable
| a few of these projects to support SSR. But, partly due to lack
| of interest, and partly due to lack of time on my part, it's
| been going slower lately. Still, the effort is ongoing.
|
| https://github.com/rust-rdom/rust-rdom
| zackoverflow wrote:
| Thanks, this is great. I see the readme mentions the project
| was created for yew, how far is from being ready to work with
| it?
| xpe wrote:
| Helpful acronym bot here.
|
| * SSR = server side rendering
|
| Related terms include:
|
| * CSR = client-side rendering
|
| * PWA = progressive web app
|
| P.S. I am not a bot. (But don't all bots say this?)
| brundolf wrote:
| What sets Seed apart from other Rust front-end frameworks? Is the
| Elm-like approach unique in that space?
|
| Unique or not, I bet it makes working with the borrow-checker a
| _whole_ lot easier
| ironmagma wrote:
| Yew and Sauron also exist which use the MVU pattern like Elm.
| Percy might also, not sure about that. Seed has a less React-
| inspired interface.
| ivanceras wrote:
| Author of sauron here, Yes sauron[0] is very much elm-like
| than any of the other rust framework, and it's very fast. How
| fast? Fast enough to be used in a text-editor[1] at ~15ms
| typing latency. It also suited application that has recurring
| events such as animation[2]
|
| It also supports server-side rendering, and is used in one of
| my other opensource project svgbob[3]
|
| [0]: https://github.com/ivanceras/sauron
|
| [1]: https://ivanceras.github.io/ultron/
|
| [2]: https://ivanceras.github.io/futuristic-ui/
|
| [3]: https://ivanceras.github.io/svgbob-editor/
| ceocoder wrote:
| My most sincere thanks to the author(s) for "Why Not" section.
| This level of self awareness and transparency makes me so happy;
| it takes so much guess work and unnecessary back and forth out of
| the discourse. Again - kudos!
| apozem wrote:
| So often people get emotional about languages and frameworks.
| They're tools, and tools have trade offs. The "Why Not" section
| recognizes that. Super impressive.
| zhiel wrote:
| In my opinion, this is the way forward. You cannot convince
| anyone that does frontend stuff to even try, or EVEN switch to
| this. We have to prove that this is a viable option, WASM is a
| viable way, WASM is actually more efficient etc. there are
| benchmarks and targeted studies... it just seems that browser
| vendors and devs haven't catched up yet
| zhiel wrote:
| If anyone is curious about Seed, here is my example project for
| pushing it sorta to a limit: https://rsfractal.herokuapp.com/
|
| It doesn't really test Seed, but I guess Seed just works?!
| :shrug:
| jjwiseman wrote:
| FYI it doesn't seem to work for me in Safari or Chrome.
| jeroenhd wrote:
| It works fine for me on Chrome (Linux or Android), Edge(ium,
| on Linux and Windows) and Firefox (Linux, for some reason not
| Android). It fails on Gnome Web (which is WebKit GTK), which
| is the closest I could get to Safari, because of
| SharedArrayBuffers being unavailable [0]. It seems like
| WebKit hasn't re-enabled them since the first Spectre
| mitigations like Chromium and Firefox have.
|
| One reason it could fail for you on Chrome is that perhaps
| you tested on iOS; Chrome on iOS shouldn't make or break web
| applications because Apple forces WebKit onto every browser
| on that platform, so they're all Safari with a skin. A broken
| website in iOS Safari is usually broken in all other browsers
| by Apple's design.
|
| Otherwise the code should work fine on up-to-date Chrome
| across all real Chrome platforms, unless you specifically
| toggled flags...
|
| [0]: https://caniuse.com/mdn-
| javascript_builtins_sharedarraybuffe...
| echelon wrote:
| The code is terse right now, but all of the ideas are there.
|
| In two years, I fully expect Rust to begin taking off as a major
| frontend language choice. A framework like Seed will help usher
| this in.
|
| It'll be faster than Javascript, eventually multithreaded, and
| produce portable binaries that can run on a wide variety of
| platforms and architectures.
|
| It'll paint to DOM, but also do immediate mode and other types of
| rendering.
|
| We'll see incredibly rich applications: games, video editors,
| IDEs, etc.
|
| Electron will yield to this. We'll have fast, cross-platform apps
| that run not just on the browser, but natively on Windows, Linux,
| and Mac.
|
| If we're lucky, we might even start writing mobile apps this way
| and ditch the iPhone/Android specific APIs.
| zhiel wrote:
| This is not a fever dream in my opinion, just replace Rust with
| your favorite language if that language targets WASM.
| Eventually, JS will be just another choice in a field of
| languages that would target WASM... then it is just a matter of
| preference.
| Oddskar wrote:
| People have been saying this for years. I don't think it's
| going to happen.
| zhiel wrote:
| Why not? WASM is gaining features after it's MVP, such as
| GC support, direct targeting with DOM APIs (with reference
| types and interface types), it's not a fast process, but
| it's coming. It doesn't take anything away from any
| programming language, but it provides a more efficient
| platform for those languages to run... what is there not to
| like?
| Zababa wrote:
| Lots of languages target JavaScript too, but only one got
| very popular, because ecosystem matters a lot. People are
| going to have to recreate the current JavaScript
| ecosystem for each languages, and then probably for each
| framework in that language.
| zhiel wrote:
| I have no idea who you are or how closely have you been
| following the ecosystem of languages, but like what? What
| you just said is what languages do
| Zababa wrote:
| No, not really. The only language that has mindshare in
| the frontend outside of JavaScript is TypeScript. Elm,
| CoffeeScript, Rescript and all of these are not known at
| all. In the JS ecosystem, Angular, React and Vue are
| king, but React is really fragmented with all the options
| (Next, etc). All of this because JavaScript is the most
| popular language in the world. Most other languages won't
| get that mindshare.
|
| Elm doesn't have the JS ecosystem, Rust doesn't, Rescript
| doesn't. The thing is, when you're doing backend stuff,
| it's usually relatively easy to pull a library with
| whatever framework you're using. On the frontend, for
| your components, you need basically a library by
| framework by language.
| rightbyte wrote:
| Wasn't this the promise of Java? I like your optimism though.
| laumars wrote:
| I can't see how when Java predates JavaScript.
| Thaxll wrote:
| There is not a single chance that a language like C++ or Rust
| become mainstream in frontend dev. The complexity of the
| language is at the opposite side of what webdev is about.
| Zababa wrote:
| > The complexity of the language is at the opposite side of
| what webdev is about.
|
| That's not true, current JS is getting complex, but we don't
| have a choice, except for WASM but the options aren't great.
| TypeScript is also very complex, but it's the most popular so
| people use it. Basic Rust isn't that complex, and I would
| argue is easier than TypeScript. I wouldn't want to be the
| guy building the framework, but using Rust to write business
| logic? That might be nice.
|
| On the backend side, Java dominates, with PHP, JS/TS, Python.
| All of these (in their modern form) are complex, usually by
| way of OO soup, or big frameworks, or a large ecosystem that
| you have to learn at first. On the other hand, languages that
| people like calling "simple" like Go or Clojure are
| relatively nice (at least for "business logic" web apps, Go
| is popular for "infra/devops" web stuff").
| void_mint wrote:
| I don't think this will happen, I don't even think Rust will
| become 1/10th the frontend language you're predicting it will.
| hnlmorg wrote:
| I love your optimism but I think you're overlooking a lot of
| why we've ended up in the landscape we are now, and it's not
| because we lacked a well designed language. It's because
| Javascript is like PHP: easy to learn, quick to develop in,
| cheap to hire, and just about good enough for people to stick
| with it.
|
| Don't get me wrong, I hate Javascript as a language. But
| sometimes worse is better.
| homarp wrote:
| [edited to make my point clearer] This is not about "value"
| of the language (worse is better) it is just about cost
| (cheap is better). Hiring js dev is cheaper because it is
| cheaper/faster to learn js.
| hnlmorg wrote:
| You're just reiterating the same points I made :)
| homarp wrote:
| edited to try to clarify my point. Mostly reacting to
| your last sentence.
| hnlmorg wrote:
| I'd already said JS was quicker to learn and cheaper to
| hire though. The "worse is better" statement is just a
| phrase intended to succinctly summarise that point:
|
| > _It refers to the argument that software quality does
| not necessarily increase with functionality: that there
| is a point where less functionality ( "worse") is a
| preferable option ("better") in terms of practicality and
| usability. Software that is limited, but simple to use,
| may be more appealing to the user and market than the
| reverse.
|
| ( Source: https://en.wikipedia.org/wiki/Worse_is_better
| )_
|
| JS is simpler and cheaper thus preferable.
|
| I guess I took for granted that not everyone is familiar
| with that phrase, sorry
| fspeech wrote:
| I deleted my first question so that I could read on the subject a
| little to make sure the question wasn't a stupid one. After doing
| some reading I still have the same question so here it is again:
|
| Does wasm app save memory significantly at runtime? If not why
| should one choose manual memory management outside of porting
| existing code?
| monocasa wrote:
| I wouldn't imagine here that Rust's value add in this case is
| the memory management. Instead it's probably the strict and
| ergonomic control over constness (I prefer rust in that specfic
| context to js Object.freeze), the typesafe concurrency, and if
| you're the kind of crazy person that would use rust on the
| frontend in 2021 you probably are using it in the backend and
| you can therefore share code.
| verdagon wrote:
| IIRC, functional programming already offered const-ness and
| type-safe concurrency.
|
| Do you think Rust might succeed here where FP couldn't really
| make much of an impact?
| monocasa wrote:
| FP with typesafe concurrency hasn't really happened on the
| frontend yet in meaningful way.
|
| And I wouldn't frame it as Rust succeeding where FP failed,
| but instead a way to sneak in FP into the frontend in a way
| that gets really angry at you when you try to structure
| your code as mutable and imperative. Yes, most of the
| frontend languages let you opt in to constness and compile
| time typesafety, but Rust makes you opt out. It's soft
| developer thing, but it seems to have benefits to code
| quality from my experience.
| brundolf wrote:
| FP isn't a technology, it's a way of using technology. You
| can follow it using JavaScript, or Rust, or Elm, or
| whatever. But JavaScript doesn't offer true constness (at
| least, not enforced). Elm does, but no JavaScript-targeted
| language (including Elm) has proper concurrency at all,
| type-safe or not (there are Workers, but they come with a
| bunch of caveats). Rust has good support for FP, type-safe
| concurrency (whether in an FP style or not), and mostly
| type-safe constness. Of course it also has its own set of
| tradeoffs, like anything else.
| brundolf wrote:
| I could also see it helping with bundle size. Also, while
| uncommon, it's not impossible for VDOM rendering to be a
| performance bottleneck on complex apps. I used to work on one
| where we had enough components on the screen at a time that
| it was often a problem.
| super_flanker wrote:
| It's great to see good wasm frameworks. I know the DOM
| interaction still requires js bridging, but I'm still interested
| in knowing rendering performance relative to yew (another wasm
| framework) and reactjs. Also last time I tested, the release
| bundle sizes were quite big, has there been any improvement here?
| the__alchemist wrote:
| I'm looking forward to the time when JS bridging isn't
| required. Once that happens, it should be possible to use Rust
| as more of a conceptual "drop-in" to the JS DOM-manipulation
| API - framework or not.
| zhiel wrote:
| Not affiliated, but an alternative to Seed or Yew is a new lib:
| https://github.com/sycamore-rs/sycamore
|
| AFAIK Seed and Yew target the VDOM stuff which has always been an
| unnecessary overhead, Sycamore does what Svelte does.
|
| It's very early days for Rust/WASM/Frontend, but all of this
| progress is very promising.
| kitkat_new wrote:
| no idea about Svelte, but what I've read in the documentation
| definitely looks very interesting!
| the__alchemist wrote:
| This is a great approach. Ie, declarative coding GUIs (like
| webapps) is nice, but VDOM is performance overhead, ie
| unnecessary computation. I haven't looked into how Svelte (Or
| Sycamore) do it, but being able to compile declarative code
| into targeted DOM manipulation seems like a best-of-both-
| worlds.
| beders wrote:
| I will never understand why anyone would want to use a compiled
| language to do front-end development.
|
| The beauty of JS and especially the beauty of ClojureScript is
| that you can immediately see the effects of your work in an
| interactive environment. Using the right libraries you can have
| true hot reloading without destroying state giving you a
| terrific, fast, fluid development experience.
|
| What are acceptable compile and reload times for you guys loading
| WASM?
| ceocoder wrote:
| My rational for using something like this:
|
| I fully agree that toolchain you mentioned gives blazing fast
| initial devX, hot reload and everything. If that's what you are
| optimizing for, it is a perfect solution.
|
| OTOH when you want to optimize for long term maintenance,
| growing codebase that is safe and easy to grow, easy to
| refactor, easy to check for odd things. I'd lean heavily on
| something compiled and with promise/guarantee of safety every
| time.
|
| In other words, it is all about trade offs and to each his own.
| clusterfish wrote:
| Because dynamic typing is terrible for big projects, and
| typescript's fake sense of security doesn't cut it. When you
| know that your code works you don't need to check it in your
| browser every nanosecond (although you could).
| expliced wrote:
| But typescript fake sense of security does cut it.
| danenania wrote:
| Updating and checking over and over is usually more about
| getting the ux right than making it work or fixing bugs. A
| tight feedback loop makes a huge difference when you're
| iterating on look and feel. If you have to wait 10 seconds
| and fill out a form or two to restore the full app state
| after each change, it becomes a nightmare and you'll likely
| just give up on making a good ux.
|
| There are also lots of frontend bugs that aren't really bugs
| in the compiler sense, but just cause the user to see a
| slightly wrong or confusing thing for a given state. Tests
| can help, but for a UI with a lot going on, there are usually
| too many possible paths to write tests for them all, so doing
| a lot of QA as you go is hard to avoid.
|
| Typescript offers a pretty good balance here since you can
| turn off typechecking for live reloading and instead check
| types in the background or as part of the test suite.
| gabereiser wrote:
| You don't need to check it in your browser at all if you
| wrote proper tests for it. TypeScript (with proper lint
| rules) is a huge win in my book compared to vanilla JS. That
| said, Rust's compiler guarantees are best in class. The hot-
| reload, want to see it happen immediately, is great for quick
| prototypes but for large projects, nothing beats full
| coverage.
| zhiel wrote:
| You would never want to understand why this is better?
|
| Here is a couple of reasons: 1. It is backed up by a statically
| typed, safe, elegant language that is like a strict teacher
| that tells you to fuck off when you make a mistake... 2. HMR is
| possible with this... 3. Look, WASM is not fighting against
| you, it is fighting for you... anyone who is targeting JS and
| is forced to do so is welcome to choose any other language you
| want...
| onei wrote:
| > ClojureScript is a compiler for Clojure that targets
| JavaScript. [1]
|
| If ClojureScript is compiled, why can't WASM be the same?
|
| [1] https://clojurescript.org/
| CraigJPerry wrote:
| In clojurescript you can press your slime or calva keystroke
| to send a form (or an expression from a rich comment) to the
| browser repl and see that immediately reflect and use the
| current state of the app without reloading.
|
| What's the equiv workflow when compiling to wasm? Save file >
| compile > hot reload? > reconstruct state somehow?
|
| Is it like clojurescript where you interactively work on the
| app in the same way you might interactively craft a sql
| statement in a live db?
| onei wrote:
| In Rust, no clue because I've never tried. However, I did
| find a hot reload of WASM compiled from C++ [1]. If they're
| not equivalent, I would imagine it's a matter of ecosystem
| maturity rather than it being impossible.
|
| Realistically, hot reload is going to be something like
| inotify(7) hooked into a compiler and whatever it takes to
| reload seamlessly. If it's been solved in one general
| purpose language, it's likely to be possible in another.
|
| [1]
| https://visualstudiomagazine.com/articles/2021/07/29/cpp-
| hot...
| CraigJPerry wrote:
| You can definitely hot reload in rust:
| https://fasterthanli.me/articles/so-you-want-to-live-
| reload-... (this person's blog is one of my fav's, i know
| that's a huge post but he covers everything really well).
|
| But this is missing the difference.
|
| When we say hot reload in javascript (or even better, hot
| module replacement) or java or rust or c++, there's
| usually annoying limitations like you can't change the
| arity of a function or you have to pause all the threads
| or you need some mechanism to reset state to a known good
| starting point because we just broke it (potentially).
|
| The difference with a lisp is that you don't need do any
| of that. You replace the function object in the system
| image (atomically) and you crack on like nothing
| happened. No waiting around, no rerunning state into the
| app. And you triggered it just from a keystroke in your
| editor.
|
| The developer experience is unparalleled.
| the__alchemist wrote:
| Seed creator here. For some context, I now code all my websites
| in HTML, CSS, and targeted JS (ie no frameworks or dependencies).
| Writing this was a great way to learn the ins and outs of DOM
| manipulation!
|
| Overall, I'm happy with the way the Seed API turned out, but
| could never get the performance or package size to a good place.
|
| That said, I love coding in Rust, and use it all the time for
| embedded!
| Svenstaro wrote:
| That's an interesting perspective! As someone considering seed,
| do you consider it a useful thing to pursue Rust as a frontend
| language in its current form and given the state of the
| ecosystem? Obviously you decided to go pretty deep exploring
| this topic and eventually went a different route but I'd be
| grateful if you could share some insight here.
| azakai wrote:
| > I [..] could never get the performance or package size to a
| good place.
|
| Do you have any more details on that? I'm curious how close
| this got, and what were the main issues (on both size and
| speed).
| the__alchemist wrote:
| I don't have specific info, but generally:
|
| - VDOMs in general have poor performance; they perform
| unnecessary computations in the diffing algorithm, and even
| well-designed ones perform extra DOM manipulations, compared
| to deliberately-written code.
|
| - The Rust WASM files would come out pretty large; a few
| hundred KB for a minimal app. This is better than some
| packages using React + common JS dependencies like Lodash and
| Moment, but with much room for improvement
|
| - DOM manipulation calls made in Rust via WASM(currently!)
| don't have any performance benefit over the native JS API
| azakai wrote:
| Thanks!
| smt88 wrote:
| It sounds like you made a Rust version of React. I think a
| Rust version of Svelte makes more sense in the long run.
| jjcm wrote:
| I'll just say I really enjoy the "Why not Seed?" section of
| your readme. The honesty is refreshing and it really let me
| know the plusses/minuses of this.
| fuddle wrote:
| Awesome looking forward to checking this out. FYI the header
| spacing looks a bit off: https://ibb.co/HzMNCJZ
| [deleted]
| kklisura wrote:
| I'm afraid that just like we have very simple web sites built
| with large SPA/frontend frameworks, we're gonna soon start seeing
| those same, but now built with WebAsembly.
|
| Let me be first saying that just like you don't need React,
| Ember, Angular, etc. to build your site, you also don't need the
| WASM as well!
| smt88 wrote:
| This project isn't just using wasm for the sake of it. It's the
| best browser-supported target language for Rust, so if you want
| a Rust front-end framework, you're going to compile to wasm.
| purisame wrote:
| Does anyone know how this compares to Yew?
| the__alchemist wrote:
| Yew predates Seed, and provided inspiration. At the time, Yew
| wasn't in a usable state. There were no full examples, no
| documentation, and the starter code in the Readme didn't
| coincide with the release. I believe they fixed those sometime
| after Seed's release.
|
| This doesn't directly answer your question, but is the context
| in why Seed started, with Yew already existing.
|
| An immediately noticeable difference is that Yew uses a JSX-
| like syntax, while Seed uses a custom API based on list-like
| macros.
| ivanceras wrote:
| I used both yew and seed, but the svg support is lacking.
| Both framework don't render svg elements correctly. As I'm
| the author of svgbob[0], which heavily uses svg. I wasn't
| satisfied with both of the frameworks, So I created sauron
| web framework and I was quite happy with the result. Not only
| I can do an server side rendering for svgbob[0], I can also
| write a text-editor[1] with it and achieve a ~15ms typing
| latency.
|
| [0]: https://ivanceras.github.io/svgbob-editor/ [1]:
| https://ivanceras.github.io/ultron/
| zhiel wrote:
| They are pretty much identical. Seed has better docs, Yew has a
| promise for multi-threaded stuff, but its not very well
| documented (or even working). I've tried projects with both and
| the nice thing with Yew is that the syntax for HTML is kinda
| compatible with the actual thing (think JSX.) Seed however is
| macros only. Both seem to compile in the same time, but I would
| bet there would be differences on bigger projects (which there
| are none atm?)
| the__alchemist wrote:
| Re big projects: I'm (sort of) using Seed on web-based
| scheduling and training software used by 7 operational
| fighter squadrons.
|
| The most complicated pages are in React/TS (eg the actual
| scheduling board), and the Seed pages are/were mostly simpler
| ones, like tracking qualifications, personalized schedules
| etc. I'm actively rewriting the smaller pages from Seed/Rust
| and TS/React to HTML/CSS/JS for performance and simplicity
| reasons.
| lbj wrote:
| Im excited to see Rust use more and more for webdevelopment,
| certainly some interest prospects.
|
| Im a little disappointed to see the amount of boilerplate in the
| examples. The Todo app is infinitely-5 longer than the
| Clojurescript example.
| zamalek wrote:
| I tried Seed out a while back, one thing I really enjoyed was the
| _lack_ of JSX-like views. It 's not necessarily the aesthetics of
| it, it's that it takes _ages_ to compile those macros.
| brundolf wrote:
| Meaning the style of macros used by this framework is just
| simpler and therefore faster to compile?
| seph-reed wrote:
| I loathe jsx.
|
| Having two separate coding languages in a single file that
| switch back and forth is such a ridiculous idea to me. And on
| top of that, I don't think jsx is any more readable than nested
| functions.
| turtlebits wrote:
| Looking the home page (which looks to be built with seed-rs), a
| ~500k wasm file is loaded.
|
| The static part loads fairly fast, but none of the links work
| until after the wasm loads (you can tell because the header
| changes)
|
| Looks like the entire site is in the wasm file as no additional
| network requests are made. Doesn't seem great for general purpose
| web sites (like your home page).
| zhiel wrote:
| Now imagine if the WASM folks had all the bundler/dead code
| elimination/link time optimization..., its coming, sorta...
| sfvisser wrote:
| Not that I disagree -- it's rather steep -- but not super
| unlike many react/vue based sites.
|
| Frameworks like Next.js can help by adding seamless server side
| rendering so at least your links will work before your js/wasm
| is loaded. Maybe seed-rs can move into that direction as well.
| brundolf wrote:
| Is that 500k with or without gzip? With gzip, that would be
| huge.
|
| Either way there are certain techniques like bundle-splitting
| and hydration that will probably have to be reinvented for
| these WASM frameworks, unfortunately. For the moment they're
| probably better suited to high-complexity browser-based tooling
| that needs the extra performance, vs simple crud sites.
|
| Edit: on second thought, for an entire multi-page site in one
| bundle this wouldn't be _super_ huge. I 'm used to smaller
| numbers but I'm also used to split-bundles.
| turtlebits wrote:
| For the site (including wasm) - (over the network) 597 kB
| transferred (uncompressed) 2.3 MB resources
| azakai wrote:
| The wasm file is dc7bb6f6208af7f13f16.module.wasm which is
| 2MB uncompressed.
| jbandela1 wrote:
| Kudos to the author for making this framework.
|
| I am using this for my personal project:
| https://www.biblemaze.com which is a Bible trivia game.
|
| Here are some things I like about Seed:
|
| 1. The Elm architecture seems to flow nicely in Rust.
|
| 2. The way of defining the elements on the page is more Rust like
| rather than html like. I initially tried Yew which is another
| similar framework, but since I am a more backend developer, I
| found writing in a more Rust style more comfortable than writing
| in a more html-like dsl. Other with different experiences may be
| more comfortable with more html-like syntax.
|
| 3. Very easy to perform REST API calls. I am using Actix for the
| backend, and I have a shared library that declares the types
| which both the backend and frontend use. This is one big
| advantage for using Rust for both backend and frontend, in that
| you never have to worry about your types getting out of sync.
|
| 4. In general as to why Rust for the front end, apart for being
| able to share types, for more complex algorithms, for me, having
| a compiled language with an emphasis on safety and that tries to
| ensure correctness as much as compile time (and especially
| pattern matching) makes writing complex code more enjoyable for
| me.
|
| 5. Excellent documentation on the Seed website. There are lots of
| examples and walkthroughs of basics as well as examples of how to
| do stuff like integrate with Javascript libraries.
|
| Anyway, thanks again to the authors for making and supporting
| such an awesome library.
| rictic wrote:
| - This is one big advantage for using Rust for both backend and
| frontend, in that you never have to worry about your types
| getting out of sync.
|
| One thing to be aware of here, you may have users with stale
| clients after deploying an update to the server. e.g. picture
| someone who leaves a tab open for a week and then comes back to
| it and interacts with your app some more without refreshing.
|
| Text based serializations will tend to be more forgiving of
| changes in the RPC schema (in the sense of erroring out when
| required fields are missing), while more compact serializations
| are more likely to incorrectly decode a message when they
| should fail.
| mdtusz wrote:
| The quick and dirty solution to this is to have a client
| response handler that checks for a header set on responses to
| ensure its a compatible version, then prompt a page refresh
| if not.
| jbandela1 wrote:
| One thing you can do in the shared library is to have a
| version number constant that is always passed in the rpc.
| That way if the client is stale, it can easily be detected,
| and you only have to change 1 place when you update the
| shared structs.
| metadaemon wrote:
| Very fun! Is it possible to remove the '-' symbols once a new
| path has begun? They were blocking previous paths, which also
| may be the point.
| jbandela1 wrote:
| Thank you. It seems this is in reference to my game. If so,
| please contact me on my email (in my profile) so we can
| discuss further in detail.
| metadaemon wrote:
| It's not a big deal, thanks.
| loveJesus wrote:
| Praise the Lord, agreed a neat game. Is it open source? It
| would be interesting to try and add on to it or use the
| questions (Did you get them from somewhere)? There is a
| Christian Gamer of TikTok @simplyivee who sometimes uses
| these kinds of word games with the audience and i was hoping
| or praying for some kind of Bible related suggestion to give
| as well. So my hope is to add some graphical items for the
| format and suggest it to her account, my coding style is a
| bit particular though with _aleluya appended to variables to
| try and remain in God's presence (Very thankful for what He
| did for me and my family, healed me of a schizoaffective
| bipolar disorder diagnosis, been psych med free since 2014.
| My dad here healed before heart surgery, knee surgery, even a
| dog healed from cataracts the day after praying for her, my
| dad here spoke praising God in Arabic once, not knowing the
| language someone else told him). I also have been thinking
| about making an app to register these miracles and do data
| analysis, they are not uncommon. I know some people have lied
| about things in the past, but there are so many true ones. I
| am happy to have seen a few Bible related posts reach the top
| of HN the past few days. My thoughts are that many people
| here are not happy to hear that God is real yet. I suppose
| not ready to surrender to Him and His ways or design of
| things. Always wondering how i can share my testimony here
| better https://soundcloud.com/brianlovejesus/hallelujah-
| pinduca-rad... God's guidance and blessing to you all in
| Jesus name
| aitchnyu wrote:
| How is interop with JS libraries like Leaflet?
| darkstarsys wrote:
| How would you debug serious web apps written in this Rust/wasm?
| Chrome dev tools can't load your Rust code, right?
| ivanceras wrote:
| I just `log` and `console_log` crate for showing values in the
| browser console. It's good enough for most cases.
| ggregoire wrote:
| On a side topic, what are the recommended Rust frameworks for
| creating REST APIs?
| brundolf wrote:
| Rocket is the most promising up-and-comer I know about:
| https://rocket.rs/ It manages to provide an experience along
| the lines of Flask or Express
|
| Iron and Actix are the more established but more complicated
| ones
|
| Edit: According to a reply, Iron is considered abandoned
| ggregoire wrote:
| Actix is #5 on techempower.com/benchmarks, that's impressive!
| Zababa wrote:
| And Rocket is surprisingly slow. Is this because it's not
| async yet?
| ggregoire wrote:
| Some comments about it here:
| https://news.ycombinator.com/item?id=26069195
| brundolf wrote:
| Nice, good info. v0.5 (currently in RC) is the
| stable/async version mentioned. Excited to see the
| benchmark get updated for that version.
| [deleted]
| brundolf wrote:
| It is higher-level than actix, though it's still
| surprising to see it as low as it is. I'm curious what
| the story is there too. It is significantly higher than
| Express and Flask, though it's lower than raw NodeJS and
| PHP.
|
| I guess maybe these benchmarks only test the overhead of
| the framework itself, and ignore the benefits of having
| your business logic and middleware written in a faster
| language? The tests for node and PHP would pretty much
| only be running battle-tested native code if that's
| what's going on
| tempest_ wrote:
| Rocket prior to 0.5 was not async and thus does not
| really preform well in those benchmarks.
|
| 0.5 however is async and is currently in rc, when it is
| released I would expect it to climb up the list a little
| bit.
| [deleted]
| agersant wrote:
| Iron is very much abandoned, I would not recommend it. I
| agree Actix and Rocket are the more common picks!
| brundolf wrote:
| Got it. I knew Iron was kinda being phased out due to stuff
| like not having async/await, but I didn't know it had gone
| so far as being "abandoned".
| ggregoire wrote:
| Digging up the topic, I also found this new framework
| https://github.com/tokio-rs/axum, which already seems to be
| popular.
|
| Sentry is rewriting some of their libs from Actix to Axum: ht
| tps://github.com/getsentry/symbolicator/commit/b6ef7cb00b7...
| masklinn wrote:
| I don't know that i'd recommend warp per se but it's an
| interesting take on the subject.
| option_greek wrote:
| Warp is pretty good. It's simple, fast and gets out of the
| way once you create the routes. No enforcement of any
| specific conventions etc.
| masklinn wrote:
| Oh yes I like Warp, don't get me wrong, but it's odd
| compared to the "standard". And the Result/Rejection system
| used for _routing_ confuses people a lot (which is
| understandable, its use here is quite at cross purpose with
| normal uses for a Result).
| bynxbynx wrote:
| I've enjoyed dropshot
| (https://github.com/oxidecomputer/dropshot/) but recognize it's
| not for everyone :)
| mojzu wrote:
| Looks like an interesting project, how complete is the
| OpenAPI support? It seems like most Rust web frameworks have
| an open issue for it/some partial implementation
___________________________________________________________________
(page generated 2021-09-17 23:00 UTC)