The State of Desktop Applications in Node.js • Hacker News Board

Re: The State of Desktop Applications in Node.js

#81

Post by Iftheshoefits » Wed, Dec 10, 2014, 8:28 PM UTC

smacktoward wrote: post #66

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.

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

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.

Re: The State of Desktop Applications in Node.js

#82

Post by ksherlock » Wed, Dec 10, 2014, 8:30 PM UTC

zzzcpan wrote: post #15

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?

Qt, WxWidgets, SDL, zoolib, Java (I guess that require something), python [http://docs.python-guide.org/en/latest/scenarios/gui/]

Re: The State of Desktop Applications in Node.js

#83

Post by pjmlp » Wed, Dec 10, 2014, 8:34 PM UTC

echoless wrote: post #68

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.

Ah, you mean the flavour of the month?

The endless UI factory churn of the web world?

Re: The State of Desktop Applications in Node.js

#84

Post by pjmlp » Wed, Dec 10, 2014, 8:36 PM UTC

woah wrote: post #73

pjmlp wrote: post #60

Earlier quoted context omitted.

Java development is pure pleasure when compared with web development.

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.

Re: The State of Desktop Applications in Node.js

#85

Post by nawitus » Wed, Dec 10, 2014, 8:49 PM UTC

mempko wrote: post #38

nawitus wrote: post #6

Earlier quoted context omitted.

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

Having apps magically always update without user consent is developer friendly, but not user friendly. Have you ever used a web app that changed in ways you didn't like?

I'd say "not always user friendly". There are of course drawbacks with web apps.

Re: The State of Desktop Applications in Node.js

#86

Post by Dewie » Wed, Dec 10, 2014, 8:50 PM UTC

jekrb wrote: post #72

pjmlp wrote: post #60

Earlier quoted context omitted.

Java development is pure pleasure when compared with web development.

Edit: Oh I get it, that was satire.

Java and JS have both been at the butt end of many a joke, probably including satire.

Re: The State of Desktop Applications in Node.js

#87

Post by echoless » Wed, Dec 10, 2014, 9:00 PM UTC

pjmlp wrote: post #83

echoless wrote: post #68

Earlier quoted context omitted.

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.

Ah, you mean the flavour of the month? The endless UI factory churn of the web world?

> Ah, you mean the flavour of the month?

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.

Re: The State of Desktop Applications in Node.js

#88

Post by gloriousduke » Wed, Dec 10, 2014, 9:06 PM UTC

Iftheshoefits wrote: post #63

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.

And until browsers become something like full-fledged virtual machines, it always will be, I think.

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

Re: The State of Desktop Applications in Node.js

#89

Post by mateuszf » Wed, Dec 10, 2014, 9:09 PM UTC

Dewie wrote: post #77

mateuszf wrote: post #64

Earlier quoted context omitted.

Usually said by Java developer not understanding JavaScript.

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

Re: The State of Desktop Applications in Node.js

#90

Post by kyllo » Wed, Dec 10, 2014, 9:11 PM UTC

evilduck wrote: post #34

kyllo wrote: post #30

Earlier quoted context omitted.

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.

30 seconds to launch!? Are you running it on a RaspberryPi or something? On my MBP, it launches about as fast as SublimeText3, 1-2 seconds tops.

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.