The State of Desktop Applications in Node.js
nodesource.com
nodesource.com
The async nature of UI and I/O makes JS a perfect fit, so I expect this trend to only continue and the tools to improve. It's so much faster and more efficient to create using JS than "native" languages, it's a no-brainer for any business who has a dev with this experience.
So that people don't need to install, maintain or update applications, and can access them everywhere in the world using just a web browser? And because they're also more secure than traditional applications that you need to install on your PC?
Have you ever used a web app that changed in ways you didn't like?
* Web browsers already have a way of creating widgets rendering them, changing their skins
* There are many javascript libraries and frameworks, so can use those for connecting backends, processing events, etc.
* With a bit of luck you can run the same code as an actual web page.
* Desktop app is an after-thought today because web service/web page came first. The world of software applications with a GUI on top started with Desktop apps that were then adapted for the web. Today perhaps the opposite is true.
I'm pretty confident that this is the simplest way to build desktop apps in JS in Windows :)
Because innovation happens when you start thinking out of the box?
From the user's perspective, however, there's been a ton of innovation, and they (usually) don't know/care that most applications are built on houses of cards.
Historically, my language of choice for the server-side has been Java (I interned at an IBM lab that was involved in the creation of Eclipse, so I used it a lot at the start of my career). More recently, I've been dabbling in Ruby, and I'd also like to give Scala and Go a try.
For most of its history, HTML has been codifying usage rather than prescribing it. The one major exception—XHTML—was never widely adopted, partly for this reason.
Ah yes, nothing is better than waiting 5 minutes for the native Facebook iPhone app to boot up. But seriously, I've mostly switched from facebook to ello just because ello as a web app is faster than facebook as a mobile app.
Not all web apps are slow and not all native apps are fast. It's up to the developers to handle that, not the platform.
I see a lot of benefits of building and using web apps over native ones.
As a developer I can really focus on using the browser as my runtime. Meaning my app will, for the most part, run on most devices. It's also easier to maintain. If I need push a patch or update, I just edit some javascript.
As a user, I know that when I switch from device to device I won't need to go through an install process. All I need is a url.
Why can't the web be for games or text editors? Some of the most useful text editors I've used are on the web. What about WebRTC? Should we still all be using the Skype desktop app instead?
I would probably say that it's lazier not to make your app work well on the web.
Besides, I'd rather have an app that takes a little longer to start up, but performs well, than an app that first requires starting a web browser and then on top of that has an interface that runs like a snail.
Also, even if it is the phone, that's still an issue with native apps. The fb web app loads faster (still not great, but faster) than the iOS app boots up.
> Ah yes, nothing is better than waiting 5 minutes for the native
> Facebook iPhone app to boot up. But seriously, I've mostly
> switched from facebook to ello just because ello as a web app is
> faster than facebook as a mobile app.
First of all, webapps almost always screw something up in the UI. If they're wrapped in a native container maybe they scroll differently, they don't respond to some gestures, are missing some menu entires or make other small mistakes. Depending on the user this can be mildly annoying or just strange for them.
Secondly, web apps make customers dependent on something they have no control of. That cool startup might close shop tomorrow and if you're lucky they'll give you one week to export your data. The company might decide to pivot or charge more or a myriad other possibilities and the customer has no choice but to either cancel the service or deal with it. I can give you an example of many iOS users that are still on 7 because some apps were broken by the update - they can do that with apps and we're talking about iOS here, desktop is even more flexible.
Thirdly, speed. Ironically, Facebook themselves admitted that they made a huge mistake by using webviews because this made their app incredibly slow. Your case is almost impossible to believe, and indicates that something is completely broken in your software configuration. In most cases a native app will outperform a web app, from the UI speed (scrolling, panning, drag & drop, viewing documents) to performing various tasks. It's quite logical, as a native app has direct access to all APIs, while a webapp has to go through N intermediate layers.
Native is hard relative to (the nearly thoughtless) slapping together of JS and CSS frameworks to "build" an "app." It requires paying people more and taking more time to develop.
When compared with RAD tooling like Delphi or XAML, HTML/CSS/JS is anything but easy.
People who have never heard of specificity or modularity start writing code that will run on thousands of browsers, and in turn those users experience a slower web.
The other side of that mess is when developers with more experience thoroughly plan out the architecture of the web app, to ensure it operates on a performance budget and the user experience stays positive. Just as native apps, this also requires paying people more and taking more time to develop.
Having helped many organizations understand how to build JavaScript applications across a bunch of different platforms, from my experience what they are trying to do is improve their ability to iterate and remain responsive to user needs across all the devices users want to interact with.
As a user, I expect and prioritize applications and experiences that are available to me wherever I choose to use the service. Web stack tech is facilitating this.
- It removes the risk of spending time and money learning what turns out to be the "wrong" (i.e. an unsuccessful) platform
- It avoids splitting the effort of tooling vendors, library authors, etc. across many different platforms, reducing the amount of redundant effort spent reimplementing things in platform Y that already exist in platform X and freeing them up to work on unique ideas instead
- It brings the largest possible number of people underneath one umbrella, which makes that community more economically attractive and therefore increases the number and quality of tools and services they have access to
Not that it's all sunshine and roses, of course, but it's not without advantages.
no.
This kind of stuff isn't for all apps, but for our use case it was almost too good to be true. We built everything out in about two to three weeks. I don't know how long it would have taken for us to do something similar with true Desktop tooling.
Here's a video of the end result in case anyone in interested...
The multi-process model is definitely more complex and probably not for everyone, but it's working really well for us so far.
If one really really wants to use JavaScript, at least make use of QML or Nashorn/JavaFX.
Please stop trying to act like the state of web and javascript is good because it's shit. Web development is basically a bunch of people suffering from stockholm syndrome.
People that complain about verbosity really don't have their priorities in line
Bragging about LOC is one of the most ridiculous things ever, since it is a bad thing.
Also, I'm in college for computer science and the school will only teach Java courses. It's dreadful and maddening. Classical inheritance is complete shit. Compiler error messages suck. The language itself is just too bloated for me to want use. Whatever I can write in Java I can do in a fraction of the time with js with much more modular and maintainable code.
I think java interfaces are a clear sign of stockholm syndrome, as every time I asked the professor why they are necessary I never got an answer other than "to hide part of your code from the outside world", "to use as a blueprint for your classes", or my personal favorite "Because in Java you write interfaces." I tried shifting my question to "Why don't I have to write an interface in js?" That one never got answered. Maybe someone here who is crafty with Java could explain and justify for me the reason for writing what feels like more code for no obvious benefit.
Also, sorry if Java is your thing and I sound like I'm bashing it. It's just been really frustrating for me compared to literally every other language I've used, especially since my degree depends solely on the language.
Whoever likes writing Java in CS courses?
> I think java interfaces are a clear sign of stockholm syndrome, as every time I asked the professor why they are necessary I never got an answer other than "to hide part of your code from the outside world", "to use as a blueprint for your classes", or my personal favorite "Because in Java you write interfaces." I tried shifting my question to "Why don't I have to write an interface in js?" That one never got answered. Maybe someone here who is crafty with Java could explain and justify for me the reason for writing what feels like more code for no obvious benefit.
Almost all modern, statically typed languages have some equivalent of Java interfaces. Inheritance a la Java is controversial, but the concept of interfaces/signatures/typeclasses/traits is a very accepted language feature[1]. Maybe the benefit of it will become apparent to you once you have to write a project with more than 7 Java classes - or when you don't have to answer to lecturers that profess that you have to make all your throwaway course work super modular and generic.
[1] Litmus test: even Go has it.
Also how have you not, in a java class, written code that uses polymorphism? That would be the easiest way to understand how useful interfaces are.
My preferred method of "inheritance" really is just extending an object. Which js is great at. And there's multiple ways to do this, with multiple kinds of prototypes. For something quick an easy I can make a prototype and just pass that through object.create() and now I have a new object that has all the properties of what I would loosely consider to be a "parent". It's more cloning than it is inheritance, and I can completely override properties however I want, while the original properties stay unchanged.
IMO polymorphism and interfaces in Java seem more like hurdles and added complexity compared to object extension and cloning in JavaScript. _.extend paired with browserify also makes for extremely modular code that I haven't seen any Java code compare too.
I think that a lot of "classical" programmers simply don't understand how important modules are to JS development.
This is why you get these posts about "how can you manage 1,000,000 LOC in JS!!?", when they don't understand that you never have 1,000,000 in JS, you have a bunch of small, unit tested modules.
Writing UI components out of HTML/CSS/JavaScript glue is a joke compared with what native UI toolkits allow for.
What was that? Sliders, exotic buttons, reactive graphs? What kind of applications are you selling?
Customer comes with Powerpoint/Photoshop mockup of their idea, based on how native UIs work.
Usually when it comes down to paying, there should be a 1:1 correspondence to their idea, across all requested devices.
While native UIs allow for full control down to pixel level and hooks on control behaviors.
Web requires a CSS/HTML/JavaScript magic mix to make it work properly across all requested browsers and devices, and still not good enough for some.
A recent example was a control for file uploads and the information that should be displayed while the file was loading. The files were too big to be processed server side and HTML 5 File API doesn't provide all the required features.
We, as developers working for companies that sells enterprise software "on the shelf", are not looking after pixel-perfect native UI and lowering customer friction during a project, as you seem to do (no offense, I can respect that).
What drives us is (i) innovation in solving enterprise problem, (ii) delivering a smooth, cutting-edge UX, (iii) offering the most affordable price while still being profitable.
If you consider those goals then a stack based on JS desktop application makes suddenly a lot of sens (lower development time, easy deployment, etc.)
Have you considered the possibility that, in some years, you could be the one that will be trying "to catch with the web"?
As I said everything goes. A native desktop .NET project today, a C++ embedded project in a few months and then a Web one.
So I never was, nor will be, a language X developer.
The endless UI factory churn of the web world?
That's a bit unfair. There are many mature(upwards 5 years of continuous development) UI components for javascript. Charts, Visualization, Data grids, UI Binding and pretty much anything an application would need are taken care of by some high-quality JS libraries.
Sifting through the various libraries to find one that fits the application is vastly preferable to having to write it by yourself.
Google wants to keep you locked in their sandbox.
multi-platform and easily bindable to any language
Does anyone know the base size for an atom-shell app?
The alternative is not making apps self-contained, but instead to make them rely on shared libraries. This is much more efficient, but apart from a few neckbeards who cry "bloat" it seems that most people care more about avoiding dependency hell and ease of use, even if that means large packages due to library duplication.
You mean as a developer. Your average 'user' does not know or care how big an app 'should' be.
A significant number of users would notice an app being dramatically larger than it ought to be. I've seen a lot of reviews like "why the hell this app over 100mb??!!1". There is a huge spectrum of technical competence between "I don't have any sense of what a megabyte is" and "Developer".
Besides, does it matter much if you delete an app when it can be downloaded again in a matter of minutes?
I just launched it and timed it at 28 seconds. Then I closed it and launched it again and it took 3 seconds, so I assume there's some sort of caching going on. But basically Atom is too slow and bloated for what I need it for, which is just editing text files, CSV files, XML files etc. Sometimes I really need the multi-line cursors for a CSV though, and I'll use ST2 for that, as it seems a little snappier than Atom, although it also takes a little while to start up.
When I write code, I use Eclipse if it's Java (for work) or emacs for everything else (personal projects). I think I'm just going to install emacs on my work machine and start using it for all my text editing needs though.
It reminds me of Newton's third law: "For every action, there is an equal and opposite reaction."
It does have a substantial learning curve. The traditional desktop stuff is all C++. The new mobile stuff is easier to develop, with a nice declarative UI system and JavaScript, but it's not applicable if you want native-feeling desktop widgets.
* When an error occurs in node-webkit, it loads an error page instead of simply logging it to the console like normal web pages. Even after fixing the error and hitting reload or navigating back, the page doesn't go away. You need to manually enter the url(copy/paste doesn't work).
* I don't know if this is something that was my fault or the app's, but when I made a call to a sqlite3 database using the node-pure-sqlite3 gem, it would take around 3 seconds to execute. With atom-shell it would take less than a second.
* The developer console is a separate window from the application in node-webkit. I prefer having a single window hold both the app and dev console during development(which atom shell-allows).
For performance of node.js calls, I haven't run any benchmarks, so I cannot help you there. However subjectively, both felt about the same to me(except in the node-sqlite-purejs case).
http://macgapproject.github.io/
The packaged app is tiny compared to a chromium+Node shell app.
One thing this article gets slightly wrong is this sentence: "This means that Node.js modules must exclusively use functions and classes provided by Node.js or modules from npm, as the DOM is off limits."
This might be technically true, but there's an easy enough workaround:
1) Use a script tag to include jQuery in the index.html page
2) Pass the jQuery object ($) as a dependency into a node module.
3) Profit.
I regularly modify the DOM from node context using this pattern.
I'm not sure if it's still actively developed though.