Maybe I don't get it, but why would I use this? What problem is it solving that insert JS framework isn't?
I understand JS is popular to hate, for a variety of reasons, but those reasons seem mostly to boil down to nerd cred. The "hate what's popular because being contrarian means I'm cool" crowd.
So, and this is an honest question here, why should I invest the time to learn an entirely new syntax for a framework to build web applications? What can this do that vue.js or react cannot? (And I don't mean it does it differently I'm looking for it does it better or JS framework doesn't do it.)
> I understand JS is popular to hate, for a variety of reasons, but those reasons seem mostly to boil down to nerd cred. The "hate what's popular because being contrarian means I'm cool" crowd.
Then you're not paying attention. I'm not sure how you expect anyone to answer your "honest question" when you've already dismissed all the answers. It's not just fashion, programming language design is a real thing that it's possible to do badly or well, Javascript is a legitimately bad language, and Rust is a legitimately good language.
Learn Rust or another ML-family language, actually learn it to the point where you can write a decent, full-sized, idiomatic program in it. It won't be easy, but it's worth it. I mean, I could talk through all the reasons such languages are better, but it seems like you're already determined to dismiss them, so really the only way is to see for yourself.
> Javascript is a legitimately bad language, and Rust is a legitimately good language.
Yeah, statements like these without even trying to back them up are pretty ridiculous.
Sometimes someone brings some stupid issue that's never a problem in practice, but most of the time people just admit they simply have no real experience with JS. They just love to claim how superior they are, and anyone who disagrees is "not paying attention".
FYI you are just showing how awful are communities around "legitimately good" languages.
I'm willing to back it up. I've written at length on these things before. But there seems little point when the person I was replying to has already pre-emptively dismissed any reason I could give.
> FYI you are just showing how awful are communities around "legitimately good" languages.
Just to let you know Rust's community is pretty cool and not awful at all. For instance the Rust Survey 2017 reports that 98.7% of respondents feel welcome within the Rust Community.
Furthermore according to the Stackoverflow 2017 survey, Rust is the "most loved" language.
Sure. Language design is has tradeoffs but Javascript makes a lot of unforced errors, cases where the consensus was already established and Javascript went against it. (In fairness it was a single-application scripting language written by one guy in three days, not a language carefully designed for general-purpose use by a panel of experts).
Non-lexical scoping is awful, everyone knows it's awful. Recent versions added a better-scoped "let" which is progress in a way but now means you have two different kinds of declarations with very different kinds of scoping. "this" in Javascript is just entirely useless, confusing semantics that resemble no other remotely mainstream language. "Prototypal inheritance" is a mistake, again no other mainstream language uses it for good reason, and again newer versions of Javascript have added "class" to correct this but that leaves the language with two radically different ways of accomplishing the same thing. "undefined" manages to be an even worse version of the billion-dollar mistake, null; errors become apparent even further from where they occur ("foo is not a property of undefined" failures a long way away from whatever caused the value to be undefined), where what you want is fail-fast. Extremely loose value coercion at runtime is terrible for large programs in a language without a type system; even at the time Javascript was first created, Python or TCL knew this. (Perl didn't, but avoided the worst of the problems by not having so much operator overloading, e.g. using . for string concatenation). Indeed lack of any kind of type system is pretty indefensible in a general-purpose language these days, even Python's getting type hinting, though this was less common knowledge back when Javascript first came out. The language is far too dynamic for working with mixed security contexts even though it's the most popular language for that very use case, forcing browsers to resort to crude sandboxes and coarse-grained permissioning instead (e.g. you can give a site access to your webcam/microphone, at which point all the ads running on the page have access too). And there are a bunch of small usability niggles (the "wats" you see talked about), none of which is important in isolation, but developer-friendliness does add up.
Rust is a pretty conservative ML-family language design: where it differs from OCaml it's because of deliberate design decisions. (In fairness some of Javascript is descended from Smalltalk which was more respected at the time than it is now). Really most of what Rust does ought to be table stakes for language design (and it kind of is, looking at e.g. Swift or even Kotlin), should have been since the 1970s when ML came out: to quote Wikipedia, "Features of ML include a call-by-value evaluation strategy, first-class functions, automatic memory management through garbage collection, parametric polymorphism, static typing, type inference, algebraic data types, pattern matching, and exception handling. ML uses static scoping rules." (Rust may appear not to have exceptions, but ML "exceptions" have more in common with Rust's panic/recover than with Java-style exceptions). These things are small and simple but very useful and general, and allow you to push a lot of work out into libraries written in plain old "userspace" Rust code (though this would be much more true if the language had HKT, grumble grumble) rather than having to "bolt on" ad-hoc features at the language level. The only novel-for-mainstream language-level feature in Rust is its ownership tracking (i.e. the borrow checker), which is about the right amount of innovation for a programming language to have, and by all accounts is working well. Good language design is as much about leaving things out (of the language itself, pushing them into userspace code) as it is about putting things in.
Simply put, at the moment, you wouldn’t. But when wasm is mature enough (host binding to control DOM directly), there will be framework for 10x performance (compares to js’). This framework is a step toward that direction.
Also it provides options for Rust programmers to not touching js. Totally worth it.
The reason people like Rust more than JavaScript is that Rust is a better at what it tries to do than JavaScript is at what JavaScript tries to do. That said, they don't try to do the same thing, so you shouldn't use Rust in all situations. Rust is focused on speed, safety, and low bug count, but it's slow and annoying to write and refactor. If you are willing to make that trade-off then do; if not, then don't.
Well it is still mostly JS. Claiming JS is crap (often stated as "beyond repair") and TS is good just because of (arguably) light addition shows some serious cognitive dissonance. But nevermind:
> The fact that it can be transpiled to Javascript is irrelevant
For some of the same reasons you might want to write your back-end in JS, but going the other direction. You could share code between front-end and back-end, but have a very strongly typed, secure, fast, and less prone to bugs language to do it in. Not everyone's cup of tea, but if you're already got a lot of code written on the back-end, this might make a lot of sense.
You wouldn't invest time and energy to build web app in rust, but you would be able to write your frontend in rust instead of investing time and energy in $JSFRAMEWORK of the year.
I'd imagine that it's useful to be able to share a data context between a route-handler, for example, and it's rendered template and the embedded client side "scripting" that may be quite extensive these days.
("scripting" in quotes because of how rust embedded in the html templates can be so much more than logic-less templates- a bit like a server side template, the dom, and clientside javascript all in one- and I'm just guessing, but because it's not dynamic, but compiled, nonetheless safe even though logic is in there...)
I understand JS is popular to hate, for a variety of reasons, but those reasons seem mostly to boil down to nerd cred. The "hate what's popular because being contrarian means I'm cool" crowd.
So, and this is an honest question here, why should I invest the time to learn an entirely new syntax for a framework to build web applications? What can this do that vue.js or react cannot? (And I don't mean it does it differently I'm looking for it does it better or JS framework doesn't do it.)