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

51–60 of 115 posts

Re: The State of Desktop Applications in Node.js

#51

Post by callum85 »

Carrok wrote: post #36
callum85 wrote: post #31

Earlier quoted context omitted.

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.

>as a user, I would be very suspicious of a 100MB countdown timer app You mean as a developer. Your average 'user' does not know or care how big an app 'should' be.

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

Re: The State of Desktop Applications in Node.js

#52

Post by ep103 »

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

Re: The State of Desktop Applications in Node.js

#53

Post by FooBarWidget »

callum85 wrote: post #24
FooBarWidget wrote: post #11

Earlier quoted context omitted.

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

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.

VLC is 106 MB. Do you care? I don't, it plays my videos well.

Re: The State of Desktop Applications in Node.js

#54

Post by evv »

rrdharan wrote: post #12

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. https://developer.chrome.com/apps/about_apps

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.

Google wants to keep you locked in their sandbox.

Re: The State of Desktop Applications in Node.js

#56

Post by jekrb »

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.

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.

Re: The State of Desktop Applications in Node.js

#57

Post by dkersten »

dnissley wrote: post #14
depr wrote: post #7

Earlier quoted context omitted.

Also, if you're making a desktop app you don't have to use HTML/JS, why on earth would you use those if you don't absolutely have to?

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?

Qt

Re: The State of Desktop Applications in Node.js

#58

Post by dshaw7 »

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.

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.

Re: The State of Desktop Applications in Node.js

#59

Post by hamoid »

FooBarWidget wrote: post #11
callum85 wrote: post #2

Last time I tried building a 'blank' node-webkit app for OS X (using https://github.com/Dica-Developer/generator-node-webkit ), the resulting .app came to ~100MB. Does anyone know the base size for an atom-shell app?

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

Our connections and cpus get faster, our memories and hard drives larger, but then we write slower and bigger software to compensate.

It reminds me of Newton's third law: "For every action, there is an equal and opposite reaction."

Re: The State of Desktop Applications in Node.js

#60

Post by pjmlp »

woah wrote: post #47
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.

Just for the delicious pain of Java development?

Java development is pure pleasure when compared with web development.
Post reply on HN