Hacker News new | past | comments | ask | show | jobs | submit login

> This leaves JS native-like apps for those that care about doing things fast by only using the knowledge they already have.

What about the devs who care about shipping a lockstep-feature-parity multiplatform app, and are willing to go through whatever hassles it takes to get "write once, run [with platform-conformant controls + behaviors] anywhere"? Because that—and not "doing things fast" or "only using the knowledge they already have"—is the argument I hear for developing Electron apps.

What would you suggest for those developers? Just give up on their desires and do 10x as much work (likely meaning being 10x as many people) to ship for every platform, like Facebook? Or go through months/years of initial effort to develop a cross-platform UI toolkit abstraction to build their app upon, like the browser chrome of Firefox and Chrome is targeted at? Use something like Java's Swing, and pretend that's better just because "at least it's not Javascript"? Ship a GTK or QT app that doesn't look/work natively on half your platforms?




When I've worked on multi-platform apps, the case for "write once, run anywhere" has always boiled down to developer hours and current knowledge. Sometimes someone suggests that a single GUI will mean less code and fewer bugs, but the ones with cross-platform GUI experience know that's optimistic.

"10x as much work" is a huge overstatement, especially when platform conformance is a goal.

For native look and feel, I'd pick Qt over Electron any day. The catch is that no toolkit can abstract away all the platform-specific details. A minimum-effort Electron app looks like a web page; a minimum-effort Qt app falls into the uncanny valley.

There can be good reasons to choose Electron! But it also has drawbacks, and it isn't the only option.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: