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

101–110 of 115 posts

Re: The State of Desktop Applications in Node.js

#101

Post by woah »

jekrb wrote: post #98
penprog wrote: post #96

Earlier quoted context omitted.

java interfaces are one of the main reasons people like java (and as other people have said, it's reimplementation in other more modern languages shows how popular and useful they are). They promote code reuse and allow protected variation. Your professors bad explanations aren't a reason to dislike interfaces. Also how have you not, in a java class, written code that uses polymorphism? That would be the easiest way…

But I reuse code all the time with js, following DOT and DRY principles, just fine without an interface. Especially with tools like browserify, where I can basically manage my code as partials independent from each other. Also, I have had to write java code that uses polymorphism. I still find polymorphism easier in javascript. That being said, I think classes and polymorphism is kinda of all just nonsense. My prefer…

I agree. An interface in JS is a unit test.

I think that a lot of "classical" programmers simply don't understand how important modules are to JS development.

This is why you get these posts about "how can you manage 1,000,000 LOC in JS!!?", when they don't understand that you never have 1,000,000 in JS, you have a bunch of small, unit tested modules.

Re: The State of Desktop Applications in Node.js

#102

Post by pjmlp »

woah wrote: post #101
jekrb wrote: post #98

Earlier quoted context omitted.

But I reuse code all the time with js, following DOT and DRY principles, just fine without an interface. Especially with tools like browserify, where I can basically manage my code as partials independent from each other. Also, I have had to write java code that uses polymorphism. I still find polymorphism easier in javascript. That being said, I think classes and polymorphism is kinda of all just nonsense. My prefer…

I agree. An interface in JS is a unit test. I think that a lot of "classical" programmers simply don't understand how important modules are to JS development. This is why you get these posts about "how can you manage 1,000,000 LOC in JS!!?", when they don't understand that you never have 1,000,000 in JS, you have a bunch of small, unit tested modules.

Because in the real boys club (aka enterprise) no one writes unit tests unless they are imposed on them.

Re: The State of Desktop Applications in Node.js

#103

Post by pjmlp »

woah wrote: post #100
penprog wrote: post #79

Earlier quoted context omitted.

My argument was that the idea of having to work on a javascript project with >10,000 lines of code makes me want to vomit while the idea of working on a java project with >1,000,000 lines of code doesn't make me feel anything special. People that complain about verbosity really don't have their priorities in line

The point of Javascript is that projects don't get to 10,000 lines. If a project is this big, you have failed. Bragging about LOC is one of the most ridiculous things ever, since it is a bad thing.

Have you ever gotten to review enterprise code done by multiple teams with offshoring?

Re: The State of Desktop Applications in Node.js

#104

Post by [deleted] »

woah wrote: post #100
penprog wrote: post #79

Earlier quoted context omitted.

My argument was that the idea of having to work on a javascript project with >10,000 lines of code makes me want to vomit while the idea of working on a java project with >1,000,000 lines of code doesn't make me feel anything special. People that complain about verbosity really don't have their priorities in line

The point of Javascript is that projects don't get to 10,000 lines. If a project is this big, you have failed. Bragging about LOC is one of the most ridiculous things ever, since it is a bad thing.

[deleted]

Re: The State of Desktop Applications in Node.js

#106

Post by pjmlp »

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…

You can have all of that without a CSS/HTML/JavaScript Frankenstein.

Re: The State of Desktop Applications in Node.js

#107

Post by bpizzi »

pjmlp wrote: post #84
woah wrote: post #73

Earlier quoted context omitted.

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.

I'm honestly curious: can you give some real examples of UI components that you customers blatantly refused when built in HTML/CSS/JS and praised when it was native?

What was that? Sliders, exotic buttons, reactive graphs? What kind of applications are you selling?

Re: The State of Desktop Applications in Node.js

#109

Post by blub »

jekrb wrote: post #20
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…

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

As a developer there might be some benefits, but as a user I am firmly agains web apps for most classes of webapps (let's say except mail or cloudy stuff).

First of all, webapps almost always screw something up in the UI. If they're wrapped in a native container maybe they scroll differently, they don't respond to some gestures, are missing some menu entires or make other small mistakes. Depending on the user this can be mildly annoying or just strange for them.

Secondly, web apps make customers dependent on something they have no control of. That cool startup might close shop tomorrow and if you're lucky they'll give you one week to export your data. The company might decide to pivot or charge more or a myriad other possibilities and the customer has no choice but to either cancel the service or deal with it. I can give you an example of many iOS users that are still on 7 because some apps were broken by the update - they can do that with apps and we're talking about iOS here, desktop is even more flexible.

Thirdly, speed. Ironically, Facebook themselves admitted that they made a huge mistake by using webviews because this made their app incredibly slow. Your case is almost impossible to believe, and indicates that something is completely broken in your software configuration. In most cases a native app will outperform a web app, from the UI speed (scrolling, panning, drag & drop, viewing documents) to performing various tasks. It's quite logical, as a native app has direct access to all APIs, while a webapp has to go through N intermediate layers.

Re: The State of Desktop Applications in Node.js

#110

Post by pjmlp »

bpizzi wrote: post #107
pjmlp wrote: post #84

Earlier quoted context omitted.

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.

I'm honestly curious: can you give some real examples of UI components that you customers blatantly refused when built in HTML/CSS/JS and praised when it was native? What was that? Sliders, exotic buttons, reactive graphs? What kind of applications are you selling?

We don't sell any application per se, we do enterprise consulting, everything goes.

Customer comes with Powerpoint/Photoshop mockup of their idea, based on how native UIs work.

Usually when it comes down to paying, there should be a 1:1 correspondence to their idea, across all requested devices.

While native UIs allow for full control down to pixel level and hooks on control behaviors.

Web requires a CSS/HTML/JavaScript magic mix to make it work properly across all requested browsers and devices, and still not good enough for some.

A recent example was a control for file uploads and the information that should be displayed while the file was loading. The files were too big to be processed server side and HTML 5 File API doesn't provide all the required features.

Post reply on HN