Search posts, tags, users, and pages
I do not believe that WASM will solve anything. It's specific use-case is to create real applications which run in the browser, like AAA computer games. For homepages, it will probably not really be useful, as it introduces a lot of new dependencies and needed knowledge and build steps.
I think that the complexity will become sane, once people become sane. React is not a universal solution. The same is true for Angular, Aurelia, Sass, TypeScript, etc. Once people learn when to use what and (more importantly) when not to use what, our lives will become a lot easier.
Example: Just look at all the people using MEAN or MERN to kick of their small homepage projects. Their projects would progress a lot faster and be a lot more maintainable and performant, if they just stayed away from those frameworks and libraries. It's time to remember KISS and DRY.
Thanks for your reply. Like you said, WASM specific use-case is to "create real applications which run in the browser". Isn't this also (in part at least) the purpose of those ambitious JS frameworks such as Angular and React? Doesn't it mean that these somewhat inelegant, over-engineered JS frameworks will lose relevance once it makes more sense to use a more adequate language along with a more coherent/elegant framework for the tasks of creating complex web apps with elaborated UIs? "Simpler" JS libraries such as Jquery (or even Vue.JS?) will be (are) more than enough for most "traditional" website UI cases (those who don't aim to be full fledged complex apps).
Because these frameworks (Angular, React) have a steep learning curve, as a beginner I'm just wondering if it's worth spending the time necessary to master them vs spending that time focusing on learning backend technologies with a much longer lifespan. (I think I have "Javascript fatigue" before even starting! lol)
What do you think? Any other experienced fullstack web developer opinion on this?
David React was a reaction to a more and more complex application and Angular was a research project to bind the interface and data and have a single truth. Both are very nice ideas, hence I do not think that such frameworks will disappear just because there is WASM. The problems they try to solve preserve even with WASM.
It might as well be the other way around: These frameworks might be ported to Rust or C++ and then compiled to WASM and used by other projects. That would fragment the communities and hurt developers, since it becomes even harder to decide what to use (WASM or not? Which stack? Which language? etc.)
" It might as well be the other way around: These frameworks might be ported to Rust or C++ and then compiled to WASM and used by other projects. That would fragment the communities and hurt developers, since it becomes even harder to decide what to use (WASM or not? Which stack? Which language? etc.) "
Thanks, I guess this answers my question. One of my "problems" with these JS frameworks though is that they bring extra overhead (eg typescript, JSX) because of the inherent limitations of JS itself. Shouldn't porting them [the frameworks] to another language then compile to WASM fix this "problem" at least?
David WASM does not have to do a lot with JS. WASM was born in order to overcome problems with JS, specifically by not using JS. However, compared to TypeScript and others, WASM goes a step further and feeds prepared and optimized byte-code into the interpreter. Just think of WASM as yet another way to battle the shortcomings of JS.
So, instead of writing your code in TypeScript on top of Angular, you can now write your code in Rust on top of Angular :D (and thinking about the Rust compiler plugins, you would even be able to make RustX as a response to JSX. scary.)
Thanks again for your replies
"WASM does not have to do a lot with JS. WASM was born in order to overcome problems with JS, specifically by not using JS. However, compared to TypeScript and others, WASM goes a step further and feeds prepared and optimized byte-code into the interpreter. Just think of WASM as yet another way to battle the shortcomings of JS. "
I must have expressed myself very poorly because this was very clear to me already. I guess I was hoping that WASM would help to get rid of the JS frameworks madness, but I now realize thanks to you that the main source of web apps frontend madness isn't the limitations of JS iself but rather simply the fact that we're creating an app running on the browser and connected to a database somewhere in the world through the world wide web.
I hear so many bad things about JS from "desktop" (non-web) developers that I thought getting rid of JS was the answer... I was hoping that thanks to WASM using a nice modern high-ish level language like Kotlin would make web app frontend development a breeze... But now you're telling me that rust or C++ would be the languages of choice, which makes sense as WASM is mainly about performance first and foremost. Does this mean the end of the days where any web developer worth his salt could get by without knowing any low level language?
David well, those frameworks do solve problems we would have in any language (GUI component management, data locality). As for the languages which compile to WASM, I mentioned C++ and Rust, since I know that C++ was the go-to language for asm.js and Rust already has a compiler-target. There might be other languages which compile to WASM, like Kotlin, however I am not aware of them for now or there has not been any official announcement, yet.
As for "JS has many bad parts", I am a desktop-developer, too, and I love(!) JS. It is super-easy to create and script a GUI with web techniques and super-performant to have the hot code in a compiled language. Using a compiled language to create WASM makes some things better, but will never replace the easiness and dynamic of JS.
This is an old discussion, but when you said " I am a desktop-developer, too, and I love(!) JS. It is super-easy to create and script a GUI with web techniques and super-performant to have the hot code in a compiled language" , what do you techniques do you refer to? Do you use electron (I thought electron was 100% JS all across) or is there some other options out there?
David of course, there is Electron, which is 100% JS. However, I once also used CEF, which embeds chromium, so I can have a web-GUI, but write the rest of the application in C++. Other than that, Qt is pretty popular. It also uses C++ as language. There even is an entire desktop environment built with Qt. Qt comes with its own interface language, which is not that different from web dev and has a browser component, so I could directly use plain old HTML/CSS/JS. Searching the web, you will quickly find even more such web front-ends for other languages.
I see that many people complain (and I can also see it for myself) that electron apps use up a lot of RAM and CPU compared to native solutions. I know KDE is based on Qt so I guess it has to be a more efficient solution compared to electron?
David Electron uses up a lot of resources, because it always comes with a whole browser and NodeJS. There are projects, which try to limit at least disk usage, however I guess that other resources will remain a problem...
I use KDE myself, and I am very happy with it. Coming from Windows, I can recommend it if you like customizing your desktop experience! As a package, it is more efficient, however, when you put it in a standalone comparison webview vs webview, you won't gain anything (other than the ability to easily write machine code)
I'm actually quite fond of the way GNOME shell works on my laptop, but I'll give KDE a chance on another machine for sure (if only for KDEconnect which is quite awesome, also dolphin is way better than nautilus). There just seems to be too many oldschool menus on KDE apps, I like the way GNOME feels moderns and always try to hide the stuff I'm not using right now, helps me to keep focused on what I'm doing...
(btw I was talking about Qt vs electron in my earlier question, obviously KDE wasn't related to the discussion)
David didn't want to say that KDE > Gnome. It's just a Qt example :) I don't really know Gnome. The last time I tried it was when Gnome 3 was released and I only had it for a week or so. I jumped the KDE-train, because KDE has the most customizable interface, and that's what I will always choose. If you don't like the app menus, just customize them ;)
Yes customisability is a big selling point of KDE but I'm afraid it may end up being a time sucking trap for someone with my personality type... You know, why spend time just getting things done when you can spend it customising your environment so you can be as productive as possible and actually get things done faster eventually, some day, maybe... lol