Its a sad direction for software development. Just bundling applications inside a browser and releasing it as a “app”.
Then saying that there is enough CPU/RAM to waste, for example Spotify can take up to 30 seconds to launch. All it has to do is to steam music, display lists with some images.
Javascript has its places and uses, but building desktop applications on top of it is just lazy.
On the one hand, I generally agree that the bundled-up-webpage style of “native” app development results in a crappy product. There’s plenty of examples of this.
On the other hand, specifically in the case of Atom, which is trying to be a sort-of 21st century Emacs, it makes a lot of sense to want the UI to be expressible as a well-understood, easy-to-work-with DOM.
This enables plugins to do a lot of things with UI that are hard-or-downright impossible in Emacs' ad-hoc, highly limited UI modification hooks (it’s damn near impossible just to draw a vertical line in emacs).
Is HTML the optimal DOM for a text-editor-cum-programming-environment? No. But it’s well-known and well-understood, and starting from scratch would have taken a lot longer.
Is this just due to the performance hit you take by running slower non-native ui code or do you have something else against the web tech on the desktop model?
I have mixed feelings about this. On the one hand as you said native code is always going to be faster, “feel better” (tighter intergration with the rest of the system), etc. However a lot of native GUI frameworks are pretty messy. (Anyone who has worked with GTK will likely know the pain that it brings). The web model at least provides a nice separation between the design and the program logic. (There are other more native frameworks that do this to some extent, but I feel this is still a significant reason why the web model is used so much). I also like how the web model allows for portability and distributivity with (relative) ease. This does not mean that I feel the electron/node-webkit method of developing software is a good one, and I personally can’t stand using programs made in this way, if for no other reason than my PC is relatively old and the slowdown is noticeable. I do think native frameworks have something to learn from the web, and in an ideal world I would like to see some kind of method of building GUIs that can be served over the web or natively and function well in both instances.
I also have mixed opinions, in part because while I’m a bit skeptical of the webtech-everywhere trend, the native-GUI-toolkit side of things is a gigantic mess too, and often not even that native. There are definitely people who do write 100% native GUI applications, but that requires going all-in on one platform. A fairly strong niche are the people who develop OSX-only applications, using all the Apple APIs directly, trying to do things in line with the OSX norms and look-and-feel guidelines, etc. The downside is that when you go all-in on native OSX like this, your app only runs on OSX.
The in-between option is a cross-platform toolkit that translates to the native GUI toolkit. That ends up as a kind of halfway house, using the native widgets to get as close to a native look-and-feel as possible, but by necessity not quite using them idiomatically, because they need to be unified or abstracted over in a way that can target a bunch of platforms simultaneously. GTK, Qt, and Java’s Swing sort of fit in there, and while they work, I wouldn’t really go out of my way to sing their praises as the one true way to do GUIs.
You can even sort of see the wrapped-webkit type of app as a roundabout realization of something that was a goal of a lot of desktop-Linux people in the late ‘90s: that instead of people writing GUI apps to a specific platform’s toolkit (usually Windows), the GUI layer should be done in a library, with the platform only needing to provide something relatively low-level and common, like a framebuffer to draw the widgets in. Tk was an attempt at that that enjoyed some success for a time.
the one unreservedly good thing i can say about web-on-the-desktop is that it’s the lazy way to develop applications. “lazy” means that you have done what you wanted to do with the least amount of fighting with various toolkits, languages, etc that make your task harder. the fact that you pay the price in cpu and ram consumption and potentially in responsiveness is a huge drawback, but that just means that no one has made a good enough “lazy” alternative yet.
Partly, yes, it’s due to the performance. Even on a fast computer, if you open enough such apps, the entire computer will end up slowing down. However, I also find the tendency of the web tech model to try applying itself to everything a tad… superfluous and useless.
Originally, HTML was designed to add links to a markup language, then CSS was added to stylize it, and finally JS was added as a scripting language for the web. Since then, it has all been evolved into being used for nearly everything, from text editors to web browsers. It wasn’t designed for this; it was designed as a way to display text, and link to other text. Nowadays, HTML and CSS seem to have become a UI specification that is difficult for both computers and humans alike to process, and JS has become a haphazardly thrown together mess⁰ with the mindset that it should encompass everything.
Personally, I can understand the urge to try to get something to do everything¹, but that of course means that there comes an increase in complexity. Complexity is usually never good, you end up with things like this or this happening. Complexity also causes speed issues, which is what the majority people seem to dislike about such efforts. However, mainly I find the complexity of a web browser sitting atop the complexity of an operating system sitting atop the complexity of a backwards-compatible CPU to be appalling to think about². We might as well create an operating system that is mostly a web browser to help reduce complexity.
It is the very attempt to use “web tech on the desktop model” that I dislike about it, not merely side effects such as the performance hit. In the past, we’ve made SMTP become a file-sharing mechanism and made unicode become a clip-art provider. Maybe this time, we should spend more time figuring out what we want the web to do, instead of haphazardly forcing it to do everything³.
⁰ Admittedly, JS is trying to become better. ¹ I admit, it is quite fun to make something do something it wasn’t explicitly designed to do. ² Being the hypocrite that I am, though, this doesn’t preclude me from actually using a web browser on OS X on an Intel i5 chip to share these thoughts with you. This is mainly because it seems to work well enough for now, and it looks nice. ³ Whoops, too late, it’s already used for everything. :(
I don’t know whether I’m happy or depressed this exists. I’m a bit happy because it’s a great place to point people who are a little too eager to do everything in a web browser, however the existence of such a project makes me think that maybe we should all move over to TempleOS.
Personally, my main reason for not using Atom as an editor is because it’s a web browser.
Its a sad direction for software development. Just bundling applications inside a browser and releasing it as a “app”.
Then saying that there is enough CPU/RAM to waste, for example Spotify can take up to 30 seconds to launch. All it has to do is to steam music, display lists with some images.
Javascript has its places and uses, but building desktop applications on top of it is just lazy.
On the one hand, I generally agree that the bundled-up-webpage style of “native” app development results in a crappy product. There’s plenty of examples of this.
On the other hand, specifically in the case of Atom, which is trying to be a sort-of 21st century Emacs, it makes a lot of sense to want the UI to be expressible as a well-understood, easy-to-work-with DOM.
This enables plugins to do a lot of things with UI that are hard-or-downright impossible in Emacs' ad-hoc, highly limited UI modification hooks (it’s damn near impossible just to draw a vertical line in emacs).
Is HTML the optimal DOM for a text-editor-cum-programming-environment? No. But it’s well-known and well-understood, and starting from scratch would have taken a lot longer.
Would picture-mode do the trick? It’s a mode for creating ASCII art.
I think he means a marker for a column.
I learned about picture-mode thanks to this comment. SO COOL!! Thank you! BRB making all the ascii arts…
Is this just due to the performance hit you take by running slower non-native ui code or do you have something else against the web tech on the desktop model?
Its lazy way to develop applications and can never be as good as native application build on native code.
I have mixed feelings about this. On the one hand as you said native code is always going to be faster, “feel better” (tighter intergration with the rest of the system), etc. However a lot of native GUI frameworks are pretty messy. (Anyone who has worked with GTK will likely know the pain that it brings). The web model at least provides a nice separation between the design and the program logic. (There are other more native frameworks that do this to some extent, but I feel this is still a significant reason why the web model is used so much). I also like how the web model allows for portability and distributivity with (relative) ease. This does not mean that I feel the electron/node-webkit method of developing software is a good one, and I personally can’t stand using programs made in this way, if for no other reason than my PC is relatively old and the slowdown is noticeable. I do think native frameworks have something to learn from the web, and in an ideal world I would like to see some kind of method of building GUIs that can be served over the web or natively and function well in both instances.
I also have mixed opinions, in part because while I’m a bit skeptical of the webtech-everywhere trend, the native-GUI-toolkit side of things is a gigantic mess too, and often not even that native. There are definitely people who do write 100% native GUI applications, but that requires going all-in on one platform. A fairly strong niche are the people who develop OSX-only applications, using all the Apple APIs directly, trying to do things in line with the OSX norms and look-and-feel guidelines, etc. The downside is that when you go all-in on native OSX like this, your app only runs on OSX.
The in-between option is a cross-platform toolkit that translates to the native GUI toolkit. That ends up as a kind of halfway house, using the native widgets to get as close to a native look-and-feel as possible, but by necessity not quite using them idiomatically, because they need to be unified or abstracted over in a way that can target a bunch of platforms simultaneously. GTK, Qt, and Java’s Swing sort of fit in there, and while they work, I wouldn’t really go out of my way to sing their praises as the one true way to do GUIs.
You can even sort of see the wrapped-webkit type of app as a roundabout realization of something that was a goal of a lot of desktop-Linux people in the late ‘90s: that instead of people writing GUI apps to a specific platform’s toolkit (usually Windows), the GUI layer should be done in a library, with the platform only needing to provide something relatively low-level and common, like a framebuffer to draw the widgets in. Tk was an attempt at that that enjoyed some success for a time.
the one unreservedly good thing i can say about web-on-the-desktop is that it’s the lazy way to develop applications. “lazy” means that you have done what you wanted to do with the least amount of fighting with various toolkits, languages, etc that make your task harder. the fact that you pay the price in cpu and ram consumption and potentially in responsiveness is a huge drawback, but that just means that no one has made a good enough “lazy” alternative yet.
But HTML5 is native in Internet Explorer 9, 10, 11 and 12 on Windows! (Only on Windows!)
http://youtu.be/9mXe9nRiPHI
How do you want your HTML5?
Partly, yes, it’s due to the performance. Even on a fast computer, if you open enough such apps, the entire computer will end up slowing down. However, I also find the tendency of the web tech model to try applying itself to everything a tad… superfluous and useless.
Originally, HTML was designed to add links to a markup language, then CSS was added to stylize it, and finally JS was added as a scripting language for the web. Since then, it has all been evolved into being used for nearly everything, from text editors to web browsers. It wasn’t designed for this; it was designed as a way to display text, and link to other text. Nowadays, HTML and CSS seem to have become a UI specification that is difficult for both computers and humans alike to process, and JS has become a haphazardly thrown together mess
⁰with the mindset that it should encompass everything.Personally, I can understand the urge to try to get something to do everything
¹, but that of course means that there comes an increase in complexity. Complexity is usually never good, you end up with things like this or this happening. Complexity also causes speed issues, which is what the majority people seem to dislike about such efforts. However, mainly I find the complexity of a web browser sitting atop the complexity of an operating system sitting atop the complexity of a backwards-compatible CPU to be appalling to think about². We might as well create an operating system that is mostly a web browser to help reduce complexity.It is the very attempt to use “web tech on the desktop model” that I dislike about it, not merely side effects such as the performance hit. In the past, we’ve made SMTP become a file-sharing mechanism and made unicode become a clip-art provider. Maybe this time, we should spend more time figuring out what we want the web to do, instead of haphazardly forcing it to do everything
³.⁰Admittedly, JS is trying to become better.¹I admit, it is quite fun to make something do something it wasn’t explicitly designed to do.²Being the hypocrite that I am, though, this doesn’t preclude me from actually using a web browser on OS X on an Intel i5 chip to share these thoughts with you. This is mainly because it seems to work well enough for now, and it looks nice.³Whoops, too late, it’s already used for everything.:(I wonder how people would react if programmers started writing self-modifying PDFs, thus transforming Adobe Reader into an application platform.
It worked for the web, so why not just attach JavaScript to PDFs.
:(I don’t know whether I’m happy or depressed this exists. I’m a bit happy because it’s a great place to point people who are a little too eager to do everything in a web browser, however the existence of such a project makes me think that maybe we should all move over to TempleOS.