4 ms·

Historically, I have found that dismissing an otherwise effective technology due to performance is a bad idea. Fifteen years ago I dismissed Java in favour of C

by hliyan 10y ago

Historically, I have found that dismissing an otherwise effective technology due to performance is a bad idea. Fifteen years ago I dismissed Java in favour of C++ because at the time the JVM was about 25 times slower than native. Now I regret not investing more time learning Java. I suspect the same will be true of HTML/JS apps in the next few years. Hardware and performance improvements will likely erase any differences.

rco8786 10y ago
Yes! Right now Electron is the easiest way to build cross OS desktop apps, bar none. Just like Java was the easiest way to write cross platform code back then. Dismissing it for performance reasons is a fool's errand. The performance issues are fixable and we're already seeing them get fixed. Bold prediction - JavaScript(or rather, a future incarnation of it resembling es7/es8) will be the lingua franca for all platforms(web, desktop, and mobile) within a decade.
psyc 10y ago
15 years ago, I believed that one day, generational garbage collection would be so good that I wouldn't have to think about it. I'm no longer holding my breath for that day.
blub 10y ago
I also dismissed Java for a long time until a few years ago when I developed a mobile project in Java and unfortunately did encounter over-architecting and lack of interest in performance as expected. On the other hand, I can't say I disliked using the language, even if I found it quite restrictive. Java is a pragmatic tool, it's not about fun or expressiveness but making a team of average or better engineers build something that works. And it does that very well. Now that I've had that experience, I know it's not for me, but I can understand when a tool like Java makes sense. JavaScript vs anything else is not the same as C++ vs Java, because JavaScript is not an effective technology to build software applications in. It never was and likely won't become one. It has a weak type system and non-existant standard library. Must be run in a packaged browser. Anything UI-related must be done by using a document markup language and style sheets. The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.
- pcwalton 10y ago
  > It has a weak type system Dynamic typing is useful. The "native" Objective-C is dynamically typed, for example. Static typing is useful too. If history has shown anything, it's shown that both dynamic typing and static typing have their places, and trying to argue that one is superior to the other in all circumstances is one of the most boring arguments imaginable. > non-existant standard library This is more or less a deliberate design choice, because there are many implementations of JS and that multiplies the probability of incompatibility. Consider the headaches that have arisen between Microsoft's STL and GNU's STL... > Must be run in a packaged browser Node? This is obviously false. > Anything UI-related must be done by using a document markup language It's an effective retained mode tree of nodes, with a whole lot more optimizations than any native toolkit I know of. (Look at how the childNodes array is implemented sometime, for example; no native toolkit does the kind of caching that browsers do...) > style sheets Style sheets are a great idea. They're becoming increasingly popular for native development nowadays (Qt, GTK, etc.) > The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top. I'm as much of a critic of current browser design as anyone, but this is mostly the fault of old browser designs. The Web platform has a lot more potential for performance than things like the Win32 API, as I've elaborated on in many other posts.
  - blub 10y ago
    It's useful, but when that's the only tool one has, it becomes a liability. I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble. Some teams make enough of an effort that they are able to deliver such an app. That should not be encouraged, but rather criticized as encouraging development practices. To be clear: they can do whatever they want in their projects. I have a problem when they recommend such methods to others, without being honest about the pitfalls and effort involved. Re standard library: the STL is currently working great! JS would kill to have something as stable and high quality as the STL. Re node: I am not aware of any desktop or mobile apps using node. Isn't that a server-side technology? Re markup: does it matter how much optimized it is and how much caching it does when in the end it's still slow? Re style sheets: they're great when used for styling, like in Qt (not sure what GTK is doing). But that doesn't scale when building widgets and doing positioning. pcwalton, web apps have had the potential to do X, Y and Z better than native apps for the past decade. At one point web developers need to talk less and deliver.

by hliyan 10y ago

rco8786 10y ago

Yes! Right now Electron is the easiest way to build cross OS desktop apps, bar none. Just like Java was the easiest way to write cross platform code back then. Dismissing it for performance reasons is a fool's errand. The performance issues are fixable and we're already seeing them get fixed. Bold prediction - JavaScript(or rather, a future incarnation of it resembling es7/es8) will be the lingua franca for all platforms(web, desktop, and mobile) within a decade.

psyc 10y ago

15 years ago, I believed that one day, generational garbage collection would be so good that I wouldn't have to think about it. I'm no longer holding my breath for that day.

blub 10y ago

I also dismissed Java for a long time until a few years ago when I developed a mobile project in Java and unfortunately did encounter over-architecting and lack of interest in performance as expected. On the other hand, I can't say I disliked using the language, even if I found it quite restrictive. Java is a pragmatic tool, it's not about fun or expressiveness but making a team of average or better engineers build something that works. And it does that very well. Now that I've had that experience, I know it's not for me, but I can understand when a tool like Java makes sense. JavaScript vs anything else is not the same as C++ vs Java, because JavaScript is not an effective technology to build software applications in. It never was and likely won't become one. It has a weak type system and non-existant standard library. Must be run in a packaged browser. Anything UI-related must be done by using a document markup language and style sheets. The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.

pcwalton 10y ago
> It has a weak type system Dynamic typing is useful. The "native" Objective-C is dynamically typed, for example. Static typing is useful too. If history has shown anything, it's shown that both dynamic typing and static typing have their places, and trying to argue that one is superior to the other in all circumstances is one of the most boring arguments imaginable. > non-existant standard library This is more or less a deliberate design choice, because there are many implementations of JS and that multiplies the probability of incompatibility. Consider the headaches that have arisen between Microsoft's STL and GNU's STL... > Must be run in a packaged browser Node? This is obviously false. > Anything UI-related must be done by using a document markup language It's an effective retained mode tree of nodes, with a whole lot more optimizations than any native toolkit I know of. (Look at how the childNodes array is implemented sometime, for example; no native toolkit does the kind of caching that browsers do...) > style sheets Style sheets are a great idea. They're becoming increasingly popular for native development nowadays (Qt, GTK, etc.) > The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top. I'm as much of a critic of current browser design as anyone, but this is mostly the fault of old browser designs. The Web platform has a lot more potential for performance than things like the Win32 API, as I've elaborated on in many other posts.
- blub 10y ago
  It's useful, but when that's the only tool one has, it becomes a liability. I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble. Some teams make enough of an effort that they are able to deliver such an app. That should not be encouraged, but rather criticized as encouraging development practices. To be clear: they can do whatever they want in their projects. I have a problem when they recommend such methods to others, without being honest about the pitfalls and effort involved. Re standard library: the STL is currently working great! JS would kill to have something as stable and high quality as the STL. Re node: I am not aware of any desktop or mobile apps using node. Isn't that a server-side technology? Re markup: does it matter how much optimized it is and how much caching it does when in the end it's still slow? Re style sheets: they're great when used for styling, like in Qt (not sure what GTK is doing). But that doesn't scale when building widgets and doing positioning. pcwalton, web apps have had the potential to do X, Y and Z better than native apps for the past decade. At one point web developers need to talk less and deliver.