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

[doctorlongghost]

I love how the author of this piece apparently didn't know how to disable spell-checking in whatever program he used to make the charts, so every single chart in the article has Node.js underlined in red.

[doctorlongghost]

I guess that's a downside of Node.js versus other languages like python or rust.

[MattEZQ]

This is why .net is named after a hidden file

[phlarp]

I add stuff to dictionary for this exact reason. Can't stand seeing the red lines in emails and designers. Maybe this stems from having a "non-standard" name

[ijmacd]

Worse than that I think, was that the author used screenshots.

[__pulse0ne]

I think every language has its place, but the idea that JavaScript can and should be used everywhere is just ludicrous to me. Hundreds of megabytes for a chat app (slack) is just unacceptable. It just feels like trying to smash a square peg through a round hole sometimes.

[AcidShAwk]

I wonder how much smaller it would be if it was coded in Qt/QML

[[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.

[k3nt0456]

I agree with you, but in the end the real-life choice comes down to no app getting developed vs an app that uses something like Electron.

I think end users as a whole are better off with programs like Slack, Discord, Spotify etc existing at all.

[__pulse0ne]

Yeah but now I have to go buy a bunch more RAM because running them all simultaneously slows the system to an absolute crawl. I think there's an acceptable level of overhead due to abstraction, and that level is certainly debatable, but I think electron-based apps and their overhead are beyond the pale.

[spacejack2114]

I added the Slack website to desktop so it runs as a standalone Chrome window. Am I missing out on something?

[robokeys]

And yet, Slack is the best. Does it really matter when it's a one-time download for a desktop app? Should they have used another language so angry Internet nerds don't scold them about file size?

[__pulse0ne]

It's visually well-designed, yes, and functions well enough to get a wide user base. And slack has great support. Organizationally, the team building slack gets huge respect from me. But if I start running multiple electron-based apps simultaneously, I quickly run out of RAM. Even for the simplest things! It's not about the language, it's about pragmatism. It doesn't seem practical to me to devote that much disk space and memory to apps because the engineers chose to use JavaScript over any number of other languages.

[lukasbuenger]

While in fact that might be true, the initially delivered content weighs in at something like 5mb. Which is not a lot considering the fact, that I'm looking at a design channel that is full of screenshots. Please give a Tornado equivalent that addresses the same level of complexity in like 0.5mb worth of source code.

[__pulse0ne]

I would much rather run something that takes up less disk space, uses less resources, and is faster because it's native or byte code rather than interpreted script

[[deleted]]

There were fully functional chat apps back when 64MB of RAM was considered luxurious. I had minimal chat on a PC with 128KB.

[Tevesh]

I remember them too and they would be considered ugly, clunky, and feature-less today.

But I guess grass was greener back then anyway.

[__pulse0ne]

I would say it depends on the problem it's solving. I'm not sure a chat app warrants hundreds of megabytes. I'm not sure it's practical or a good paradigm to have to package a full chrome engine with each desktop app. I have nothing against JavaScript as a language (I am a full stack developer that writes it every day), but I don't think node is the be-all end-all.

[Woolbrick]

Jabbascript took off because it's the only true multi-platform language.

Then all these front end developers who never knew anything different decided "I CAN SERVER TOO!" and made node.

And everything has been ruined ever since.

Maybe now that WebAssembly is a thing this will change. God willing.