5 ms·
People complaining about that are generally talking about the churn in front end web frameworks and JavaScript development in general. None of that eas necessa
by learc83 6y ago
People complaining about that are generally talking about the churn in front end web frameworks and JavaScript development in general.
None of that eas necessary for WebAssembly to be developed. Unless you mean that the annoyance of the constantly changing JS ecosystem motivated people to push for it.
- root_axis 6y agoNobody 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 6y ago>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 6y ago> 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 6y ago> 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 6y agoYes, 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 6y agoI am for the same thing, except when it specifically means a new JS UI framework every week. Nobody needs that.
- root_axis 6y ago> Nobody needs that. You have no idea what people need when they decide to create whatever is they want to create, if you don't want to use it you don't have to.
- nurettin 6y agoThat's the problem. Since I have no idea, I have to attend a meeting at the start of the week to discuss whether I need it or not with the staff because everyone wants the next hot thing. It isn't a coding culture or freedom problem as you put it, but rather a corporate space problem and much more often than not, it just causes unproductivity.
- emsy 6y agoThe 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.
- dgb23 6y agoI 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 6y agoFor sure! I find WASM to be quite readable, its actually an impressive feat of bytecode design.
- onion2k 6y agoNone 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.
- tbugrara 6y agoIt'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_frameworks_section_overview https://2019.stateofjs.com/front-end-frameworks/#front_end_f...