Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Desktop Applications in Node.js

nodesource.com

Post reply on HN
Print view View original

41–50 of 115 posts

Re: The State of Desktop Applications in Node.js

#41

Post by echoless »

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

Re: The State of Desktop Applications in Node.js

#42

Post by gagege »

pjmlp wrote: post #37
Iftheshoefits wrote: post #21

Earlier quoted context omitted.

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.

I have lots of UI toolkits under my belt since the mid-80's, been doing web development on and off since the .com days. When compared with RAD tooling like Delphi or XAML, HTML/CSS/JS is anything but easy.

Even WinForms is a breeze compared to all the quirks of the web.

Re: The State of Desktop Applications in Node.js

#43

Post by doublerebel »

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.

Re: The State of Desktop Applications in Node.js

#44

Post by organsnyder »

gagege wrote: post #40
jekrb wrote: post #20

Earlier quoted context omitted.

|slow, shitty "web apps" 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…

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

Re: The State of Desktop Applications in Node.js

#45

Post by jiggy2011 »

cyorir wrote: post #35
jiggy2011 wrote: post #28

Earlier quoted context omitted.

You could install more than 1000 apps on a moderate SSD at 100MB each. How many apps does the average person have installed?

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.

If your media is 337GB then you must already be storing it somewhere other than your 256GB SSD!

Besides, does it matter much if you delete an app when it can be downloaded again in a matter of minutes?

Re: The State of Desktop Applications in Node.js

#46

Post by organsnyder »

gagege wrote: post #42
pjmlp wrote: post #37

Earlier quoted context omitted.

I have lots of UI toolkits under my belt since the mid-80's, been doing web development on and off since the .com days. When compared with RAD tooling like Delphi or XAML, HTML/CSS/JS is anything but easy.

Even WinForms is a breeze compared to all the quirks of the web.

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.

Re: The State of Desktop Applications in Node.js

#48

Post by jekrb »

gagege wrote: post #40
jekrb wrote: post #20

Earlier quoted context omitted.

|slow, shitty "web apps" 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…

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

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.

Re: The State of Desktop Applications in Node.js

#49

Post by organsnyder »

bpizzi wrote: post #13
mid-kid wrote: post #4

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 peop…

> 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?

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.

Re: The State of Desktop Applications in Node.js

#50

Post by organsnyder »

Iftheshoefits wrote: post #26
bpizzi wrote: post #13

Earlier quoted context omitted.

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

Post reply on HN