[HN Gopher] Single Page Applications using Rust
___________________________________________________________________
Single Page Applications using Rust
Author : rkwz
Score : 572 points
Date : 2020-08-11 14:00 UTC (8 hours ago)
(HTM) web link (www.sheshbabu.com)
(TXT) w3m dump (www.sheshbabu.com)
| bodhi_mind wrote:
| Anyone know when all browsers will support 64bit wasm and allow
| >4gb memory?
| jandrese wrote:
| 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.
| Naac wrote:
| 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.
| nikitaga wrote:
| Rust is also a safer alternative to Javascript (and even
| Typescript for that matter).
| K0nserv wrote:
| 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.
| praveenperera wrote:
| 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 wrote:
| You should have a look to this project built with actix, diesel
| and yew:
|
| https://github.com/saschagrunert/webapp.rs
| praveenperera wrote:
| This is great. Thank you!
| gameswithgo wrote:
| sharing types you just have a shared lib. don't have to do
| anything special. and you can serialize them easily with serde
| [deleted]
| rkwz wrote:
| Thank you! The sharing common types and logic is pretty easy
| using cargo workspaces, will include this in future posts :)
| praveenperera wrote:
| Awesome!
|
| I think it would also be cool to explore alternatives to REST
| with JSON for a full stack Rust app.
| gameswithgo wrote:
| I have a hobby project where I am serializing everything to
| bincode with serde, and communicating with my own protocol
| over websockets. its quite nice! Rust's enums make this
| kind of serialization and communication super easy.
| praveenperera wrote:
| That sounds very interesting. Do you have a public repo I
| could check out?
| boltzmann_ wrote:
| waiting for a rails like framework that would let me use only one
| language full-stack.
| whb07 wrote:
| F# does this via Fable.
| dmit wrote:
| 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 wrote:
| 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%.
| Wohlf wrote:
| C# as well via Blazor.
| intelleak wrote:
| Hi, would you be able to give your experience in brief, how
| is fable? And elmish? How happy are you with fable?
| notamy wrote:
| Elixir does this via Phoenix + LiveView, tho it's not quite as
| fully-featured as Rails.
| gameswithgo wrote:
| Yew, Seed, Percy
| nilkn wrote:
| You can definitely already do that in Rust, although I'm not
| sure how mature all the tooling is yet and rather than using a
| single framework you'd be using a few different toolsets (e.g.,
| Actix/Rocket, Diesel, Yew).
| danShumway wrote:
| Isn't this example already using Rust full-stack, or am I
| missing something? You still need to write HTML, but that's
| also the case with Ruby on Rails.
| rolae wrote:
| With Stimulus Reflex we are getting pretty close.
|
| https://docs.stimulusreflex.com/
| batt4good wrote:
| 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.
| pier25 wrote:
| Can you load WASM modules dynamically like we in do in JS with
| import()?
| steveklabnik wrote:
| 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 wrote:
| Right, I guess the tooling would need to support code
| splitting into separated wasm modules like we do with Webpack
| or Rollup.
| bob1029 wrote:
| 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.
| grok22 wrote:
| I am interested in understanding this further -- is there a
| write-up or explanation with example anywhere regarding how you
| achieve this in Blazor.
| bob1029 wrote:
| As far as I am aware, there is no public document on the
| internet which describes this approach in a consolidated way.
| Unfortunately, I cannot share examples from the codebase I am
| currently operating on. That said, I can offer some MS
| documentation links in hopes that this paints a slightly
| better picture for how I achieve this outcome.
|
| This describes how you would request a scoped stateful
| service from an arbitrary Razor Component:
|
| https://docs.microsoft.com/en-
| us/aspnet/core/blazor/fundamen...
|
| This describes how you would inject these stateful services
| into DI in a way that scopes them as desired:
|
| https://docs.microsoft.com/en-
| us/aspnet/core/blazor/fundamen...
|
| Note that we are using Server-Side Blazor, so this approach
| works for us. I do not think it works with WASM (at least out
| of the box), but we do not care for this form of Blazor
| hosting right now, so its not a concern for us.
| nicoburns wrote:
| 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.
| IggleSniggle wrote:
| I find the reference to Angular confusing here, since generally
| in an Angular app you will keep a single client's state
| concerns in Services that hold the results of API queries, with
| those results flowing into the UI reactively. You only pass
| input into Components from other Components for transient,
| presentational UI state.
| amw-zero wrote:
| What you described is exactly what I've been doing when
| building UIs. All of the logic of the front end application is
| completely outside of the view layer. I think this coupling of
| the view vs. the front end application is bad, and it's the
| most common default mode.
|
| Then, the view has only minimal logic. Like you mentioned, it
| does require some code, like mapping over an array to create
| the individual rows of a table. You also need one level of if
| branching, because sometimes you need to show or hide a UI
| element based on some state.
|
| But that's it. I don't even render components when testing
| generally. The setup code for actually rendering UI is very
| brittle, and when was the last time your bug was that you
| called the wrong function in response to a button click? The
| small layer between the UI framework and the brains of the
| application is best tested by actually looking at the rendered
| view anyway. Its completeness is qualitative.
|
| Anyway, I'm really fond of this approach and wish more front
| end devs were open to doing it.
| frequentnapper wrote:
| what is the appeal of Blazor (as for that matter yew), when now
| there's a healthy ecosystem based on Typescript for the front-
| end? Is it just the ability to never leave C# (or rust)?
| gameswithgo wrote:
| Yes, there is always some value in having the same language
| client and server. Both in terms of being able to have shared
| types and functions, and less cognitive overheard when
| switching from client to server.
| fmakunbound wrote:
| I'll do just about anything to avoid JavaScript, including
| learning Rust.
| alpineidyll3 wrote:
| You read my mind.
| thealienthing wrote:
| I can only imagine how many JS diehard fans are screaming in
| rage when they read this. I'm with you.
| vlucas wrote:
| 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.
| HugoDaniel wrote:
| luckily WebAssembly is stream compiled while data is being
| fetched in parallel; unlike JS it does not need to load the
| whole file to start working on it :)
| dstaley wrote:
| 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 wrote:
| 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... explains more.
| tus88 wrote:
| Whats the point. Javascrupt cannot have memory errors and has no
| threading, so why bother with a memory safe language like Rust?
| hpen wrote:
| Why create web apps in Rust? Won't that slow down development?
| pettusftw wrote:
| 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.
| johannes1234321 wrote:
| 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 ...
| ncmncm wrote:
| Ah, but that wasn't written, it was cut'n'pasted, which Doesn't
| Count. Or does it?
| johannes1234321 wrote:
| Answer A: For a joke it doesn't matter.
|
| Answer B: By that logic it is "without writing any code"
|
| But yes, the example is nice and it's not a production line,
| probably not even copyrightable.
| arkanciscan wrote:
| 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 wrote:
| 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.
| rwoerz wrote:
| Yes, two of them instead of a single one. Promise kept!
| raggi wrote:
| 136kb feels heavy for what this is
| kinghajj wrote:
| A lot of that comes from a few large libraries needed to
| provide base runtime functions (like memory allocation).
| crazypython wrote:
| Full-stack Dlang framework https://github.com/huntlabs/hunt-
| framework
| NationalPark wrote:
| No wasm stuff here though.
| AlchemistCamp wrote:
| 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/
| joshsyn wrote:
| 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.
| kibwen wrote:
| 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 wrote:
| Dug in the source, I believe they're using Prism's Diff
| Highlight plugin:
|
| https://prismjs.com/plugins/diff-highlight/
| deschutes wrote:
| What is the size of the served wasm binaries?
| M2Ys4U wrote:
| Looking at the linked demo site[0] the wasm file is 476kb
| (133kb compressed with brotli).
|
| [0] https://rustmart-yew.netlify.app/
| [deleted]
| kuon wrote:
| 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.
| ori_b wrote:
| 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?
| nilkn wrote:
| 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.
| azangru wrote:
| I re-ally struggle to see the appeal of Rust for frontend web
| development over typescript.
|
| Perhaps there are some rare scenarios where you need to eek out
| every little bit of performance... But in normal circumstances,
| typescript offers a fantastic combination of familiarity,
| expressiveness and ... if not type-safety, then at least some
| degree of type-sanity.
| danenania wrote:
| There are major benefits to using the same language on
| backend and frontend though, especially with typed languages
| where you can share types. In my experience, this makes a
| much bigger difference than the specific language you choose.
|
| So the real question imo should be which is better
| considering _both_ frontend and backend. I suppose it's also
| a very project-specific question. Maybe a heavy frontend
| project = ts, while heavy backend = rust.
| mplanchard wrote:
| I would choose Rust over TS not for any performance
| characteristics, but because I strongly prefer it as a
| language, due in large part to features like pattern
| matching, sum types, exhaustiveness checking, traits, etc.
|
| I do quite like TS, but you can never really get away from
| the fact that you're still limited by many historical
| JavaScript gotchas, and the type system is nowhere near as
| powerful as Rust's.
|
| Edit: That being said, as a business decision, TS will often
| be a better pick because it's so much easier to find talent,
| and the learning curve is much smaller.
| bgorman wrote:
| I don't understand why Rust is more compelling than ReasonML
| (OCaml).
|
| Reason is more expressive and on the web low level memory
| management isn't a concern.
| nilkn wrote:
| Isomorphic codebases. I would much rather use Rust on the
| back-end than ReasonML/OCaml.
| StreamBright wrote:
| I was wondering about that too. OCaml has a really good track
| record and the whole Bucklescript ecosystem also proven to be
| good for reliable frontend development.
| ronanyeah wrote:
| As a longtime user of both, Rust has a long way to go on the
| frontend before I would consider switching.
| giancarlostoro wrote:
| > I am hopeful that Rust can achieve what Elm did not.
|
| I am hopeful we can see the web ecosystem evolve into being
| capable of 'Single Language Web Applications' like Rust seems
| to be capable of, and C# as well. Of course there's Flutter,
| but it seems to just pain on a canvas instead of reusing the
| DOM.
| Parazitull wrote:
| For anyone looking for an Elm like experience but without the
| limitation imposed by its creator, take a look at Elmish, a
| port of the Elm architecture in F#.
|
| Advantages: You can use F# on the front and backend. Pretty
| good js interop with a lot of opportunities to shoot yourself
| in the foot.
|
| Disadvantages: You will probably need to use the Elm
| docs/tutorials to learn about Elmish.
| nickbauman wrote:
| 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?
| steveklabnik wrote:
| This is a complicated question, and ends up different for
| each individual. For me, I don't see the borrow checker as
| being more silly than GC, just an alternative, and one that
| speeds up my development process, not slows it down. I am
| also, of course, incredibly biased.
|
| Rust also has many, many features that are not the borrow
| checker. Some people prefer Rust because of those features,
| in spite of the borrow checker.
|
| https://without.boats/blog/notes-on-a-smaller-rust/ is also
| one of my favorite bits of writing on this topic.
| nickbauman wrote:
| That's a good link there. I think the answer to a smaller
| Rust is Go, however. The comparative compiler speed alone
| is worth the price of entry. Don't @ me ;)
| gameswithgo wrote:
| Go is so much smaller its no longer anything like a
| smaller ruts, though.
|
| Or, is Go bigger because the GC represents a ton of
| complexity?
| hardwaregeek wrote:
| Wow...there is really really good advice in that post. I
| was considering making my side project language into a
| simpler Rust and that post just gave some great
| suggestions. Especially since I'm writing the compiler in
| Rust to WASM.
| Scarbutt wrote:
| 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).
| StreamBright wrote:
| It is a valid point I don't know why the downvotes.
|
| I think Rich had to make a decision, writing a completely
| new LISP from scratch or leverage an ecosystem and create a
| LISP on the top.
|
| >> 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.
|
| The biggest problem with Java libs the mixed quality. Many
| big data project have this problem, if you peek under the
| hood you gonna be amazed about abstractions leaking into
| different bits and pieces of the system. My favourite
| example how ORC imports Hadoop FS
|
| https://github.com/apache/orc/blob/master/java/core/src/jav
| a...
|
| There is one more problem with Clojure that I find
| annoying, the actual Java interop. I was running into
| issues with this many times and some Jave libs are almost
| unusable without a thin wrapper written in pure Java.
|
| Other than that, I think Clojure is still one of the best
| options out there.
| pjmlp wrote:
| 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".
| danenania wrote:
| It's been years since I used clojurescript so ymmv, but imo
| integrating so tightly with the closure compiler was a big
| mistake. It adds _tons_ of futziness and build complexity
| for what, in practice, are usually pretty marginal
| reductions in bundle size that end users won't notice.
| nickbauman wrote:
| Never had a problem with the closure compiler vis-a-vis
| ClojureScript, is this really a thing?
| keithasaurus wrote:
| I don't see clojure in the same realm here. Both rust and elm
| are geared more toward enforcing correctness through their
| type systems to tame complexity in large projects. In my
| experience, clojure, being dynamic, fits more as a comparison
| to vanilla JavaScript. In a langauge-to-language comparison,
| I think clojure is somewhat more appealing than JavaScript
| due to immutability by default and general functional
| niceties. However, the fullstack comparison is not quite
| apples-to-apples as clojure (backend) is JVM and
| clojurescript (frontend) is node. While it works for some
| people, clojure feels awkward to me as a fullstack language.
| dragonwriter wrote:
| > clojure (backend) is JVM and clojurescript (frontend) is
| node.
|
| Node is a backend JS implementation. ClojureScript is
| compile-to-JS and can run on the backend in Node or on the
| frontend in browsers.
| keithasaurus wrote:
| Thanks, that's correct. I often make the mistake of
| interchanging node for browser js on accident...
| nickbauman wrote:
| Types provide only the simplest most trivial kinds of
| correctness, though. And people routinely make mistakes
| with types.
| johnsoft wrote:
| I think simple, trivial type systems offer simple,
| trivial correctness. Robust type systems can offer robust
| correctness (when used to their potential).
| jhomedall wrote:
| In addition to the benefits listed in the other comments,
| exhaustive checks in sum types are useful for catching
| unhandled cases, especially when refactoring.
| [deleted]
| keithasaurus wrote:
| Types still exist in clojure of course, you just have to
| spend time reasoning about what they may be in any given
| place. The longer I've worked with clojure, the less I've
| understood this argument.
| AlisdairO wrote:
| Things like null safety aren't trivial for practical
| purposes IME.
| nickbauman wrote:
| Most Optional implementations are kinda terrible, though.
| They cost more than they save. If I have a function with
| a param and I release it with it required, but later I
| change it to be optional (loosening a requirement) does
| rust require everyone calling that function the old way
| to change their code? If so that not an improvement!
| ragnese wrote:
| You're basically just regurgitating a recent Rich Hickey
| talk. Interested readers can probably find it on YouTube.
|
| Rich is certainly a brighter individual than me, but some
| of his points are either him missing the point or being
| intentionally misleading.
|
| For example, he discusses how Either types aren't true
| sum types because Either<A, B> isn't the same type as
| Either<B, A>. So he disparages people who say that
| Rust/Scala/Whatever have sum types. He's missing the
| point because 1) All Either implementations I've seen
| have the ability to swap the arguments to match another
| Either with the types backwards, so it's a sum type in
| practice, and 2) Clojure has none of it, so why criticize
| the typed languages by saying their type systems aren't
| perfect when your language's type system isn't helpful at
| all? Throw the baby out with the bath water?
|
| To your specific point (which is also one of Hickey's),
| yes, it does kind of stink that loosening a requirement
| forces consumers to update their code. However, that
| minor downside does not mean that Optional is "not an
| improvement". It's still a HUGE improvement over Java's
| absurd handling of null (IIRC, Clojure is the same as
| Java there).
|
| Also, maybe changing something to optional isn't _really_
| "loosening" the requirements. It's just changing the
| requirement. If the parameter changed to optional, don't
| you want to be alerted to that? Why is it optional now?
| What will it do if I pass None/null? Maybe I actually
| would prefer that to the way I called the old version.
|
| It just never struck me as offensive to have to change my
| code when I upgrade a dependency. I have trouble
| sympathizing with that mindset.
|
| Edit: And what is the Clojure alternative? You can loosen
| requirements, but really, you never had enforceable
| requirements anyway. Is it apples to apples to talk about
| a typed language loosening its contract?
| ithrow wrote:
| _does rust require everyone calling that function the old
| way to change their code? If so that not an improvement!_
|
| Can you share why is that bad? the compiler will tell you
| exactly where you need to make the changes.
| nickbauman wrote:
| Poor ergonomics: I loosened a requirement. Nobody should
| have to change their code. Kotlin does this right.
| ragnese wrote:
| How often do you believe this really happens in practice?
| And does that truly outweigh the benefit of being able to
| define a precise contract on your APIs?
|
| How many times have you written a function and a version
| later said "Oh, wait. I guess I don't actually need that
| required Foo parameter! I used to, but now I don't!"
| steveklabnik wrote:
| If you change a type from T to Option<T>, yes, all the
| other code has to change to take the option into account.
| nickbauman wrote:
| Yeah that's not good design. Lowering a requirement
| should not make callers complying to a stricter one have
| to change anything. But, ohhh.. right only the _type_
| changed. so everybody stop what you 're doing and start
| over.
| steveklabnik wrote:
| I strongly disagree, but this is why it's great we have a
| ton of languages! To me, forcing you to handle it is the
| exact point of an option type.
|
| The type wasn't the only thing that changed, the possible
| values have changed. You may be getting more values than
| you were previously. This means that some of your
| assumptions may be incorrect. Of course your code needs
| to change.
| skoodge wrote:
| I might be misunderstanding, but I think you are talking
| about slightly different points here. It seems to me that
| the critique of an explicit Option type (that acts sort
| of like a box, in contrast to Kotlin's T? vs T) applies
| to when you pass in the Option _as a function parameter_
| to a function that previously expected it to always be T
| instead of Option <T>. In that case you as a caller are
| never "getting more values than you were previously", but
| you can now certainly pass in more values than you could
| before.
|
| Forcing callers to refactor their calls to use a new
| Option<T> type as a parameter simply amounts to a change
| in the type signature, but since the function is more
| liberal than before, it cannot break your assumptions (at
| least not assumptions based on the function type
| signature).
|
| (For what it's worth, I do find Kotlin's T? to be more
| elegant than the Haskell/Rust-style Option/Some type. But
| then again, Kotlin is not fully sound, so there's that.
| Dart's implementation of T? will be fully sound though,
| so there are definitely examples of languages going that
| route.)
| steveklabnik wrote:
| That is true! You're right that the perspective can be
| different.
|
| You _could_ write <T: Into<Option<i32>> if you wanted,
| and your callers wont change.
|
| Frankly, using options as parameters is just not
| generally good design, so this issue doesn't really come
| up very often, in my experience. There are exceptions,
| but it's exceedingly rare.
| [deleted]
| AlisdairO wrote:
| Well, yes, of course. The thing you could previously rely
| on being present can no longer be guaranteed to be
| present - that _should_ require code in the calling
| function to change.
| nickbauman wrote:
| Not if I _loosened_ the requirement. Stricter adherents
| shouldn 't have to change anything. This is poor language
| ergonomics.
| setr wrote:
| To be clear, you're talking about the function signature
| changing from fn(a: int)
|
| to fn(a: Option<int>)
|
| ?
|
| Technically, yes, all callers would have to update, but
| practically, you'd just define fn(a:
| int) { fn_2(Some(a)) }
|
| to avoid the breakage. That is, you're essentially
| telling the compiler how to loosen the requirements.
| Ergonomically, this seems rather fine. Especially if this
| means you gain (some) protections from the much more
| problematic case of restricting the requirements.
| [deleted]
| [deleted]
| nilkn wrote:
| In many ways the borrow checker is a tool for enforcing safe
| mutation of values. As a side effect it happens to prevent
| entire classes of memory bugs, but it also prevents many bugs
| that aren't related to memory safety. Historically that side
| effect was the motivation for designing and implementing it,
| but in practice it's useful as a general guide for writing
| rigorous and correct software. As a result, I don't think the
| borrow checker as silly in this context as you're suggesting.
| gameswithgo wrote:
| There is no javascript in a rust web application.
| louisvgchi wrote:
| Rust is not running in the context of JavaScript. It's
| running on WebAssembly, which has no garbage collector.
| johnsoft wrote:
| >The borrow-checker in Rust is kind of silly tool to use in
| the context of a managed language
|
| I suspect a lot people are drawn to Rust more because of its
| type system and great tooling. I'd be perfectly happy with a
| version of Rust that swapped out the borrow checker for a GC,
| but such a language doesn't exist today, and Rust does exist.
| nickbauman wrote:
| Yeah the borrow checker is an interesting solution to a
| problem I don't have with a managed language. It's the main
| "safety" feature people coming to rust are introduced. I'm
| in agreement about Rust here with a lot: "one does not let
| one's friends skip leg day" there's a lot more to good
| language design than memory management. Is it worth it?
| ragnese wrote:
| One of the things I like about non-managed languages is
| the ability to have true destructors. Releasing resources
| is awkward at best in Java, et al.
| G4BB3R wrote:
| I prefer to use languages in the domains they were designed
| for, and I think it's almost impossible to a general purpose
| language, or a system programming language, to be better in a
| domain-specific language that was designed with the right trade
| offs in mind. Elm having less abstraction-power and doesn't
| offering full interop with JS, was a design decision. For this
| reason, we have lots of high quality packages that makes sense
| to Elm, instead of bindings of JS libs. For the other side, I
| can't see any language being better at system programming than
| Rust.
| tiffanyh wrote:
| > " I prefer to use languages in the domains they were
| designed for"
|
| So for web development, do you use PHP?
|
| Because neither Python, nor Ruby nor even JavaScript itself
| was designed for web development.
| dmix wrote:
| Most of Ruby's life has been dedicated to web development.
|
| The original use-case at birth of a language matters less,
| as programming languages are living things that evolve and
| mature, sometimes morphing into very different things than
| they were at the beginning.
|
| Likewise Rust's current lifespan has almost entirely been
| dedicated to taking on C/C++ and their use-cases in systems
| programming and server applications. That's all that really
| matters here.
| golergka wrote:
| Language design does not end with the release of the first
| version.
| dec0dedab0de wrote:
| JavaScript was definitely designed for web development.
| Though, at the time web development meant a tiny bit of
| magic in an otherwise static html document.
| bhaak wrote:
| I wouldn't call "animating a piece of text" on a HTML
| page as "web development.
|
| 16 bit home computers could do this better 10 years
| before JS.
| whatshisface wrote:
| The crucial distinguishing factor is that JS was made to
| animate a bit of text... on every device in existence,
| past present or future. That's the biggest difference
| between the web and native.
| G4BB3R wrote:
| No, because PHP was not designed at all, it was just a hack
| that solved some problems and started to evolve. Anyway,
| web development in '95 is not the same thing as today.
| frequentnapper wrote:
| > nor even JavaScript itself was designed for web
| development
|
| Javascript was designed for web development of the 90s. It
| evolved along with web development.
| Tarq0n wrote:
| I noticed Elm is listed as an inspiration by a number of Rust
| front-end frameworks (seed and iced for instance). It seems a
| lot of people feel the same in the Rust community.
| wolfadex wrote:
| Why not have tools that specialize and are strong in some areas
| instead of trying to have a Swiss Army Knife language? In other
| professions it's normal to have different tools for different
| tasks. Or is there something I'm missing?
|
| I personally would be happy with many different languages that
| are focused on front end development, like how we already have
| many that are focused on back end development.
| ghostwriter wrote:
| > It was an outgrowth of failed experiments in FRP from the
| Haskell world
|
| I'd like to hear more about this failed experiment. Reflex is
| alive and active and perhaps is the best tool out there for
| fullstack applications.
| Ericson2314 wrote:
| As someone who uses Reflex at work and has also written a
| bunch of Rust, I wish Rust the best but am highly skeptical
| it's going to be a _productive_ tool, and not just nerd-
| fodder, for user interfaces.
|
| Reflex is distilled mutation and week reference black-magic,
| and the safe interface it provides relies heavily on higher
| kinded types. Even if someone goes though all the trouble to
| implement it or something like it (And that would be cool!),
| I don't think the resulting algorithms can be packaged up in
| nice abstractions.
|
| Rust is a great language, but it just shouldn't bother
| competing where GC will do. It's just no point trying to win
| a race with that handicap.
|
| ------
|
| I do believe in "one language for all tasks", actually. It's
| just that one language will have split ecosystems as it will
| support many idioms that don't interoperate well. Put another
| way, let's start with "multiple languages, perfect type-safe
| FFI", and then go for endosymbiosis.
| svnpenn wrote:
| > without writing a single line of JavaScript
|
| Looks like 680 lines to me:
|
| https://rustmart-yew.netlify.app/wasm.js
| steveklabnik wrote:
| You do not write that JavaScript, it is generated for you by
| the tooling.
| svnpenn wrote:
| 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 wrote:
| Sure, and you are very welcome to do so. That's not what
| the original post said, nor what you said in response,
| though.
| CryZe wrote:
| That's auto generated and will shrink more and more in the
| future as WASM gets more abilities to directly call into DOM
| APIs and store JS objects.
| intelleak wrote:
| 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 ...
| devxpy wrote:
| 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.
| kevincox wrote:
| Macros in Rust don't need to be completely valid syntax. There
| are some requirements such as balanced parens and strings but
| the macro API is basically a token stream. The syntax
| requirements are just so that the compiler knows when the macro
| ends.
|
| https://doc.rust-lang.org/1.7.0/book/macros.html#syntactic-r...
| Ciantic wrote:
| It's using this: 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 wrote:
| whoa, so you can write like a DSL parser using the rust macro
| matcher syntax?
| dgb23 wrote:
| 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 wrote:
| 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...
| nulptr wrote:
| rust allows for procedural macros (basically a function
| that takes a token stream and returns a token stream, and
| yes you can do parsing in this funciton
|
| https://doc.rust-lang.org/reference/procedural-macros.html
| [deleted]
| quarantine wrote:
| As a lot of less-than/greater-than tokens
| [deleted]
| arkanciscan wrote:
| I eagerly await every single NPM package being rewritten in every
| single language just so someone can post a ShowHN about it.
| runawaybottle wrote:
| It's demo day everyday like kindergarten.
| sharpercoder wrote:
| 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.
| kolektiv wrote:
| Well, that's definitely a sweet-spot, but as a by-product of
| that, Rust is still a well-thought through language with a
| strong and logical type system, some very useful features for
| expressing domain models, etc. and a model of memory management
| which maps very well to WASM. So if you already know Rust, this
| is a short and logical step. If you don't already know Rust, I
| wouldn't learn it just to write web apps in - but if you do,
| you now have all the advantages of "same language client/server
| side" as well as the advantages of safety, good libraries in
| certain spaces, etc.
| Vinnl wrote:
| > I wouldn't learn it just to write web apps in
|
| I'm going to be looking into the other way around: writing a
| web app in it to learn it. Seems like a great use case that
| would make it easier for me to learn, as someone who has
| experience with web apps and not so much with desktop
| software.
| nilkn wrote:
| It's the reverse of what happened with JavaScript. In other
| words, JavaScript started on the front-end and then spread to
| the back-end because it was advantageous to have one language
| for both. One of those advantages is that folks who were
| experts in JavaScript were suddenly able to use their language
| of choice for back-end work too.
|
| Rust started on the back-end but is fairly likely to spread to
| the front-end in the future for the same reason. One of the
| advantages will again be that folks who are experts in Rust
| will be able to use their language of choice for front-end work
| too.
|
| Beyond this, I would argue that Rust's type system is a
| significant draw for many folks as well. I dare say it has a
| lot more potential than Elm, a Haskell-like language designed
| just for web development.
| stmw wrote:
| I don't think Rust is just for low-level development anymore,
| for example at Commure we have been using it very successfully
| for "enterprise app".
|
| So if you're already using Rust for the app backend, I think
| the interest is more about using the same language in the back
| and in the front. Since nowadays one usually wants a typed
| Javascript (e.g. Typescript) anyway, it is far shorter of a
| leap to Rust.
| k__ wrote:
| Predictability?
|
| As far as I know, Rust's WASM performance is much more uniform
| than JS'.
| the_gipsy wrote:
| A fast webapp is a selling point on it's own.
|
| Of course, maybe just because it uses WASM it doesn't
| automatically have to be faster - but this looks promising.
| skocznymroczny wrote:
| Possibility of sharing code between backend and frontend.
| hinkley wrote:
| Yes. Isomorphic code was always about having to prove the
| correctness of a smaller body of code.
|
| Web assembly will see a whole new round of people trying to
| do monoglot programming. Which I welcome, because I like
| JavaScript well enough but I don't like writing it all day,
| every day, for years at a time.
| danShumway wrote:
| A few advantages:
|
| - Rust compiles to WASM, not JS, so you can actually take
| advantage of its low-level nature in the browser for
| performance critical tasks within your app.
|
| - The Rust code you're writing is still statically compiled, so
| you still get to take advantage of Rust's typechecking and IDE
| features.
|
| - Some people just like writing Rust code more than Javascript.
| Part of the reason Javascript took off so quickly on the server
| was because there's a huge productivity boost from using one
| language everywhere. Similarly, if you love Rust but think that
| Javascript paradigms around prototypes, closures, or `this` are
| weird, you get to ignore that and take advantage of one of the
| best app distribution platforms in the world without learning a
| new language.
|
| I pretty solidly hold to the position that increasing language
| diversity on the web is a good thing. Particularly with Rust,
| since they've put in the work to have proper, accessible
| support that's still separating app logic from DOM layout and
| CSS styling. I'm really happy with how their community has
| approached building out Rust as a first-class language on the
| web rather than just as native language that happens to have a
| web compile target.
| muglug wrote:
| > you can actually take advantage of its low-level nature in
| the browser for performance critical tasks within your app.
|
| Yeah, but the problem is that 99.9% of front-end work is only
| performance-critical for DOM rendering (the 0.1% is stuff
| like video encoding & decoding) and WASM can't help with
| that.
| cogman10 wrote:
| > the 0.1% is stuff like video encoding & decoding
|
| In which case, rust still isn't a good fit for a front end
| library (Unless you are patching in support for a new codec
| into old browser).
|
| Frankly, the browser will have a faster version of the
| codec that can also take advantage of other hardware that
| you wouldn't want to expose to WASM.
| tanilama wrote:
| Precisely
|
| Talking about perf without understanding the problem domain
| is a common mistake Rust folks tend to make.
|
| I don't think there is enough push for people to switch to
| a new language just for performance sake in front-end land.
| JS ain't that bad, and performance is certainly achievable
| by careful and incremental optimization.
| droobles wrote:
| You should check out Glimmer and what they're doing with
| their byte-code components - I think the Glimmer vm in Rust
| would boost DOM rendering performance vs virtual dom
| implementations.
| K0nserv wrote:
| Have you used the modern web? We might not be building apps
| with "performance criticial tasks", but the modern web
| would benefit immensely from anything that improves
| baseline performance.
| muglug wrote:
| Yes, I use it all the time, but most websites are really
| simple things - for every figma.com there are a thousand
| e-commerce sites that do very mundane things.
| brundolf wrote:
| > 99.9% of front-end work is only performance-critical for
| DOM rendering
|
| There are two meanings of "DOM rendering" in the context of
| UI-as-a-function-of-state libraries: 1) generating the
| virtual DOM from data, and 2) modifying the real DOM to
| match it. Arguably there's even a 3) browser reflow as a
| result of those DOM changes.
|
| You're right that 2 and 3 can't really be helped by WASM.
| But 1 can, and while it's not _usually_ the bottleneck, it
| certainly can be. At my last company it was not terribly
| uncommon that fixing UI jank came down to eliminating
| unnecessary React render function calls because the sum
| total of them all - running the actual JavaScript logic -
| was taking too long. Assuming yew computes the virtual DOM
| in WASM (I don 't see how it could be otherwise), the
| performance increase could definitely be beneficial for
| certain highly-complex apps.
| ng12 wrote:
| Switching from JS to Rust will not give you a noticeable
| improvement in runtime speed, especially since V8 is
| absurdly well-tuned. If your JS logic was the bottleneck
| it's a good sign that the code was poorly architected and
| Rust cannot help you with that.
| brundolf wrote:
| Unless your claim is that WASM isn't actually faster than
| JavaScript - which I haven't personally verified but
| seems like a pretty shaky argument - you're not really
| making any sense.
|
| When you've got 10,000+ component instances on a page,
| tiny bits of render logic add up. You can identify
| whether actual JS logic is your bottleneck (and to an
| extent, which JS is your bottleneck) through profiling.
|
| The most common fix is to avoid calling render functions
| at all where possible. These are cases where the output
| of the render function will be identical to the previous
| output - which means React won't make any DOM changes -
| but where the render function will itself get called
| anyway. You can prevent this through better dirty-checks
| on props and state (shouldComponentUpdate, in React's
| case). Though if you're not careful, even those
| comparisons can become a limiting factor (not often, but
| sometimes). Immutable data structures like those in
| Immutable.js and pub/sub component updates like what MobX
| does can help ensure comparisons don't get expensive.
|
| Another trick is to do expensive operations like mapping
| over a large array ahead of time, instead of doing it on
| every render. Maybe you even need to perform your array
| transformation in-place with a for loop, to avoid
| allocating-and-copying. This is especially true if you do
| multiple array operations in a row like filtering,
| slicing, reducing. Memoization of data that gets re-used
| across renders is a generally helpful pattern.
|
| Another huge factor in this case is concurrency:
| JavaScript runs on the same browser thread as reflow and
| all the rest, meaning that all of this JS logic blocks
| even non-JS interactions like scrolling and manifests
| very directly as UI jank. React rendering cannot happen
| in a worker thread because React requires direct access
| to the DOM API (element instances, etc), and worker
| threads cannot share memory directly with the main
| thread; it's message-passing only (the upcoming React
| Concurrency project will help alleviate this problem, but
| doesn't directly solve it). Rust, on the other hand, can
| share memory between threads, meaning that in theory
| (assuming Yew takes advantage of this) renders can happen
| in parallel. Even if they don't, WASM already lives in a
| separate thread from the main DOM, which does mean it
| will probably incur some constant message-passing
| overhead, but it should never block reflow. And that
| would go a very long way towards preventing user-facing
| jank.
|
| The average web app doesn't run into these problems, and
| usually they can be optimized around, but when you do run
| up against these limits any across-the-board speed
| improvement that raises the performance ceiling can
| reduce the amount of micro-optimization that's necessary,
| reducing the cost in developer time and likely improving
| readability.
| ng12 wrote:
| That is exactly what I'm talking about. Everything you
| referenced is an architecture problem, not a JavaScript
| problem. You can write slow apps in JavaScript+React, you
| can write slow apps in Rust. Unless milliseconds matter
| (doubtful in browser-land) you won't get the kind of
| performance you want for free just by switching
| languages.
| brundolf wrote:
| Milliseconds absolutely matter. Every React render cycle
| (the entire relevant subtree from top to bottom because
| again, it's all synchronous) that takes more than 16
| milliseconds presents to the user as a dropped frame. In
| fact that 16ms also has to include any DOM updates and
| the resulting browser reflow, which you have much less
| control over and are usually more expensive than your JS,
| so really the window is smaller than that.
|
| Also, many of the optimizations I listed above can make
| code less readable in small ways. Many of them are things
| you should not do eagerly (premature optimization is the
| root of all evil), and should only go back and do once
| you've identified a specific problem. If an across-the-
| board speed increase prevents them from ever becoming
| problems, that's a win.
|
| If you're thinking I'm a JS-hater, you're wrong. I think
| JS is a good language and I love using it where it's
| appropriate. But there are some usecases that benefit
| from a faster technology, and it's absolutely bonkers to
| try and argue that that technology shouldn't exist
| because "you can still make something slow with it if you
| really try".
| K0nserv wrote:
| 16ms with 60fps targets, but there are higher frequency
| displays hitting the markets so that target might shift
| to 8ms or lower in the future.
| CryZe wrote:
| Rust compiled to WASM is still vastly faster than JS
| (often even by about 10 times or more). But yeah you
| probably should be fixing your JS at that point if it
| matters that much.
| K0nserv wrote:
| Yew already seems to out perform most other frontend
| frameworks and view libraries[0]. More importantly it
| does this while still paying the serialising cost when
| moving from WASM to JS and back. This cost is set to go
| away when WASM to JS interop improves and will make Yew
| even faster.
|
| 0: https://github.com/DenisKolodin/todomvc-perf-
| comparison
| adamredwoods wrote:
| I would rather have a fast way to debug than speed execution
| when dealing with single page apps. Execution speed isn't a
| concern, it's payload size and TTR speed that we care about
| when working with a SPA, and this wasm code is over 200,000
| lines.
|
| What a nightmare to debug!
| gavinray wrote:
| > 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.
| dom96 wrote:
| I was very surprised to find this. I have done some WASM
| experiments and found that JS is very often incredibly well
| optimised, often running faster than WASM. Do not
| underestimate the years of JIT optimisations that went into
| V8 and other JS engines.
| gavinray wrote:
| Same, do NOT underestimate V8 black magick + optimizations.
|
| I've done a fair bit of benchmarking/performance
| experimentation with compiling Rust/Go/Zig etc to WASM
| (including with SIMD or parallelization enabled).
|
| It'll be really interesting watching the progress of V8 +
| WASM SIMD proposal, it's been enabled behind a flag in V8
| for some time now.
|
| https://v8.dev/features/simd
| paulgb wrote:
| 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/
| danShumway wrote:
| > There's a small-but-non-trivial amount of overhead involved
| in calls between WASM code and the DOM API's, plus
| (de)serialization
|
| My understanding is that this is going to get a lot better in
| the future though -- last I checked the plan was for WASM to
| eventually have direct bindings to DOM APIs, at which point
| you won't need to interact with JS at all.
| gavinray wrote:
| That's true, if the Interface Types proposal gets accepted
| that overhead should be significantly less. At that point
| it'll get really interesting what the potential performance
| looks like for DOM-interaction heavy apps.
|
| https://github.com/WebAssembly/interface-
| types/blob/master/p...
|
| I wouldn't think it's far behind. The Multi-Value proposal,
| which had huge ramifications, was recently accepted in
| April so WASM is clipping along at a fair pace still.
|
| https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/
| markdog12 wrote:
| Firefox Nightly and Chrome Canary both recently landed
| multi-value and reference types:
| https://webassembly.org/roadmap/
| pmarcelll wrote:
| I haven't seen it mentioned, but memory usage might also be
| better, and I have a good real-world example to show why it
| still matters in 2020: we use Jira to manage our software
| projects and our team's project manager uses a newish MacBook
| Air with 8GB of RAM. Jira is written in React and a single page
| for a ticket can easily eat 150+ MB of memory (it's even more
| for Jira boards). Our PM regularly complains about the slowness
| of his machine and I think Jira is a big contributing factor. I
| don't think much of the memory is used for presentation (so it
| might not be React's fault), but rather for business logic
| processing a large amount of data. And IIRC calling a simple
| `filter()` on a JS array creates a new array for the operation
| while Rust uses iterators.
| paulgb wrote:
| Although Rust is most known for bringing safety to low-level
| development, it also happens to be a nice, modern programming
| language with things like match statements and sum types. I
| find myself using it frequently for things I used to do in
| Python, with greater productivity once a program reaches the
| point that I can't keep it all in my head.
| doomedlung wrote:
| What are the debugging tools like for this?
| pedrocr wrote:
| 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.
| k__ wrote:
| _" took us 15 years of being flamed every time you pointed out
| you didn't like Javascript"_
|
| Rust is a special case here, light weight, and loved by JS
| devs.
|
| I'd still "flame" anyone who wants to drop a C# or Java VM on
| their users.
| balfirevic wrote:
| I still hope that we'll get a lightweight (or lightweight
| enough, at least) .NET VM on WebAssembly. Blazor is far from
| lightweight currently, but it's runtime wasn't purposefully
| written for the task and is based on Mono.
|
| Rust certainly has an advantage here, as it was design to not
| require a runtime system.
| pansa2 wrote:
| > _Rust is [...] loved by JS devs._
|
| Is it? That's interesting, because to me the two languages
| seem to be polar opposites.
| runawaybottle wrote:
| You know what's even more interesting? Using a low level
| language for no obvious performance reasons in the browser
| (as in, what performance critical thing are you solving?).
|
| I just remember having to do a lot of my college classes in
| C++, where some of our basic programs needed variables to
| be constantly cast into another type just to do something
| with it. I remember, man, I cannot wait to have to deal
| with this when I parse json data from an api request, bring
| it on.
|
| I am JS developer, and apparently I love Rust.
| dmit wrote:
| I start missing Rust approximately 30 minutes into every
| new Typescript project I work on because there's no good
| alternative to Rust enums (and other benefits that come
| with them, like pattern matching). I can't derive basic
| traits for my data, like specifying equality or a
| canonical ordering. I can't define math operations for my
| calendar types, my units of measure, or my 3D graphics
| structs. (De)serialization of data is a minefield.
|
| In what world is Rust a lower level language compared to
| JavaScript at this point?
| StreamBright wrote:
| >> no good alternative to Rust enums
|
| So you are missing a basic feature that a bazillion other
| languages can give you. I am still amazed how people
| think that the ML features in Rust somehow new
| inventions.
| dthul wrote:
| There are no good alternatives in Typescript. Nobody
| claimed that there are no other languages with enums.
| _underfl0w_ wrote:
| > In what world is Rust a lower level language compared
| to JavaScript at this point?
|
| The embedded one. Can't write bootloaders or kernels in
| JS. I mean, maybe you _could_ but... why would you?
|
| (On mobile here, bear with me if no newlines came
| through)
| GordonS wrote:
| Personal opinion: Rust seems as bizarre choice as C/C++
| would be for web apps, regardless whether it's for the
| frontend or backend - I'd personally _much_ prefer to use
| a higher-level language like C#, F#, Go, Scala or Kotlin.
| k__ wrote:
| Well, Rust is higher level than C, but not nearly as
| heavy as the others you mentioned.
| StreamBright wrote:
| F# turned out to be a great option for us, we combine it
| with Elm and they work very well together.
| kroltan wrote:
| The qualms you describe are with static typing, not
| necessarily low-level languages.
|
| And considering TypeScript is so favored as a way to
| "herd the cats" of JavaScript typing, it seems not
| everybody shares your opinion.
|
| People go to Rust not necessarily because it's "fast" or
| "low-level", but possibly because it has a expressive
| type system that lets you be precise and correct without
| having to be verbose.
|
| Sure, the fact that it can be used at the low-level and
| for performance-intensive applications can be a very good
| thing, but it is far from Rust's only merit.
| steveklabnik wrote:
| Just because that was your C++ college experience, does
| not mean that reflects the experience of C++ today, let
| alone Rust today.
| steveklabnik wrote:
| When you're looking for a new technology to invest in,
| something that's very different from your current focus can
| be quite valuable, as it gives you a lot to learn, a lot of
| new things you couldn't do before, etc.
|
| "loved by JS devs" is maybe a bit strong, as there are a
| LOT of JS devs, but we do enjoy a lot of JavaScript folks
| getting involved with and/or using Rust, and I and others
| have given a bunch of talks about Rust (with and without
| wasm) at JavaScript conferences that were well received.
| jimmaswell wrote:
| What killer features does Rust have that I'm missing out
| on writing web apps in plain old Javascript? The only
| impressions I got trying to learn Rust are that it's very
| inconvenient, esoteric-looking (syntax is garbled about
| randomly from the norm for no apparent reason other than
| to be different - why go to such pains shortening
| everything like pub and fn when fn x -> int takes up so
| much more space than int x?), and really just not
| something I'd want to go through just to write a webpage.
|
| Static checking etc. is nice but what's wrong with things
| like typescript? Do we really want web libraries
| fragmented into a million languages?
| woah wrote:
| A dislike of the function keyword used in a language
| seems like an incredibly strange and arbitrary way to
| make a decision about it
| steveklabnik wrote:
| Just because they're JS devs, doesn't mean that they're
| doing web development with Rust, to be clear. That's part
| of the whole "expanding what you can do" bit.
|
| > randomly from the norm for no apparent reason other
| than to be different
|
| This has been written about in a number of places, and I
| don't have time to get into it, but a lot of languages
| are trending in this direction with syntax because it is
| more regular in a language that contains pervasive type
| inference. It's not random.
|
| > Static checking etc. is nice but what's wrong with
| things like typescript?
|
| Typescript still has node (or deno, still V8) as a
| runtime, so you're still dealing with its runtime, and
| all the cons (and pros) there. Additionally, the
| guarantees you get out of TS and Rust are different, as
| they have pretty different type systems, even if they're
| both statically typed, and TS is closer to Rust than it
| is to JS.
| dgb23 wrote:
| The Rust ecosystem shares some characteristics and idioms
| that are familiar and appealing to JS developers, like:
|
| - leaning on (some) pragmatic FP concepts
|
| - modern tooling and dependency management
|
| - very _approachable_ and solid documentation, books etc.
| (see MDN, Rust by Example, Rust Book, Eloquent
| Javascript...)
|
| - both can target the browser (well)
|
| - Mozilla has a very good name in the Web dev community. I
| think at least; this is definitely relevant to me.
| [deleted]
| pcan77 wrote:
| I promise you that the amount of JS devs who LIKE Rust is not
| very high. I cannot imagine going from a language like JS or
| TS to the confusing syntactical monster that is Rust.
|
| I realize this is an unpopular opinion, but JS/TS is WAY more
| human readable than Rust is. It's almost the equivalent of
| programming in C for the browser. Plus, literally anything
| you could ever want to use in already in the JS ecosystem and
| doesn't have to be reinvented in Rust.
| skratlo wrote:
| > literally anything you could ever want to use
|
| ...so but how's the quality of npm ecoshitstem? last time I
| heard you guys had some trouble in paradise, plus
| everything noteworthy is owned by either facebook or
| google, both having huge antitrust issues lately
| bilkow wrote:
| I do not disagree on the amount of JS devs who like rust
| (how many even know that rust exists?), what you think is a
| syntactical monster I find more readable than JS (except
| when generics are abused, which is rare in my experience).
| Just by having no parenthesis around "if" it becomes a lot
| cleaner, and together with anonymous / arrow function
| syntax in js it becomes even more confusing. Its still very
| subjective, but if you're going just for clean syntax, I
| feel like python is the real winner.
|
| Also, explicitly borrowing in method signatures is a BIG
| plus for me as its a lot easier to understand an API when
| its clear whether it mutates or not an argument, as opposed
| to JS where number arguments just cannot be mutated and
| pointer arguments (such as arrays) always can be mutated. I
| find understanding random github projects a lot easier in
| rust than js or python.
|
| I'm not saying you should use rust, but many like rust
| specifically because of its readability and even find
| they're more productive in the long term because of its
| "high level" features and explicitness (although LEARNING
| it is a lot harder).
| StreamBright wrote:
| >> Rust is a special case here, light weight, and loved by JS
| devs.
|
| Is there any data on that?
| Thaxll wrote:
| "where you can choose whatever language you want to program for
| the web" if by chosing meaning doing PoC during the week-end
| maybe ... for real work we don't have a choice.
| monadic2 wrote:
| I mean, don't do this for other reasons, like it's an
| accessibility nightmare.
| riquito wrote:
| You are getting downvoted because the rendered page is HTML,
| which has the same accessibility properties as always
| samcgraw wrote:
| Other than 10% of the globe unable to run wasm, what
| accessibility concerns come to mind here? Are there any that
| wouldn't also apply to a SPA that uses JS to manage the DOM?
| steveklabnik wrote:
| Some people believe that wasm will encourage people to turn
| web pages into one big <canvas>, which would be quite a
| hit. I don't personally believe that, though.
| Shared404 wrote:
| I had in fact considered playing with and possibly
| deploying something like this if I liked it.
|
| I'd like to thank this thread for reminding me why that's
| probably not a good idea.
|
| Are there any good resources to read up on for making
| sure accessibility is good in <canvas>? I assume you'd
| have to implement it yourself.
| rikroots wrote:
| > Are there any good resources to read up on for making
| sure accessibility is good in <canvas>
|
| whatwg.org[1] is less than helpful when it comes to to
| describing how to make sure canvas elements are
| accessible; MDN[2] is a little more helpful. tl;dr: it's
| a lot of hard work.
|
| I have found some relatively useful posts in various
| places (eg: [3]) for people (like me) who don't like
| being told not to do something. These articles generally
| date from around the mid 2010s but, given that there has
| been little development in the <canvas> world since then,
| their advice is still good today.
|
| [1] whatwg -
| https://html.spec.whatwg.org/multipage/canvas.html
|
| [2] MDN - https://developer.mozilla.org/en-
| US/docs/Web/API/Canvas_API/...
|
| [3] - https://developer.paciellogroup.com/blog/2015/02/ht
| ml5-canva... - including this link because post was
| updated in 2020
| Shared404 wrote:
| Thanks, I've favorited this.
| steveklabnik wrote:
| I have no idea personally, I imagine you'd have to
| implement it all yourself, yes, and I don't even know if
| the proper hooks are there, honestly.
| untog wrote:
| > It only took us 15 years of being flamed every time you
| pointed out you didn't like Javascript
|
| I don't think that has ever been an unreasonable reaction. Nor
| is it all that unique: if you want to do iOS development in
| something other than Objective C or Swift then the iOS dev
| community is going to tell you that you're making a mistake.
| And they're often right.
|
| I've used Rust. I like Rust a lot. But one thing I don't see
| mentioned in this article at all: "debugger". Or "inspector".
| The web development stack has some incredible tools to aid in
| development, debug code, memory usage, etc. etc. Can you still
| use them with this single page app? If not, what strength is
| Rust bringing here that you can't achieve with the standard web
| dev stack?
| milesvp wrote:
| Not sure about this particular instance, but I can tell you
| about a project I'm working on in C++ that compiles down to
| wasm.
|
| I was working on some prototype code that would eventually
| run on an embedded device, so C++ was the obvious choice for
| that work. Getting it all running in a linux app using SDL
| was a good starting point, but then I needed to collaborate
| with some very non technical people. At that point using
| Emscripten to compile the code to run in the browser ended up
| being useful work. I can upload the resulting html, js, wasm
| file to a webserver and anyone with a link can take a look.
|
| Most of the debugging I do outside of the browser. But I was
| able to do some debugging using the web inspector.
|
| But you're right. I'm not sure that the tooling is quite
| there yet for a more generic single page app. My code tends
| to destroy the browser if left open, and it's hard to tell
| why (most likely something memory related that doesn't
| translate well).
|
| I'm tempted to do more experimenting with cross compiling to
| wasm, but I'm not sure if my goal was production code on a
| browser I'd target anything but HTML5 CSS and JS+framework.
|
| That said, there's something to be said to being able produce
| a webapp while having no direct need for HTML & CSS. In the
| article author was still using HTML and CSS, so mostly the
| Rust was to avoid JS. My use case allowed me to not have to
| know HTML to produce a page. There's also lots of precedent
| with game devs using Unity or Haxe tool chains to cross
| compile to the browser.
| ar_lan wrote:
| I think the same could be said about node, though. A big
| _ideal_ would be to be able to use the same libraries, code,
| tooling, etc. instead of needing to fragment with multiple
| languages /impls/skills/tools/etc.
|
| I don't know why anybody would choose Javascript for a server
| except for the fact that it's also Javascript, so you can
| largely share your stack between front-end and back-end. But
| I'm not convinced Javascript is all that great of a choice
| compared to most other languages out there for backend
| development, albeit it being very popular.
| doomedlung wrote:
| oh yeah, why's that then?
| vlovich123 wrote:
| 1. You can integrate existing high-quality libraries more
| natively
|
| 2. You can write your backend and front end in the same
| language which can be appealing to increase the ability for
| more people in the org to contribute code (eg you don't need
| to hire a traditional web developer).
|
| 3. Tooling in rust is different. I'm sure the state of
| debugging and inspecting WASM will get better (I don't
| actually know the state) but you're now not limited to the
| tooling just in the browser and you can run all of that
| offline in a server
|
| 4. Performance
|
| 5. Tooling isn't there yet but it's an area of active
| development. Debugging in Chrome: https://developers.google.c
| om/web/updates/2019/12/webassembl...
| untog wrote:
| > you're now not limited to the tooling just in the browser
| and you can run all of that offline in a server
|
| When it comes to DOM interaction (a key part of this
| article) you absolutely can't.
|
| I see the logic in compiling a native library to Rust and
| using it via WASM. It's the part where you bring the whole
| DOM WASM-side that I'm sceptical about. As you say, tooling
| isn't there yet. Is performance even there yet? Last I
| heard WASM<->DOM interaction incurs a performance penalty.
| Right now it all feels like a "because I can" capability.
| I'm not saying that will always be the case, but for right
| here and now I'm sceptical.
| swsieber wrote:
| You can write your stuff in such a way to minimize the
| WASM<->DOM interactions. And there is a speed benefit for
| pure WASM stuff, so I can see it being a net win if
| you're using a good framework that pushes you in the
| right direction.
| tyingq wrote:
| I suspect it won't really hit until the changes that enable
| direct DOM access, and things that make dynamic languages
| easier to implement in WASM. These things:
| https://github.com/WebAssembly/proposals/issues/16
| throwaway234101 wrote:
| Is that still happening? It looks like it's been on the back
| burner for a few years now.
| sushshshsh wrote:
| It's the year 2020 and I'm still out here writing JSP, PL/SQL,
| and VB6 lmfao
| jaywalk wrote:
| Please tell me this is a joke.
| est31 wrote:
| There are two phases of a technology: the adoption for new
| projects phase, and the legacy phase. In the first phase,
| new projects dominate the programming activity in the
| technology. In the second phase, maintenance and
| improvement of already existing codebases dominates the
| activity. Technologies like jsp are in that second phase.
| sushshshsh wrote:
| Wish it was! My life is full of Dim iX As Integer and
| CURSOR AS right now and it's pretty gross. But it's better
| than writing css or react at least.
| cdelsolar wrote:
| um no it's not
| AndrewUnmuted wrote:
| Can't we agree that they're both just awful?
| laurentdc wrote:
| I know of at least two insurance companies in my country
| that still have their administrative software written in
| VB6 (probably along with some shoddy web app for IE8).
|
| Also see "IT runs on Java 8"
| https://veekaybee.github.io/2019/05/10/java8/
| jermaustin1 wrote:
| I've actually been wanting to do a video series on using VB6
| to build a modern web application. It would have a Windows
| Form GUI obviously.
| arethuza wrote:
| A company I used to work for did an acquisition where the
| company being acquired had written their own web server in
| VB6. I never did find out why...
| sushshshsh wrote:
| Wtf how is more important than why actually LOL. The why
| probably involves consultants and a lot of powerpoint
| AndrewUnmuted wrote:
| I found this [0] suspicious-looking source code from 2002
| that may be able to give some answers.
|
| [0] https://www.developerfusion.com/code/2184/dm-web-
| server/
| dom96 wrote:
| Are we? There are and have been plenty of languages that target
| JavaScript for many years now. What does webasm actually enable
| that wasn't possible before?
| gameswithgo wrote:
| As per usual in the world of languages, nothing new is
| possible, but things can be easier and perform better.
| camgunz wrote:
| This is what WebAssembly has to say about it:
| https://webassembly.org/docs/faq/
| flohofwoe wrote:
| Performance (asm.js was pretty close but required special
| support from the JS engine too).
|
| But maybe more importantly: WASM frees Javascript from the
| future burden of being both a human-friendly programming
| language, and a machine-friendly compilation target.
| pjmlp wrote:
| Plugins already made that performance possible.
| devwastaken wrote:
| It took 15 years for llvm and wasm to be made. Sandboxing and
| cross compilation in a way that isn't crazy has always been a
| big problem for allowing the web to just run whatever it wants.
| Though I'm still skeptical on wasms real security given its use
| in browsers is independently implimented, non seperable from
| the Js stack, and we're still using JIT. Everyone else goes and
| impliments their own runtime too.
| ChrisSD wrote:
| Independent implementations are important. We don't want
| another Flash.
| pjmlp wrote:
| "Everything Old is New Again: Binary Security of
| WebAssembly"
|
| http://www.software-
| lab.org/publications/usenixSec2020-WebAs...
| amelius wrote:
| We could as well have used VirtualBox instead to sandbox
| applications on the web, and run them at near-native speed.
| No need for LLVM and WASM. The only thing needed would be to
| incorporate VirtualBox into the browser.
| derefr wrote:
| Besides VirtualBox being an single implementation rather
| than a standard, that wouldn't have worked--VirtualBox is
| just a hypervisor, not an emulator, and so "has" whatever
| ISA the host has. So you'd need separate binaries for x86,
| ARM, etc.
|
| Google did a much better version of this, without these
| problems; they called it PNaCl. People still didn't like
| it, because LLVM IR is still not technically a formal
| standard, only a de-facto one.
| amelius wrote:
| > So you'd need separate binaries for x86, ARM, etc.
|
| I don't see this as a fundamental limitation.
|
| Perhaps I should have said QEMU instead of VirtualBox.
| derefr wrote:
| Google first developed NaCl, and that was rejected
| because of this problem. The main driver, I think, was
| that you can't predict the computing landscape. Just
| because we have certain common architectures around right
| now, doesn't mean there won't be _new_ architectures
| around 20 years from now, and /or doesn't mean the
| architectures around now won't be dead by then.
|
| The thing about the web, and web standards, is that web
| clients (browsers) are expected to be able to work with
| web apps, on a common "web platform." Users expect to be
| able to take an up-to-date web browser and point it at
| any arbitrary old website, and have it work. And web
| platform engineers agree that this is how things should
| be, and make sure that browsers do everything they need
| to do to make this possible.
|
| But having the possibility of a web app delivering one of
| N different binaries for each of a bevy of random ISAs--
| and no requirement to support _all_ ISAs, only whichever
| ones the site 's author felt like deploying--means that
| the browser authors of 20-years-from-now, to support
| users' expectations of arbitrary old web apps "just
| working", would need to ship N virtual-machine
| interpreters, one for each ISA that people ever compiled
| web binaries for.
|
| Basically, it'd be a not-quite-combinatorial explosion in
| VM/runtime implementation work, which would decrease the
| quality that any one VM/runtime could have (which is
| really bad when those very implementations are one of the
| main sources of security vulnerabilities for attacking
| computers today.)
|
| And, even then, there'd still always be sites broken
| because they shipped native code only for a platform
| nobody ever bothered to build support into browsers for;
| or used an instruction only available on some extension
| of an ISA that only appears in some particular
| proprietary chipset.
|
| The web-standards people all agreed that, if you were
| going to have "object code for the web", it was much
| better to constrain the web to one "abstract machine"
| ISA. All the browser authors could then put all their
| effort behind implementing just one high-quality
| runtime/VM serving that abstract machine.
|
| The only dispute, after that, was what form the ISA would
| take. Google suggested LLVM IR, and was shot down. WASM
| came up with their own proposal, and it got accepted,
| probably mostly _because_ it was a proposal for a
| standalone formal standard, rather than a de-facto part
| of something else.
|
| Probably, any ISA that was standalone in a similar way
| could have been used instead of WASM. But that is a
| surprisingly rare quality in an ISA. (For example,
| neither JVM nor CLR bytecode is a standard independent of
| the platform/runtime it's a part of. You can't become a
| member of the "JVM ISA steering committee", only a member
| of the _Java_ working group.)
| wtetzner wrote:
| > because LLVM IR is still not technically a formal
| standard, only a de-facto one.
|
| I'm not sure if this is still the case, but last time I
| looked into it LLVM IR also changed between releases in
| ways that were not backward compatible.
| steveklabnik wrote:
| It is both not platform-independent, and not stable.
| That's not to say that this means it's bad! It was just
| not designed for that kind of purpose whatsoever.
| arkanciscan wrote:
| When you figure out that you still have to use the DOM and CSS
| you're gonna turn right back around like grandpa Simpson.
| gameswithgo wrote:
| don't _have_ to, can use webgl.
| untog wrote:
| Bye bye, accessibility!
| runawaybottle wrote:
| That and ui/ux programming. Gotta make sure you are
| displaying the right stuff, and be meticulous about your UI
| events/interactions.
|
| JavaScript might suck, but it's got all the normal basic shit
| other languages have. Loops and shit, variables and stuff.
| You guys aren't complaining about a little old language,
| you're complaining about UI development and how tedious it
| can actually be if you want a professional level of polish.
| alsdkfjkqjwer wrote:
| ...and to reset the score, yet again, on
| usability/accessibility. sigh.
| gedy wrote:
| It's funny because non web folks complain about Javascript
| fatigue and no standard libraries/approaches - so now on top of
| that we are going to mix in other languages and everyone
| bikeshedding the same thing in N languages? Seems maintaining
| apps with all this code is going to get a lot harder.
| pas wrote:
| There is/was Scala.js too, and other similar things that
| "transpile" to JS.
| loxs wrote:
| Funny thing is, this is not strictly needed anymore, as
| TypeScript is probably the best language in existence right
| now.
|
| edit: OK, maybe not compared to Rust... but here it wins by
| ease of learning.
| root_axis wrote:
| 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.
| pjmlp wrote:
| This was already possible with browser plugins.
|
| Active State had ActiveX plugins for using Perl and Python
| instead of JavaScript.
| bitexploder wrote:
| The tools are sophisticated but also much harder to use.
| Things like modern front end JavaScript and Kubernetes are
| very complex beasts to tame. Their value is dubious for many
| use cases people choose them for, but they are undeniably
| powerful tools that advance the state of art by a lot. Same
| with NoSQL. It became hyped and overused but some really
| powerful and easier to use technology eventually emerged from
| it and gave us things like Redis, Redis now is a part of most
| modern web app stacks. I still just use Django and a lot of
| server side HTML templates. Developers often have a hard time
| knowing when to use a given technology and often end up
| bringing tech into their stack they don't need. This plays
| out in 5-8 year cycles. Meanwhile RDBMS and simple things
| like Django with minimal front end JavaScript can still solve
| the vast majority of problems people have in the web app
| space. It's the classic hype/adoption/cynicism cycle we have
| had forever.
| root_axis wrote:
| This just reads to me like "my personal preferences are
| good and things I don't like are hyped up and of dubious
| merit".
|
| If it were me, I'd prefer rails to django any day of the
| week, that's a personal preference, but if we're talking
| about building an SPA you're typically going to be building
| a worse solution if you can't SSR your client views, which
| you need a js backend to do.
| wtetzner wrote:
| I'm not sure exactly what you're referring to, but being
| able to run Rust both on the server and client should
| allow SSR, no?
| bitexploder wrote:
| To some extent, that is true regarding my personal
| preferences, but being in tech and writing code for over
| 20 years teaches you a few things. Developers should be
| more picky about tools they adopt without becoming too
| cynical or dismissive of new technology. Every so often
| you have to go through your technology shed and be sure
| you aren't being biased towards existing comfortable
| tools. It's nice to work out of your comfort zone and
| learn new things, but it's also nice to be very efficient
| at problem solving. When I feel a new tool or technology
| crosses a threshold from hype to having proved its value
| I tend to take it seriously and learn it. I try to avoid
| getting sucked into tech stacks that I don't think will
| make it. Some times I am wrong, but usually not. I could
| have made my description of technology more generic, but
| in general, things like
| Django/Rails/Postgres/MySQL/NodeJS/Redis are battle
| proven technology that won't let you down. IMO that is
| the hardest part about being a lead engineer / CTO --
| knowing when to say Yes and No to given technology stacks
| :)
| root_axis wrote:
| I agree with everything you've written here, particularly
| your process of tool evaluation and refinement. My only
| push back is with respect to the way you characterized
| the merit of "overhyped" tools (in your previous comment)
| that didn't line up with the productivity profile of your
| personal experience. I agree that
| Django/Rails/Postgres/MySQL/NodeJS/Redis are all reliable
| tools, but I am not a fan of the philosophy that labels
| other people's work as unnecessary or harmful simply for
| existing outside the pantheon of worthy tooling.
| there_the_and wrote:
| _> if we 're talking about building an SPA you're
| typically going to be building a worse solution if you
| can't SSR your client views, which you need a js backend
| to do._
|
| I have not used React with Rails and maybe I'm
| misunderstanding your comment, but the react-rails readme
| includes a section about SSR via ExecJS and integrated
| with Rails:
|
| https://github.com/reactjs/react-rails#server-side-
| rendering
| root_axis wrote:
| ExecJS functions as a JS backend in this case, its just a
| ruby interface for node/rhino/v8 that's a little bit
| clunkier to utilize.
| there_the_and wrote:
| That is obvious (it's in the name). The way your comment
| is phrased reads to me like you are saying that one can't
| use Rails and has to switch to a full JS backend for SSR.
| If that's not what you are saying, then it's unclear what
| you are actually saying and why you juxtaposed Rails /
| Django against a JS backend.
| root_axis wrote:
| My point is that you literally cannot SSR your client js
| views without a js backend, so node has a clear
| engineering purpose in this respect. Yes, you can import
| a second backend into your main backend to avoid writing
| node, and that's fine, maybe your team is mostly made of
| rubyists or maybe your existing code base is ruby,
| there's nothing wrong with this approach, but it is more
| complication and layers of abstraction than just using a
| js backend if you must build an SPA.
| there_the_and wrote:
| _> import a second backend into your main backend_
|
| This is not typically how the term "backend" is used in
| this context. Most mature apps will use a variety of
| tools and services built in a variety of languages, but
| this is not referred to as "importing a second backend."
| In fact, your comment is apparently the first use of the
| phrase "import a second backend" on the entire internet:
| https://www.google.com/search?q=%22import+a+second+backen
| d%2...
| root_axis wrote:
| I'm speaking metaphorically. When I say "import a second
| backend" I'm saying that the thing being imported into
| the ruby backend is literally a wrapper around the exact
| same runtime that is typically used to run js backends,
| the corollary being that the "ruby" part is unnecessary
| added complexity from an engineering perspective unless
| you have some other compelling reason to use ruby (which
| is certainly possible).
| [deleted]
| setr wrote:
| I've never been fully confident in knowing what SSR
| refers to -- but its just the creation of static html on
| the server, right? As opposed to shipping a bunch of
| async dom updates contained in a js script executing on
| load, client side
|
| But if I have it right, I have no idea why a JS backend
| would be required to do SSR; this is exactly the same
| domain of work php, rails, django have always done,
| without node.js needing to enter. For an SPA (which I
| believe is just a bunch of js fetching data from JSON
| apis and rendering client-side), you'd need JS to handle
| client-side rendering, but if you can replace that with
| WASM (when it has DOM support)... I don't see why you'd
| need JS anywhere
|
| FYI I'm defining everything because I'm pretty sure
| there's a mistake somewhere in my understanding of the
| problem
| steveklabnik wrote:
| Nah it's used in two related, but kinda confusing ways,
| it's not just you:
|
| Traditionally, it means rendering your HTML on the
| server. Exactly what you're saying.
|
| It also refers to a specific technique that's used to
| implement rendering your HTML on the server by
| effectively running your client side app server side,
| then shipping its output. This requires some work to get
| right, and so it's presented as a feature of client-side
| libraries/frameworks.
| setr wrote:
| Ah
|
| The actual client code is being executed.
|
| Wait thats just weird -- if you're effectively removing
| the work from the client to the server anyways, such that
| its only executing on the server... I don't see what
| you've achieved beyond the original writing of standard
| language-agnostic SSR -- that you can design everything
| client-side, and conveniently migrate the heavier work
| serverside without interruption/rewrite?
| nwienert wrote:
| It gives you the best of both worlds - fast initial load,
| accessible, works without JS. But then also get all the
| client side goodness - highly interactive views,
| animations, and far less bytes transferred for subsequent
| page loads. Plus, writing a complex frontend is simply a
| far better experience in something like React than in
| Ruby, Python, PHP, etc.
|
| Finally, it lets you also render them to React Native
| using a lot of shared code. And you can share code
| between your backend APIs, etc.
|
| To be honest, I'll take Typescript over anything, even if
| it wasn't the default for the web. It strikes the perfect
| balance of flexibility, concision, safety, debugging ux,
| and has a huge ecosystem to boot. I think client side JS
| these days if anything is underrated and the WASM hype
| won't change much - if you want a lightweight, accessible
| app then doing a SPA in JS (with SSR) is actually not
| even a compromise, it's truly superior to any
| alternative. Now, with a big caveat: you need to invest
| to get it all set up properly. No one has really
| "railsed" it yet, as far as I can tell.
| steveklabnik wrote:
| > such that its only executing on the server
|
| It's not, it can run on both. You render on the server
| for the initial page load, and then on the client for
| every page after.
|
| Or not! The point is, now that you've unlocked both, you
| can use either one, in the way that works best for your
| application, in whatever ratio makes sense.
| kristiandupont wrote:
| SSR typically refers to server side rendering of a single
| page app. I.e. render the HTML for a given route of an
| SPA. For that to work, you need to be able to execute
| your SPA code on the server which will be JS. You are
| right that WASM will change all of this, but the
| ecosystem is not mature yet.
| vmarsy wrote:
| > I've never been fully confident in knowing what SSR
| refers to
|
| https://developers.google.com/web/updates/2019/02/renderi
| ng-... is a great resource on the subject.
|
| You can be fully Server-side (regular php), you can do
| full JS client-side rendering, and you can have hybrids
| that mix both.
| airstrike wrote:
| > If it were me, I'd prefer rails to django any day of
| the week, that's a personal preference
|
| This is totally not what the parent is getting into. It
| seems like your comment reads much more like "my personal
| preferences are good" than the parent
| root_axis wrote:
| They complain about Javascript and Kubernetes then praise
| Django and Redis, all in the abstract without any
| consideration for the totally different problems these
| tools actually solve. I injected my own personal
| preferences in-kind but labeled them as preferences
| instead of slamming other tools as overhyped and without
| merit.
| Scarbutt wrote:
| _but if we 're talking about building an SPA you're
| typically going to be building a worse solution if you
| can't SSR your client views_
|
| Is not worse, is fine. Mostly depends on the
| requirements, why go the extra complexity of SSR if you
| don't need it?
| putnambr wrote:
| Most of the time SSR gives massive web accessibility
| benefits. Ignoring web accessibility because you don't
| want to implement SSR is likely a worse solution for a
| large portion of your userbase.
| root_axis wrote:
| That's why I said "typically". One of the biggest
| complaints about SPAs is the perceived slowness due to
| the app loading and rendering assets in the browser, as
| well as the typical HN noscript complaints, as well as
| accessibility issues, SEO issues, and other problems
| related to back button behavior and url routing. SSR
| solves all of these troubles.
| learc83 wrote:
| 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.
| tbugrara wrote:
| It's 2020 and I still see this "churn in frontend web
| frameworks" mentioned. I don't see how this is true
| anymore. The churn was very real in the early 2010s, but
| these days almost all web development is done in React [1].
| If not React, it's either Vue, Angular, and Ember. I'm sure
| there are a lot of niche frameworks out there that are in
| use, but that's not what churn means. As a web developer
| you can learn React once and never have to pick up another
| framework again pretty easily.
|
| Not to mention that at this point the complexity of web
| development isn't exclusively held within your framework
| choice. Thinking about global state, eventing, and
| architecting your project are where the real hard problems
| are.
|
| [1] https://2019.stateofjs.com/front-end-
| frameworks/#front_end_f...
| onion2k wrote:
| _None of that eas necessary for WebAssembly to be
| developed._
|
| Theres no churn in WebAssembly tooling and frameworks _yet_
| , because WebAssembly has yet to make a big impact on many
| front end devs. We _will_ see the jQuery-but-WebAssembly
| for making binding easier, Bootstrap-but-WebAssembly for
| making UIs and React-but-WebAssembly for managing
| components (not actually those libraries, but equivalents)
| come along and they will get adopted to make applications
| that serve large bundles of WebAssembly code that could be
| done better in simpler tools. That is inevitable.
|
| WebAssembly _will_ be used badly. Everything is, especially
| in web dev. Hopefully it will also be used well though.
| root_axis wrote:
| 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 wrote:
| >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 wrote:
| > _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.
| nurettin wrote:
| > have always been opposed to the framing that people
| creating new web development tools is a bad thing.
|
| You mean you support the creation of a new JS UI
| framework every other week? Or is this about something
| else?
| root_axis wrote:
| Yes, I support developers doing whatever they want and
| releasing it to the commons for all to benefit from if
| they so choose. If that means "a new framework every
| week" then it is what it is, I don't see the problem with
| that. Just because someone wrote some code and put it on
| the internet doesn't mean you have to use it.
| nurettin wrote:
| I am for the same thing, except when it specifically
| means a new JS UI framework every week. Nobody needs
| that.
| emsy wrote:
| The problem is not creating new web development tools but
| creating them for the sake of creating them. And what's
| worse is people end up using them out of fear to fall
| behind. People complained about Maven that you first have
| to ,,download the internet" to run a build. This is even
| more true for npm. In the meantime there are still native
| apps written in C and makefiles that work just fine.
| Also, wasm is just a new compilation target for Rust.
| This means if you know Rust you can write web apps. You
| have to learn _less_. With a new tool you have to learn
| usage, syntax and idiosyncrasies.
| root_axis wrote:
| > _The problem is not creating new web development tools
| but creating them for the sake of creating them._
|
| Why is that a problem and who is the arbiter of merit
| with regard to publishing code to the internet? I can't
| see any other way to parse what you've written other than
| "people should stop making so much stuff"
|
| > _wasm is just a new compilation target for Rust_
|
| And the vast majority of the js ecosystem is just
| compilation targets for js, if anything rust seems even
| further removed from the web ecosystem since web
| applications typically don't require low level
| performance.
| danShumway wrote:
| 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?
| root_axis wrote:
| > _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_
|
| Absolutley not. I love rust and would be happy to live in
| a world where I could write rust in any place where I
| would typically use typescript or babel or coffeescript
| back in the day, but none of that is going to be possible
| without an entire stack of tooling similar to that which
| already exists for the js-targeted ecosystem, and I have
| no problem with that, but people who ostensibly dislike
| "churn" claim to have a problem with new tooling and new
| solutions for building web pages and this is exactly the
| promise of wasm.
|
| If anything, wasm represents the biggest shift in "churn"
| in the history of web development since it opens the door
| to dozens of new languages and frameworks that were
| previously impossible to use for web development.
| Risord wrote:
| > 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.
| learc83 wrote:
| People complain that the _JavaScript_ ecosystem changes
| too frequently.
|
| It is perfectly logical to believe that this is true,
| while simultaneously believing that allowing new language
| ecosystems to target the browser, could result in a new
| ecosystem that is much more conservative and changes at a
| slower pace than the JS ecosystem for whatever reason (a
| language with a larger standard library, a language with
| a different culture etc...).
|
| A one time change to another ecosystem and then a slower
| pace of changes.
|
| Who knows if this is will be the case, but it is a
| logically consistent position to hold, and there's
| nothing ironic about it.
| root_axis wrote:
| It's not logically consistent. Why does it matter whether
| the tooling compiles down to js or wasm, if anything,
| expanding the web development ecosystem to include dozens
| of new languages and frameworks will _increase_ "churn"
| as many new approaches become popularized on the front-
| page of HN. It's absolutely no different than a new js
| framework.
| dgb23 wrote:
| I agree with with the intent of your statement!
|
| However:
|
| > Nobody wants to hand-write wasm (...)
|
| As a side note I want to point out that it is actually
| quite feasible to hand-write WASM in the text
| representation WAT.
|
| It has some high level control constructs, type checking,
| some unique safety guarantees and a simple memory model.
|
| Writing some (simple) programs in WAT and possibly a
| small language compiler for WASM is quite educational,
| fun and can be inspiring.
|
| It can also build a more grounded intuition for the
| performance characteristics of WASM.
| root_axis wrote:
| For sure! I find WASM to be quite readable, its actually
| an impressive feat of bytecode design.
| bdcravens wrote:
| I feel like there's a movement to try to reel that in while
| keeping many of the advantages, via server-side DOM diffing
| over websockets (LiveView, Blazor, Stimulus Reflex, etc)
| cheez wrote:
| The tools are not sophisticated, they are brute forced.
|
| I'm not sure I've seen a more elegant approach to frontend
| web development in 2020 than Vanilla JS.
|
| Maybe with some lit-html on top.
___________________________________________________________________
(page generated 2020-08-11 23:00 UTC)