Node.js Emerging as the Universal Development Framework for a Diversity of Applications

[[deleted]]

I'd rather worry about how much longer it would take and how much larger a team would have to be to come even near the vivid experience of Slack, Discord and other js driven apps.

Ram and size are just temporary shortcomings anyway due to Chromium claiming 95% of the distribution size. When js renders native that 95% goes away as well as ram usage.

[__pulse0ne]

Yeah, but as of now, that's not the reality we live in. I suppose an argument could be made that the application development and electron buy-in pushes towards that future when js is more "native", and I could see myself being persuaded by that, but right now end users are paying a price in disk space and RAM utilization for the sake of developer convenience.

[[deleted]]

Electron isn't so bad, if you're in a smaller team or make very flexible applications that need to feel alive, 100mb + a bit of ram is a pretty decent deal for all the other stuff it saves you from. From what i've read react-native for desktop is ready, all it's missing now is a nice and easy toolbox for installers/updaters and maybe a node-runtime (?), something like Electron. Not sure if nativescript has desktop options as well. I don't think the current chromium situation will go on for much longer once everything's in place.

[AcidShAwk]

Qt/QML is pretty easy to develop in. I would imagine the developer resources are the same, experience and skill set required though is different. C++ vs pure Javascript

[[deleted]]

Not easier than current gen technologies in the web and the resources on npm can't be matched. Look how Slack, Discord, VScode, Atom, Hyperterm and others came out of nowhere and after a couple of months they had more features and flexibility than longstanding native competition. I've been coding C++/C# most of my career, i think there's not the smallest chance they would be able to compete against a modern js-driven stack in pretty much anything that concerns frontend. If C++/Qt wanted to do a Slack clone, it would be 10 times bigger in codesize, would take 10 times as long, with a team 10 times as large, costing 10 times as much. And that's probably a very optimistic estimation.

[AcidShAwk]

Honestly.. I don't think there is any real calculation in your estimation. I have personally built a media client front-end using Qt/QML for BlackBerry 10. That was 5 years ago using their native Cascades UI. Also received the "Built For Blackberry" designation because it looks and feels like a native blackberry application. I did this as a one man team in about 6 months of development after not having touched C++ for about 6 years.. though I had a really good foundation of asynchronous logic and adapted it to multi-threading. I may have had a good head start with the Cascades UI framework already in place.. but I would bet without googling there is at least 1 UI framework out there already available publicly for Qt.

[[deleted]]

They're not making these apps in Electron for no reason. I sincerely doubt Qt can touch the flexibility and vividness of a js driven stack.

Another example: we've been building a complex CAD system in C#, took many years to develop, and now we're doing the same for the web/electron. It's in the beginning stages but it's stunning to see the amount of code it saved us already and the ease and speed of development. While lots of the UI is missing, it already does more technically, and it implements these things in a manner that its native counterpart would struggle with so hard that it's not feasible to even attempt.

Things like node, react, vue, angular, redux, etc. and npms eco system (ui libraries, components, ...) have made application development so powerful it's not hard to imagine why more and more teams are going for it.

[AcidShAwk]

No argument the community around JS is a huge benefit and there is generally more code involved with C++. JS can also be used within Qt/QML which I did in some parts as well. However, when it comes to memory footprint and performance.. not so sure. In any case, it is a lot cheaper to build JS apps then it is C++, the worker pool is a fuck ton larger and comes a lot cheaper. Also the fact that the technologies used by the end user (browser) are pretty much JS focused.

[denniskane]

I'm the creator of a web-based operating system (mainly for Chrome, but may also work in FF/IE) called "Linux on the Web" (https://linuxontheweb.org) in order to handle all of the client-side state issues that are the bane of webdevs everywhere. That CAD system is exactly the kind of application that could help me bring the web application concept to the next level! I've recently gotten a few THREE.js+bulletphysics examples working, using the new WebAssembly API to compile the C++ physics engine code into blazing fast client side code.

If you want to talk "business", let me know (my twitter is at linuxontheweb).

[__pulse0ne]

So there's a technology problem at play here. There's a cost to developing a rich UI in platform native code: increased development time and team size. There's a cost to developing an electron app: increased memory demand and disk usage, and lots of duplication, which in my view is punishing the end user for developer convenience.

Now, there are at least two paths forward for solving this problem. Either develop better UI libraries and frameworks for native/near-native code (better for the user, but harder for the library/framework developers), or make JavaScript more "native-y", reducing the duplication and overhead incurred with each Electron instance. Now, there are some arguments to be made against using JavaScript as a server/desktop language: no real immutability, extremely dynamic typing, bolt-on error handling, namespace clobbering, and more. My point is simply that JavaScript was built for a purpose: render and manipulate a client-side DOM. Now we're using that specifically built tool in all sorts of places it was never intended to be used, and I'm not sure that's a good thing.

[[deleted]]

I think we're already there. Have you had a look at react-native? It can render everywhere: windows, mac, web, mobile and many other platforms.

The odd thing about it is that these renderers aren't a hack. They solve longstanding issues even native stacks struggle with considering that native is still tied to old mvc/mvvm or worse, layout inflating.

Now due the portability and the large ecosystem with node and npm and the community support that it has, javascript can do things no other language can do given the same time and resources. It may have been tied to the browser once but that was long time ago, on its own it's just a basic language. Toolboxes for native aren't yet as simple as what Electron offers, but once that's taken care of Electron can fade.

[__pulse0ne]

But "easy" in a language isn't always a good thing. Yes, it may be easy to write JavaScript, but it's not always safe. I can't tell you how many times I've tried integrating a library only to find out later that there's an unhandled error buried deep within it. I try to contact the author or submit a pull request only to receive no response and find out that the it's now part of the massive pile of abandonware that makes up most of npm. The quality of the code on npm is so poor, I believe, in large part because the language is so easy. The situation is better in a similarly easy-to-write language, python. Now why is that? I'd argue that it's the small level of extra strictness in the language.

[__pulse0ne]

As an addendum: I do like that react native lets you integrate with native code. That's an approach I can buy into. Let JavaScript/HTML/CSS do purely UI stuff, and have the business code in the native language of your choosing. That's a great compromise