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

61–70 of 115 posts

Re: The State of Desktop Applications in Node.js

#61

Post by pjmlp »

organsnyder wrote: post #46
gagege wrote: post #42

Earlier quoted context omitted.

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.

Try to explain to customers holding payments, why the web page looks different across multiple handsets using the same browser.

Re: The State of Desktop Applications in Node.js

#62

Post by mateuszf »

pjmlp wrote: post #39

2014, still catching up with the desktop. If one really really wants to use JavaScript, at least make use of QML or Nashorn/JavaFX.

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.

Re: The State of Desktop Applications in Node.js

#65

Post by echoless »

ep103 wrote: post #52
echoless wrote: post #41

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

completely clueless programmer checking in. How is atom's performance? The one app I tried that used it was always slow and cludgy...

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

Re: The State of Desktop Applications in Node.js

#66

Post by smacktoward »

Iftheshoefits wrote: post #21
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 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.

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.

Re: The State of Desktop Applications in Node.js

#67

Post by one-more-minute »

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.

[1] https://github.com/LightTable/LightTable/pull/1756

Re: The State of Desktop Applications in Node.js

#68

Post by echoless »

pjmlp wrote: post #39

2014, still catching up with the desktop. If one really really wants to use JavaScript, at least make use of QML or Nashorn/JavaFX.

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.

Re: The State of Desktop Applications in Node.js

#69

Post by benjismith »

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.

Post reply on HN