Seriously, does anybody nowadays care about a 100 MB desktop app? I developed my first app in 1997 with Delphi and it was only 200 KB, so from that perspective I always cringe when I see that an app I've developed is multiple MB. But in all seriousness, do users actually care? Every time I download an OS X app, it's at least 50 MB, but I find that even I don't care anymore because downloading 50 MB nowadays only takes 10 seconds, and my machine has more than enough RAM to load all the bundled libraries. We are in an age where people deploy VM images and Docker containers that are many hundred megabytes, and it seems people are happy that way.
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.
I would agree with you if you were talking about 20MB. I think that would be my threshold for not caring about how big an app is, i.e. even if it's something really basic like a countdown timer app I would be OK with it being up to 20MB, because as you say, connections are fast and space is cheap. But 100MB? I don't know.
It's nothing to do with how much space it will take up. The problem is that, as a user, I would be very suspicious of a 100MB countdown timer app. I would think that either it's got some kind of adware in it, or just that it's incompetently designed.
I disagree. App file sizes are displayed in app stores because many users care about them.
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".
My laptop has a 256GB SSD. My media collection is 337GB. So a 100MB app doesn't just need to compete with other 100MB apps, it has to compete with my music, videos, and photos. Is a 100MB app better than my photos reminding me of my time in Sapporo, Japan? That depends on the app, but I'm more inclined to delete a 100MB app to make room for more photos than a 20MB app.
I can confirm that I don't use Atom because of the overhead of the browser engine. It takes about 30 seconds to launch, and it hangs frequently, which to me is unacceptable for a program that edits plain text files.
Lenovo ThinkPad T440 running Windows 7 (not by choice, standard issue for my work).
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.
The web wasn't made to be used as a desktop app replacement, and it will never be. Quit trying to make it that way, and start using a widget toolkit like you should. Hell, if you love html/js so much, there's a big chance you won't dislike QML.
The web is for sharing content, not for games, text editors, and all that stuff. I see google trying to blur the lines between that, but why is it necessary? Just because people are too lazy to adapt themselves to the platform they're writing for, and allow them to create slow, shitty "web apps"?
>I see google trying to blur the lines between that, but why is it necessary?
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?
Regardless of my personal view of JS desktop apps the reasoning usually follows out of a combination of these:
* 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.
What is the alternative to building a cross-platform desktop app that isn't tied to the browser security model? Build a different app for every platform?
When I set out, a few years ago, to build a gui app in JS in Windows (but cross-platform), I found RingoJS which is a wrapper around Java. My entire app could be in a single .js file, with access to all Java libs. For the widget library, I chose SWT. I built a few very simple apps, despite having never programmed in Java before. Later, I found how to run my .js file directly with RhinoJS and SWT from the command line.
I'm pretty confident that this is the simplest way to build desktop apps in JS in Windows :)
It's OK that you don't like using HTML/JS, but a lot of people do like using them (which is also OK), and those people are the target audience for things like node-webkit.
> The web is for sharing content, not for games, text editors, and all that stuff. I see google trying to blur the lines between that, but why is it necessary?
Because innovation happens when you start thinking out of the box?
Innovation can happen when you start thinking out of the box. That doesn't mean it does happen. I don't find much about "webdev" to be terribly innovative. In many ways it is a large step backwards or sideways.
I agree that from a technology standpoint, the web development field is absolutely atrocious—at all levels. On the server side, broken languages control vast swaths of marketshare, and the client side has plenty of its own issues.
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.
I really should have made that singular—I was referring to PHP.
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.
More specifically, innovation happens when innovators push the limits of existing technologies (even if they're bad or not intended for that use) rather than waiting for the platform to catch up.
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.
"5 minutes"? Even if you had said "10 seconds", there's something wrong with your phone. Facebook on my Moto G starts up in under 2 seconds. Same with most other apps.
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.
Facebook sometimes takes at least 10 seconds to launch on my Nexus 5. While it's loading, all I see is a white screen. This happened both before and after upgrading to Lollipop. I'm running stock unrooted Android, and I don't notice issues with any other apps.
iPhone 4? Maybe there is something wrong with my phone, but my friends experience the same problem, so I'm assuming it's the app/platform combination. It also frequently crashes on start up.
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.
Then you should check out `about:blank`, a social network similar to ello but even faster.
As a developer there might be some benefits, but as a user I am firmly agains web apps for most classes of webapps (let's say except mail or cloudy stuff).
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.
The hype around HTML/JS as a substitute or replacement for native development has little to do with developer laziness and more to do with commoditizing software development labor.
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.
Web becomes a lot easier when you limit your target platforms. If you're shipping a thin browser-based shell around a web app and you know that you need to target Android 2.0+, iOS 6+, and Windows Phone 7, then you already know that you can eliminate many rendering engines (Firefox, Opera) as well as some of the old browser versions (IE < 10) that are usually the most problematic.
Which is also a problem for web. Compared to writing native apps you can get away with much more. You can be asked to help in projects where css like this was already written:
#updates > span > table > tbody > tr > td > span
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.
Commoditization is one aspect and that may be the case in some situations.
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.
You make it sound like there's no benefit to programmers to consolidating around a single platform. But there are several:
- 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.
All of your points apply to webdev. They just take a different form, and frequently are masked by mistaking the ease with which trivial apps can be developed by mixing a few canned frameworks together for reduced complexity.
This article doesn't accurately convey the state of Chrome Applications. There's actually a much richer way to build apps that have a more native look and feel, including their own branded top-level window with fewer of the limitations the author cites.
The article's title is "The State of Desktop Applications in Node.js", and chrome applications do not let you run node.js on the local machine. If you can't run your own userland code on the machine and talk to hardware, then you can hardly call it a desktop app.
Related question: what are the other ways to build a desktop application on Linux that works on Linux, Windows and OSX on slow machines, like intel atom, and doesn't require anything from the user?
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.
We ended up building Mac and Windows apps for http://www.webhook.com built on a Node / Chromium shells. Essentially we're a Wordpress competitor, but Node powered, and wanted to provide a simple one-click install for people that didn't know how to work their command line or how to install Node properly. This solution ended up working great. It basically allowed us to build a non-destructive sandbox dev environment for them that had a UI experience similar to the CMS itself. Better yet, the app points to hosted JS and CSS files so really there's never a need to "update" the app. When we have feature or bug changes, we just push out new files and everything just works.
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...
You see, I barely need to "understand" Java to use it and get decent and performant code but I need to be a javascript expert to be able to do anything not horrible.
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.
My argument was that the idea of having to work on a javascript project with >10,000 lines of code makes me want to vomit while the idea of working on a java project with >1,000,000 lines of code doesn't make me feel anything special.
People that complain about verbosity really don't have their priorities in line
Really? I feel js gives way more freedom and is much more forgiving to writing in your own particular style. I've had the exact opposite experience with Java.
I write JavaScript all the time for work and hobby and it's always rewarding.
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.
> 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.
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.
java interfaces are one of the main reasons people like java (and as other people have said, it's reimplementation in other more modern languages shows how popular and useful they are). They promote code reuse and allow protected variation. Your professors bad explanations aren't a reason to dislike interfaces.
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.
But I reuse code all the time with js, following DOT and DRY principles, just fine without an interface. Especially with tools like browserify, where I can basically manage my code as partials independent from each other. Also, I have had to write java code that uses polymorphism. I still find polymorphism easier in javascript. That being said, I think classes and polymorphism is kinda of all just nonsense.
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.
Can't I just take your glib statement and just reverse the roles (JS developer not understanding Java)? What makes JS development more misunderstood than Java development?
Maybe the fact that Java developers expect "typical" object model in JavaScript which doesn't exist, and JavaScript developers can use lot of their constructs in Java just fine (with the exception of functions which are not very different in Java, just more tedious).
I assume you once did a project where you were trying to make FactoryModelControllerInitWidgets in js? The fetishization of boilerplate doesn't work as well in js.
No, I have to deal with customers always disappointed that regardless the HTML 5 hype, browsers still cannot provide a UI experience like full blown native applications.
Writing UI components out of HTML/CSS/JavaScript glue is a joke compared with what native UI toolkits allow for.
I'm honestly curious: can you give some real examples of UI components that you customers blatantly refused when built in HTML/CSS/JS and praised when it was native?
What was that? Sliders, exotic buttons, reactive graphs?
What kind of applications are you selling?
We don't sell any application per se, we do enterprise consulting, everything goes.
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.
Thanks for the context. It appears that it's more a matter of business model than an effective superiority of java over webdev for doing UI.
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"?
I am coding since the web was born and was ridding the .COM and web 2.0 waves in web development. I am quite comfortable in web development, it doesn't mean I like it.
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.
Then it will be either not the same codebase as for webapp (having one is I suppose the most common reason for using web technology on desktop) or will require plugins.
Well they sort of already are if you take into account asm.js and the use of emscripten to compile native-language bytecode into it. But, I guess if you already have the native code for a desktop-only app...
While JavaFx and QML offer a better development environment(good IDEs with refactoring support, drag-and-drop designers etc), they cannot compete with the thousands of UI (and increasingly non-UI/utility) libraries that are out there for Javascript.
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.
I've played around with both node-webkit and atom-shell, and I prefer atom-shell over node-webkit, due to some minor inconveniences with node-webkit.
* 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 DOM performance, they are pretty much identical. Both use Chrome(each uses a different version though, usually atom-shell uses more recent versions).
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).
There are a number of ways to make desktop apps with JS. TideKit/TideSDK uses V8 IIRC. On Linux, Gnome has the GJS API. Tint and Quaxe are two more promising newcomers. All of these use a JS engine to create native platform UI controls. So for anyone who thinks JS is limited to webviews, you missed the boat. Thousands and thousands of native apps are already created and shipped on a JS core.
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.
The post mentions Light Table as a node-webkit user, so I'll mention that we're actually in the process of moving to atom-shell [1]. After having some issues with NW we found that atom-shell gave us a more suitable architecture and some nice desktop integration features for only a few days work.
The multi-process model is definitely more complex and probably not for everyone, but it's working really well for us so far.
I've been using node-webkit for the past 18 months or so, and it's been absolutely delightful.
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.
114 comments
[ 3.4 ms ] story [ 178 ms ] threadDoes 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."
http://blog.chriszacharias.com/page-weight-matters
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.
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.
multi-platform and easily bindable to any language
https://developer.chrome.com/apps/about_apps
Google wants to keep you locked in their sandbox.
http://qt-project.org/
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.
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...
https://vimeo.com/108922566
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.
* 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).
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.
The multi-process model is definitely more complex and probably not for everyone, but it's working really well for us so far.
[1] https://github.com/LightTable/LightTable/pull/1756
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.
http://macgapproject.github.io/
The packaged app is tiny compared to a chromium+Node shell app.
I'm not sure if it's still actively developed though.