101–110 of 112 posts
Earlier quoted context omitted.
maybe not, but electron requires some refactoring and learning a few new things by itself, it's also not a straight swap from a web app.
Win7, for better or worse, is still a relevant OS. What engine does its native webview use? Some old IE thing that is garbage in comparison to Chromium?
I am a fan of VIM but I find the whole discussion around Electron rather amusing - almost as if we need to justify our need for regular punishment by reinventing the wheel. It is fun to do things from scratch but it will not get you there fast. Yes, Electron apps are a bloat considering that each one of them brings its entire runtime like games, and you know that most games will exceed several Gs of disc space and me…
UWP apps can be written in HTML/JS. You can run local js / html in a webview in most platforms. React Native is pretty much just this. It's a shame there isn't a cross-platform framework using webviews and native frameworks.
This article implies the differences matter. Nope, sorry, the conveniences of VSCode are worth the "cost" for me. I have 32 gigs of RAM and the time I spend opening files doesn't register compared to the time I spend writing or reading code. I do wonder whether the measurements take the base overhead of each editor into account. Do the numbers represent the use per file or the total for the file plus the entire app?
> worth the "cost" for me. I have 32 gigs of RAM I can see this conversation in the future: "I have 128TB of RAM" "Why the hell do you need so much RAM, what's the point?" "I use electron apps." "Oh..."
[...]
"Why the hell do you need so much RAM, what's the point?"
"It's a Chrome box running web-native apps."
"Oh..."
WASM is defining our future. It might not be chrome boxes, it could be Safari boxes, or Edge boxes, or Brave boxes, or... Why use MacOS/Windows/Linux when everything is available to a sufficiently powerful JS interpreter with built-in sandboxing?
Earlier quoted context omitted.
I think the most frustrating thing here is it doesn't need to be this bad. Rendering HTML and running a JS VM might seem like a long way around to get a desktop interface, but you're reading this in just that context, alongside a couple of dozen tabs, many running webapps with complexities to rival Microsoft Word '97. You're not using 4GB per tab; you probably aren't even getting up to 4GB with all your tabs. Electro…
> Electron can do better Think of electron as a single tab open in a browser instance. If you open 12 tabs in chrome, it doesn't use 12x the RAM, because most of the initial RAM is used maintaining the browser instance , not the rendered tab. most electron apps don't have "tabs" but if they did they wouldn't multiply the memory usage either
Earlier quoted context omitted.
UWP apps can be written in HTML/JS. You can run local js / html in a webview in most platforms. React Native is pretty much just this. It's a shame there isn't a cross-platform framework using webviews and native frameworks.
Electron provides some nice integrations with the base OS that you can access with JS. However, such abstraction, although maybe not as complete as the one in Electron, can be easily written so that the native browser can be used as the main renderer. As long as the application works across all browsers, it will remain small and pretty much portable. You still need to update the browser wrapper through which is more…
Yes, you'd need to update and build apps for each native platform separately, but the end result would be worth it. We're talking about maybe halving ram usage simply by writing a little more native code to package up our javascript
This article implies the differences matter. Nope, sorry, the conveniences of VSCode are worth the "cost" for me. I have 32 gigs of RAM and the time I spend opening files doesn't register compared to the time I spend writing or reading code. I do wonder whether the measurements take the base overhead of each editor into account. Do the numbers represent the use per file or the total for the file plus the entire app?
The people behind Atom and VSCode are putting this out for free.. How about we each use whatever we want and stop complaining about having too much choice.
Earlier quoted context omitted.
> Electron can do better Think of electron as a single tab open in a browser instance. If you open 12 tabs in chrome, it doesn't use 12x the RAM, because most of the initial RAM is used maintaining the browser instance , not the rendered tab. most electron apps don't have "tabs" but if they did they wouldn't multiply the memory usage either
While I understand your shared-memory argument, Electron in this example, is using twice what Firefox is using for 3 webapps and another dozen tabs.
I'm not saying it does or doesn't, and I'm not defending it, I just think we need to be a little more fair with our comparisons
I did a comparison a while back (though I'd hardly call it scientific). I built a basic "hello world" Electron app, which consumed 69MB of RAM on Windows 10. When I opened the html file of that app in Chrome it took 82MB.
I really wanted to like Atom, but it always felt unfinished and clunky with crashes/freezing/locking becoming more of a regular occurrence with the more plugins or extensions you use. It's one saving grace is that I thought Sublime was a bit bulky/memory hungry, but Atom gave me a new found appreciation for Sublime which I'm now back in love with!
My collegue tried VS Code, but it screwed a commit due to not updating the file after a checkout, so he went back to Sublime.
Earlier quoted context omitted.
Atom claims to have code folding, but (despite having syntax highlighting) the code folding function works naively off of indents, not syntax, so you're out of luck working on any codebase with less-than-meticulous indentation, zero-indent comments, etc. Unfortunately, IIRC, Sublime does exactly the same thing. It's really frustrating. I haven't been able to find a good all-purpose Mac programmer's editor with workin…
Atom is currently in the process of working on implementing a new source folding parser [0] based on something called 'tree-sitter' [1]. If you are interested in following that development, feel free to watch that PR. [0] https://github.com/atom/atom/pull/16299 [1] https://github.com/tree-sitter/tree-sitter