Hacker News Reader

Comment by podperson | Hacker News Reader

The underlying runtime technology -- node-webkit -- seems pretty interesting.

This particular workflow would be more interesting to me if it was clearer that you could pick and choose your tools. I don't want to use Angular, Jade, or Coffeescript (for example). And (as per another thread) a workflow that included an out-of-box offline data storage option would be nice.

As I understand it, if I don't use tools that have a "compilation" phase, my workflow using node-webkit would be to save my files and restart node-webkit, right?

View on HN

It depends. At least before finally building your executables, you might want to concat & minify your assets and so on, since this will heavily increase the startup time of your app if you don't. (been there, done that, ... :D)

To generate the final executables, you'll end up hacking together some shell scripts or the like, at least if you do this on a regular basis.

Both points together: an automated asset pipeline and an easy-to-use build tool is included.

+1 for the data storage part, i'd love to hear some deeper thoughts in the github issues part...

about the chosen technologies: these are my preferences. After spreading my app skeleton idea I expect similar stuff to emerge for other personal preferences. But finally: one of my main goals of spreading the word here is to bring the idea of node-webkit to the folks, since this is an awesome open source project and could use some more helping hands.

Thanks for putting this together! Do you have any links to scripts or examples for doing the packaging as you mention? I've been trying to keep my eye on this for a while and never seem to find anything.

I think really the holy grail for a lot of people is an app built with web utils and running on node - but having some type of packaging system to create executables that look just like any other desktop app.

I know there's various options out there but it seems like Chromium is the cleanest - Just everything I found wants you to install it as a browser "app" or plugin or whatever.

the packaging just works, just type `npm run deploy`. It uses https://github.com/mllrsohn/grunt-node-webkit-builder behind the scenes.

You'll get a native executable for Windows, OSX and Linux32/64, ready to ship and double-click-able. Isn't this what you want? :)

ah that's fantastic - I mis-read and thought that was how you launch the app, rather than package it. thanks!

I ended up writing one app (and making significant headway on a second) using node-webkit yesterday, so many thanks for bringing it to my attention.

In general, a web app has to get pretty ridiculously bloated for javascript minification and so forth to impact launch time on a local file system. I'd call this premature optimization. (In my day job we're working on a pretty huge web app and we don't use any build process except -- just recently -- precompiling our LESS files (mainly to handle IE and mobile devices)). For us, the downside of a build-process to the debug cycle is a far bigger hit than the benefit of minification. (Perhaps we were overreacting to another project which used maven and had 2-3 minute builds...)

Of course if you're using coffeescript or clojurescript or whatever there's no avoiding some kind of build process.

It strikes me that automating and simplifying the build process is exactly the kind of thing you could wrap up in a pretty nice node-webkit application!

The sky is the limit, node-webkit is indeed very powerful when you know what you're doing.

For the build process: just try it with brunch, e.g.: with my skeleton (a simple todo app is included for playing around). It will take ~4sec to start up initially, but then work close to perceived realtime, taking 50ms or so on my machine to reflect any changes you do, plus: livereload automatically the browser window, so you actually save the "press reload" step in most cases.

And: since i'm using only meta-languages that require a compile-step (!), i have basically a useful error-checking (incl. linting!) on coding time, without time-intensive inspecting the result in-browser. Do not underestimate this. Sure, finally i have to confirm in the browser (and/or testsuite) that everything works, but typos and other common bugs are "growled" as i type.

> Do not underestimate this.

Absolutely. But don't overestimate it either! Most serious bugs compile perfectly well -- and so you're trading quick detection of simple errors for more difficulty dealing with the hard stuff.

The nice thing is, that brunch automatically generates proper sourcemaps, so you can debug your application pretty well. Soooo, you have the little stuff catched instantly and are able to debug higher-abstraction code (!) without much hassle. Of course, this just works in my specific case that simple... :)

Reply on news.ycombinator.com