4 ms·

"TL;DR: it's not Electron or Javascript which makes editors slow, it's how the code is written." It would not have been humanly possible to get something like

by tjoff 10y ago

"TL;DR: it's not Electron or Javascript which makes editors slow, it's how the code is written." It would not have been humanly possible to get something like Spotify (we have lists of text and icon-sized images) so resource intensive in any other language. Now if you want to spend ten (hundred?) times the effort to actually make javascript do something decent I truly hope you get pleasure from that sadistic adventure.

flohofwoe 10y ago
I don't know, writing extensions for VSCode in Typescript is actually quite pleasant. Sure it would be better to have a super-performant, super-small, cross-platform runtime environment. But what would that be? Qt? Java? .NET? Or another roll-your-own UI kit? PS: I think Spotify should have simply stayed in the browser, the desktop app is redundant.
- tjoff 10y ago
  Why not Qt? And, since this is Microsoft, why not take this opportunity to develop the backend in .NET core. But I yes the biggest impact javascript will have on mankind is that noone will ever be bothered to create a good foundation for cross platform applications. The desktop app is absolutely paramount for Spotify to stay relevant. Not sure if I've seen or heard of anyone using it in the browser (not that that is relevant, but I'd stop using it the very second I can't use it as a standalone app).
  - roblabla 10y ago
    Because Qt is a huge library. And it's not even really native outside of Linux KDE (though it's the closest we'll get cross-platform wise).
    - Johnny_Brahms 10y ago
      I don't want to be a part of the anti-electron crowd,but for something like a text editor qt will most certainly be smaller than electron.
    - mixedCase 10y ago
      It is huge, but so is Electron. It's as native as it gets, it imitates native widgets perfectly and allows the designer to easily recreate every element of a particular OS' HIGs with the use of stylesheets and native code. In before "doesn't look native in my macOS": Because the people writing in cross-plat tools usually don't care about getting every detail right, they just want their app to run well everywhere. But Qt does allow the developer to nail those details without too much effort if he actually cares. The only problem with Qt is C++.
      - roblabla 10y ago
        Been doing some research about my problems with qt. I found some interesting stuff. In qt6, there will be "native components" that use the actual underlying OS widgets[0]. They'll be less stylable, but will integrate better with the native look and feel. That should take care of the annoying cross-platform problems. The other problem left is how big it actually is. As it turns out, it's possible with the LGPL to statically link your program and still comply with the license[1]. Basically, you just need to provide a way to download the .o files so they can be relinked against a different version of Qt. Thanks to this, it should be possible to create (relatively) lightweight, statically-linked binaries of Qt software. As far as the C++ is involved... There are qt bindings for just about every other language out there. Just today, bindings for go were released[2]. The future is bright for qt and cross-platform apps. [0] http://blog.qt.io/blog/2017/02/06/native-look-feel/ http://blog.qt.io/blog/2017/02/06/native-look-feel/ [1]: https://news.ycombinator.com/item?id=4302517 https://news.ycombinator.com/item?id=4302517 [2]: https://news.ycombinator.com/item?id=14068525 https://news.ycombinator.com/item?id=14068525
        mixedCase 10y ago
        > As far as the C++ is involved... There are qt bindings for just about every other language out there. Absolutely not. And the ones that do work are ginormous. The Go bindings are LGPL licensed, meaning they aren't an option for most people until Go plugins are available across the board, at least. With that said, QML does have plenty of bindings, thankfully. And indeed, Qt's future looks bright, while Gtk's uncertain, so the former is definitely the saner option.
  - z3t4 10y ago
    What's the user benefit of a (JavaScript) "desktop" (Electron, nw.js) app vs the same app as a web (browser) app , given that the web app has all the features of the desktop app, when the app won't work without the server ? (if you can't run the server yourself) Benefits for a web app (non-desktop): * User don't have to download the "browser" (Electron or nw.js) * The user don't need "install" permissions * The app can be accessed via an URL * The app runs in a VM (a browser) that don't give full (root) access like a Electron/nw.js app does. btw, I did not know Spotify had a web app. There's only a tiny link to it at the bottom of the page, impossible to find unless you really look for it, witch is probably why no one is using it. P.S I'm now enjoying Spotify via the web app after not using it for years because I don't like "desktop" apps (for the reasons above)
    - obmelvin 10y ago
      It is much easier to navigate to the desktop app than to hunt through browser tabs to change the song etc.
      - deleted 10y ago
        [deleted]
    - yoz-y 10y ago
      Not à Spotify user but in general: - a native app can have global shortcuts (very important for a media player) - you don't accidentally refresh a native app - native apps don't get purged from memory at random - UI is generally better, keyboard shortcuts are more consistent
    - seangrogg 10y ago
      As a web developer that has never touched electron I would imagine the benefit is simple: * One API that "just works" * Guaranteed caching of necessary assets * Access to native features (such as simplified access to the file system) I could totally see all of this on the browser. But then the file system needs to go to the cloud, we need to consider hipster browsers (like k-meleon and omniweb), and we have to deal with the browser determining how our assets are cached and evicted.
  - Rapzid 10y ago
    VS Code didn't start out like you think it did. More akin to life forming in a petri dish vs sitting down to design the Visual Studio replacement. From what I recall piecing together it came about internally as MS due to monaco and TypeScript. I'm under the impression it was a TypeScript dogfood/dev environment project. It worked out well and they threw it over the fence to the public where it caught fire.
  - city41 10y ago
    > the biggest impact javascript will have on mankind is that noone will ever be bothered to create a good foundation for cross platform applications Why isn't Electron a good foundation for cross platform apps? The only possible negative to Electron is that the runtime is gigantic. A decent tradeoff if it means for example the VS Code team can support three OSes and push out rapid updates. I really can't see any downside to this, what am I missing?
z3t4 10y ago
use a stepping debugger to see what it does. then remove stuff that dont add value.
derefr 10y ago
Is Spotify's resource-intensiveness due to things it's actively doing in Javascript (i.e. a lot of procedural code running all the time), or is it due to things it sets up the DOM to do (i.e. a really complicated page that the renderer chokes on)?

by tjoff 10y ago

flohofwoe 10y ago

I don't know, writing extensions for VSCode in Typescript is actually quite pleasant. Sure it would be better to have a super-performant, super-small, cross-platform runtime environment. But what would that be? Qt? Java? .NET? Or another roll-your-own UI kit? PS: I think Spotify should have simply stayed in the browser, the desktop app is redundant.

tjoff 10y ago
Why not Qt? And, since this is Microsoft, why not take this opportunity to develop the backend in .NET core. But I yes the biggest impact javascript will have on mankind is that noone will ever be bothered to create a good foundation for cross platform applications. The desktop app is absolutely paramount for Spotify to stay relevant. Not sure if I've seen or heard of anyone using it in the browser (not that that is relevant, but I'd stop using it the very second I can't use it as a standalone app).
- roblabla 10y ago
  Because Qt is a huge library. And it's not even really native outside of Linux KDE (though it's the closest we'll get cross-platform wise).
  - Johnny_Brahms 10y ago
    I don't want to be a part of the anti-electron crowd,but for something like a text editor qt will most certainly be smaller than electron.
  - mixedCase 10y ago
    It is huge, but so is Electron. It's as native as it gets, it imitates native widgets perfectly and allows the designer to easily recreate every element of a particular OS' HIGs with the use of stylesheets and native code. In before "doesn't look native in my macOS": Because the people writing in cross-plat tools usually don't care about getting every detail right, they just want their app to run well everywhere. But Qt does allow the developer to nail those details without too much effort if he actually cares. The only problem with Qt is C++.
    - roblabla 10y ago
      Been doing some research about my problems with qt. I found some interesting stuff. In qt6, there will be "native components" that use the actual underlying OS widgets[0]. They'll be less stylable, but will integrate better with the native look and feel. That should take care of the annoying cross-platform problems. The other problem left is how big it actually is. As it turns out, it's possible with the LGPL to statically link your program and still comply with the license[1]. Basically, you just need to provide a way to download the .o files so they can be relinked against a different version of Qt. Thanks to this, it should be possible to create (relatively) lightweight, statically-linked binaries of Qt software. As far as the C++ is involved... There are qt bindings for just about every other language out there. Just today, bindings for go were released[2]. The future is bright for qt and cross-platform apps. [0] http://blog.qt.io/blog/2017/02/06/native-look-feel/ http://blog.qt.io/blog/2017/02/06/native-look-feel/ [1]: https://news.ycombinator.com/item?id=4302517 https://news.ycombinator.com/item?id=4302517 [2]: https://news.ycombinator.com/item?id=14068525 https://news.ycombinator.com/item?id=14068525
      - mixedCase 10y ago
        > As far as the C++ is involved... There are qt bindings for just about every other language out there. Absolutely not. And the ones that do work are ginormous. The Go bindings are LGPL licensed, meaning they aren't an option for most people until Go plugins are available across the board, at least. With that said, QML does have plenty of bindings, thankfully. And indeed, Qt's future looks bright, while Gtk's uncertain, so the former is definitely the saner option.
- z3t4 10y ago
  What's the user benefit of a (JavaScript) "desktop" (Electron, nw.js) app vs the same app as a web (browser) app , given that the web app has all the features of the desktop app, when the app won't work without the server ? (if you can't run the server yourself) Benefits for a web app (non-desktop): * User don't have to download the "browser" (Electron or nw.js) * The user don't need "install" permissions * The app can be accessed via an URL * The app runs in a VM (a browser) that don't give full (root) access like a Electron/nw.js app does. btw, I did not know Spotify had a web app. There's only a tiny link to it at the bottom of the page, impossible to find unless you really look for it, witch is probably why no one is using it. P.S I'm now enjoying Spotify via the web app after not using it for years because I don't like "desktop" apps (for the reasons above)
  - obmelvin 10y ago
    It is much easier to navigate to the desktop app than to hunt through browser tabs to change the song etc.
    - deleted 10y ago
      [deleted]
  - yoz-y 10y ago
    Not à Spotify user but in general: - a native app can have global shortcuts (very important for a media player) - you don't accidentally refresh a native app - native apps don't get purged from memory at random - UI is generally better, keyboard shortcuts are more consistent
  - seangrogg 10y ago
    As a web developer that has never touched electron I would imagine the benefit is simple: * One API that "just works" * Guaranteed caching of necessary assets * Access to native features (such as simplified access to the file system) I could totally see all of this on the browser. But then the file system needs to go to the cloud, we need to consider hipster browsers (like k-meleon and omniweb), and we have to deal with the browser determining how our assets are cached and evicted.
- Rapzid 10y ago
  VS Code didn't start out like you think it did. More akin to life forming in a petri dish vs sitting down to design the Visual Studio replacement. From what I recall piecing together it came about internally as MS due to monaco and TypeScript. I'm under the impression it was a TypeScript dogfood/dev environment project. It worked out well and they threw it over the fence to the public where it caught fire.
- city41 10y ago
  > the biggest impact javascript will have on mankind is that noone will ever be bothered to create a good foundation for cross platform applications Why isn't Electron a good foundation for cross platform apps? The only possible negative to Electron is that the runtime is gigantic. A decent tradeoff if it means for example the VS Code team can support three OSes and push out rapid updates. I really can't see any downside to this, what am I missing?

z3t4 10y ago

use a stepping debugger to see what it does. then remove stuff that dont add value.

derefr 10y ago

Is Spotify's resource-intensiveness due to things it's actively doing in Javascript (i.e. a lot of procedural code running all the time), or is it due to things it sets up the DOM to do (i.e. a really complicated page that the renderer chokes on)?