701–710 of 1001 posts
Earlier quoted context omitted.
That's really interesting! I have an up-to-date atom install that i've been adding plugins to for about a year now (up to like 50 or so), and has been running for at least 12 hours (windows 10), and currently has 7 ~500 line files open. Adding up all the processes' (7 of them) private memory gets me 194mb.
I installed the 64-bit version, you might be using 32-bit.
It might just be a difference of platforms.
Earlier quoted context omitted.
Well, to the extent that these costs degrade the user experience, I'm not sure they really are externalizing them. Presumably they pay this cost in the form of decreased user satisfaction. It's just that this is a cost they are willing to pay. There may be an interesting economic lesson here: it really is not that easy to externalize costs. It surely can be done (air pollution), but it requires some special circumsta…
Yep, and when the government doesn't properly tax those harm-to-public-good things like air pollution to balance the incentives and make it cheaper to do "the right thing" and pollute less, companies (which are made of real people and are not just unthinking machines) will do whatever they can to maximize profits. This is why it's so important to e.g. Increase the price of water to reflect the true cost in the Centra…
Earlier quoted context omitted.
Yes. You just described modern computing.
Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.
For macOS desktop applications are written with Objective C, which is C with fast message-passing, and doesn't trade much to speed. Swift is modern alternative, but it doesn't trade anything for speed either.
For Linux applications are traditionally written with C and Gtk or with C++ and Qt. Those options are both very performant.
For Windows main language for a long time was C++ and it remains supported language. There's movement to .NET, so Windows is an outlier here. But .NET is generally very performant language, it makes some tradeoffs for safety, but it has enough features to stay fast and its implementation is specifically tuned for desktop applications.
The only terrible platform with slow language is Android and it's well known for its lags.
There's very little desktop software written with Java and Python and usually those are specialized applications, when users don't really care about experience, but rather care about functionality.
So JavaScript invasion here is unexpected and not wanted. I won't use any JavaScript desktop application, if I have choice. I don't like this technology. JavaScript and V8 made for browser with advanced sandbox capabilities. That's fine. But for desktop it's just not needed. And there's no other advantages. UI is terrible and does not conform to any standards. Performance is not good. Memory consumption is abysmal. Energy consumption is abysmal as well.
If I'm about to buy application for macOS, I'm always carefully inspecting its bundle and trying to determine which technologies were used. Unless it's pure Objective C/Swift, I'm usually won't buy it. I hope, more users would do it.
Earlier quoted context omitted.
IE10/11 let you pin any website to the taskbar with its own icon, complete with notification overlays: https://msdn.microsoft.com/en-us/library/gg491738(v=vs.85).a...
Same for Chrome: http://www.geekpen.com/wp-content/uploads/2016/12/Chrome-Mor... Probably Firefox also has this.
Here's more info, with images of how it looks like: https://support.mozilla.org/t5/Learn-the-Basics-get-started/...
Earlier quoted context omitted.
We use Java because Python proved to be too slow.
Yeah and some use C because Java is too slow. The point is, there is nothing new here, the history of computing is repeating itself. It's just now we have better toys, a bigger market and the stakes are higher.
Although I think that (for 99% of possible use cases) if you believe that Java is too slow, you're just doing it wrong.
Earlier quoted context omitted.
We use Java because Python proved to be too slow.
Java also has JavaFX, which comes with an embedded Webkit browser. I can create my UI with React, or any other HTML/CSS/JS library, and make it interact with code written in Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc. very easily. I think this provides all the benefits of Electron, but is even more flexible and powerful.
Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x…
> Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". This comment is completely wrong. You know what Slack was before it was an Electron app? It was a Cocoa app. Sure, it wrapped a WebView, but given Slack's nature that's not a surprise. Regardless, the Cocoa Slac…
Earlier quoted context omitted.
Java also has JavaFX, which comes with an embedded Webkit browser. I can create my UI with React, or any other HTML/CSS/JS library, and make it interact with code written in Java, Scala, Groovy, Clojure, Kotlin, Ceylon, Frege, etc. very easily. I think this provides all the benefits of Electron, but is even more flexible and powerful.
Yet, this is not as popular as electron. Ask yourself why.
Earlier quoted context omitted.
This issue is so furiously divisive, and I feel like it brings out the worst in HN. I'm from a web dev background. Some of the comments here make me feel like I should be ashamed of that fact. I can see both sides of this argument (every time it comes up) As a consumer of apps, I want the leanest, most minimalist, fastest thing going. I want native apps on my devices (If you think slack is a hog on the desktop you sh…
Your non-technical users are capable of noticing that a certain application makes their computer slow or drains their battery or doesn't support a certain feature of their platform. It may take them longer to notice, and they won't know why, but that won't stop them from switching if a better alternative comes along. Delivering high-quality web apps generally requires knowing JavaScript and CSS. Delivering high-quali…
Earlier quoted context omitted.
That's nonsense . Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-platform development . That is, it's cheaper to build a single cross-platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose th…
Electron is like almost any other cross-platform VM, including Java (which is living under most of the "native" apps on the world's most popular platform), .NET, and so forth. It doesn't share resources between instances but then you also don't get dependency hell (wrong version of Java for application X, etc.) Subjectively, I'd say that Electron's performance overheads are not bad compared to, say, Smalltalk in the…