New world, same old problems. Fascinating to see how this parallels the way Emacs tackled this problem long ago. - https://lwn.net/Articles/673724/ - https://news.ycombinator.com/item?id=11001796
It also looks very similar to a Smalltalk image...
Improving startup time in Atom with V8 snapshots
51–60 of 173 posts
Re: Improving startup time in Atom with V8 snapshots
#52New world, same old problems. Fascinating to see how this parallels the way Emacs tackled this problem long ago. - https://lwn.net/Articles/673724/ - https://news.ycombinator.com/item?id=11001796
I don't recall overcoming long startup times in vi and vim. Did I miss something?
Re: Improving startup time in Atom with V8 snapshots
#53Earlier quoted context omitted.
> Must every thread about VSCode and Atom start the same way If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with. > It's a trade off: performance for a cross platform JavaScript app development. It's an unnecessary tradeoff. If a single developer can create ST from scratch for Windo…
If this was truly that simple, don't you think someone would have already done it? Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
IntelliJ does a good job of it without resorting to Electron.
Re: Improving startup time in Atom with V8 snapshots
#54Earlier quoted context omitted.
> In my experience all languages are essentially the same. That's the problem: you don't seem to have enough experience.
I dont seem to have much experience? Based on what? For having a different view than you? Isnt that a little naive? So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week. How much experience do you think I have? I've used plenty of languages, and I'm well aware that there ar…
>So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week.
That's because you either used the languages superficially, or use only very similar languages, probably of the Algol family (e.g. Ruby, Python, PHP, JS, etc).
You won't get very far with Haskell "over the course of a week". Or APL. Or Idris. Or Erlang. Or Lisp -- or any other language that's not a mere Algol derivative with some different bells and whistles. And even those have their idioms, of course, that one needs much more than a week to get competent with, but, it gets worse when we expand languages to not be "mainstream Algol derivatives". One would only be using languages like Smalltalk, OcamL, Scheme, Scala, Self, etc, superficially without getting into their idioms and nuance, which wont happen in a week (and can take years to really master).
Re: Improving startup time in Atom with V8 snapshots
#55Earlier quoted context omitted.
It's a benefit if your engineers already know JavaScript, obviously. Also, emacs is one of the most successful text editors so I'm not sure I get your comparison.
I don't consider emacs successful. Succesful among fanatics, maybe, but I don't consider is valuable to a serious programmer. Also, surely it's not that hard to switch languages? In my experience all languages are essentially the same.
[deleted]
Re: Improving startup time in Atom with V8 snapshots
#56I wish atom would just add preloading. I be happy to always have a hidden, sleeping window ready to pop to front on request. There must be some reason this is harder than I imagine...
You can basically do that now: just don't quit. If you start Atom and it discovers that it's already running, it tells the running process to handle the request. It even honors environment variables and flags like --dev. For example, starting Atom cold on my medium-sized project (by running `atom .` in the base dir) takes 6 seconds. If I close all windows but leave Atom running, do something else for a while, and the…
You are right, it is things like 'git commit' where I'd like it to be faster -- and that's where an invisible window feels like the right option. Start opening another one whenever I start using the last hidden one.
Re: Improving startup time in Atom with V8 snapshots
#57Earlier quoted context omitted.
> Must every thread about VSCode and Atom start the same way If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with. > It's a trade off: performance for a cross platform JavaScript app development. It's an unnecessary tradeoff. If a single developer can create ST from scratch for Windo…
If this was truly that simple, don't you think someone would have already done it? Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
Qt Creator? Although at this point its UI is a mixture of wrapped native widgets and non-native QML widgets.
Re: Improving startup time in Atom with V8 snapshots
#58Earlier quoted context omitted.
I dont seem to have much experience? Based on what? For having a different view than you? Isnt that a little naive? So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week. How much experience do you think I have? I've used plenty of languages, and I'm well aware that there ar…
> So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week. That's because you either used the languages superficially, or use only very similar languages, probably of the Algol family (e.g. Ruby, Python, PHP, JS, etc). You won't get very far with Haskell "over the course of a…
Well of course you can't include languages like Haskell in the group of interchangeable languages. Incidentally I have used Haskell (and it did take more than a week). But it doesn't matter because we're talking about moving JavaScript developers to Java, or C++, or as you say, Algol-likes.
Re: Improving startup time in Atom with V8 snapshots
#59Earlier quoted context omitted.
Electronics design software. :) Most of the time is spent doing fine collisions with shapes coming out of an R-tree to build up a connection graph. For the vast majority of designs, it's fast. For very dense, imported designs, it can get slow. (No two tools keep data in the same form, so translating leads to inefficiencies.)
That sounds less like startup inefficiency and more like the application doing actual work on startup. Have you tried caching it?
Isn't that what these V8 snapshots are?
> V8 snapshots allow Electron applications to execute some arbitrary JavaScript code and output a binary file containing a serialized heap with all the data that is left in memory after running a GC at the end of the provided script.
Re: Improving startup time in Atom with V8 snapshots
#60Earlier quoted context omitted.
> Must every thread about VSCode and Atom start the same way If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with. > It's a trade off: performance for a cross platform JavaScript app development. It's an unnecessary tradeoff. If a single developer can create ST from scratch for Windo…
If this was truly that simple, don't you think someone would have already done it? Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
>If this was truly that simple, don't you think someone would have already done it?
Someone already has done it. An one-man-shop built Sublime Text by himself.
Surely it's not having JS as an extension language as opposed to Python (the only difference between ST and what I propose) that's making it difficult.
>Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
There's a "cross platform, development-focused text editor with native UI component" that's working great.
Whether there's an open source editor like that is orthogonal, since what I'm discussing is whether is technically feasible to create such a browser -- and the existence of ST proves that it is (and that's by a single developer: with resources such as that GitHub or even better MS, have, it would be much easier).
The choice of license is just a decision after that.