Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving startup time in Atom with V8 snapshots

blog.atom.io

Post reply on HN
Print view View original

101–110 of 173 posts

Re: Improving startup time in Atom with V8 snapshots

#101

Post by penagwin »

MichaelGG wrote: post #93
merkaloid wrote: post #27

Earlier quoted context omitted.

if you want to protect your source code, don't use Javascript.

>don't distribute your programs That's what it really comes down to. From what I can see, it's mostly an emotional response. I'd be surprised if code/binary obfuscation is a net win in general. I've had to disabuse developers of this idea. One distributed binaries that weren't quite valid but ran on the CLR, though not Mono. A 10 line script was enough to remove the invalid sequences. What did the developer gain in t…

I agree with the idea that anything can be reverse engineered. However electron by default has plain text javascript code. I'd like to prevent people from editing plain text (!!!) to evade my licensing check!

Re: Improving startup time in Atom with V8 snapshots

#102

Post by penagwin »

fnord123 wrote: post #40
merkaloid wrote: post #27

Earlier quoted context omitted.

if you want to protect your source code, don't use Javascript.

I guess "source code protection" is for distributing plugins for Atom without distributing the source so the code isn't accessible. So I would call this "source code concealing". In any event, this could be done with WASM.

I actually needed this with it's framework electron. Unfortunately I haven't yet found a method of compiling coffeescript (or javascript) with WASM.

I'm just asking for concealing against my licensing code from being in a text file.

Re: Improving startup time in Atom with V8 snapshots

#103

Post by penagwin »

phn wrote: post #39
penagwin wrote: post #17

I started this issue a long time ago, and it's been frozen since: https://github.com/electron/electron/issues/3041 Maybe now we can have actual source code protection?

Is compiling to WebAssembly an option to you? Better than relying on memory snapshots.

I haven't heard of a method of compiling Coffeescript or Javascript with WebAssembly? Have I missed something?

Really I just want my licensing code to not be in a text file so people can't just load up notepad to evade it.

Re: Improving startup time in Atom with V8 snapshots

#104

Post by kiliankoe »

draw_down wrote: post #87
_arvin wrote: post #84

Great article. Avid ST3 user here, but glad to hear about the improvements. For anyone curious, I made a quick gif comparing startup times on my machine for Sublime Text 3 (Build 3129), Atom (1.16.0), Atom Beta (1.17.0-beta2, the one mentioned here), VSCode (1.11.2), and VSCode Insiders (1.12) https://media.giphy.com/media/3ohzdTHkfj5ISAAPq8/source.gif I should mention - my ST3 is heavily customized (28 plugins), whi…

They all look to be within the same ballpark; none of those startup times would be a problem for me, at least. But when I tried Atom it was noticeably less responsive, which I have very little tolerance for. I haven't tried VS Code. (I also use Sublime)

Showing a window is in the same ballpark, but being ready for input is something else. On Sublime this is basically the same instant. On VSC and Atom it takes a bit longer to actually render a cursor.

Re: Improving startup time in Atom with V8 snapshots

#105

Post by scott_s »

ruleabidinguser wrote: post #81
computerex wrote: post #61

Earlier quoted context omitted.

Not useful to serious programmers? Do you feel the same way about Vim? Just because you haven't gotten used to using something, doesn't mean it's necessarily total shit. There is a reason why people have been using emacs for decades.

I do actually, and I should reword that to "not useful for serious programming." VIM to me is best used for lightweight, quick and short editing tasks. THats how I use it. For any involved work, you're going to want a debugger, you're going to want automated build tools, you're going to want effortless compile/run cycles and so on.. You don't really want to implement all of that in VIM because your work won't be port…

I have all those. They're just not integrated into my editor. I use vim; it is my editor, but not my development environment. Unix is my development environment.

Re: Improving startup time in Atom with V8 snapshots

#106

Post by chickenfries »

coldtea wrote: post #35
chickenfries wrote: post #3

Earlier quoted context omitted.

Must every thread about VSCode and Atom start the same way? It's a trade off: performance for a cross platform JavaScript app development. If that is a tradeoff you don't have to make, don't do it. Atom and VSCode have made that tradeoff. I don't know what rehashing this can possibly accomplish.

> 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…

They could, but they chose not to. Maybe they know something about their organization that you don't. Either way, nothing is stopping anyone from writing a cross platform editor that you describe! If it's really so easy you should team up with all the people who show up to complain about electron in these threads. Until you or someone else makes an editor as good as Atom or VSCode I'll keep going to them as my first choice of text editor.

Re: Improving startup time in Atom with V8 snapshots

#107

Post by scott_s »

coldtea wrote: post #35
chickenfries wrote: post #3

Earlier quoted context omitted.

Must every thread about VSCode and Atom start the same way? It's a trade off: performance for a cross platform JavaScript app development. If that is a tradeoff you don't have to make, don't do it. Atom and VSCode have made that tradeoff. I don't know what rehashing this can possibly accomplish.

> 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 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.

Because such comments tend to be repeats, making them not interesting. They also tend to derail interesting discussion. When there's an article on an interesting detail about X, but the top comment litigates why X should even exist, the interesting part of the article never gets discussed. And when that happens on all threads that involve any aspect of X, it's boring.

Re: Improving startup time in Atom with V8 snapshots

#108

Post by pseudalopex »

nathansobo wrote: post #88
coldtea wrote: post #35

Earlier 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…

Using web technology was less about making development easier on us , because in many ways it made it harder. Web technology is about enabling extension authors to use a powerful and familiar technology to achieve their goals.

Could you give some examples of extensions that benefit from Atom being built on Electron instead of just embedding a JavaScript or Python interpreter?

Re: Improving startup time in Atom with V8 snapshots

#109

Post by porpoisemonkey »

penagwin wrote: post #101
MichaelGG wrote: post #93

Earlier quoted context omitted.

>don't distribute your programs That's what it really comes down to. From what I can see, it's mostly an emotional response. I'd be surprised if code/binary obfuscation is a net win in general. I've had to disabuse developers of this idea. One distributed binaries that weren't quite valid but ran on the CLR, though not Mono. A 10 line script was enough to remove the invalid sequences. What did the developer gain in t…

I agree with the idea that anything can be reverse engineered. However electron by default has plain text javascript code. I'd like to prevent people from editing plain text (!!!) to evade my licensing check!

For what it's worth I agree with the Electron dev's decision to close the ticket. They don't seem to have the same use case as you and are under no obligation to support it.

There's also the unstated issue of ongoing support for the feature. If they put in code obfuscation they'll be obligated to make sure that it provides adequate protections to avoid a deluge of "someone hacked my obfuscated code" type tickets. What constitutes "adequate protections" will have to be updated over time as more advanced techniques are discovered for reversing out the code.

Combined with the performance drops that were clearly outlined by the Electron devs it would seem like a code obfuscation feature could be a really big waste of time.

Re: Improving startup time in Atom with V8 snapshots

#110

Post by lispm »

itp wrote: post #11

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

Let's not forget Lisp I.

Lisp I Programmer's Manual, 1960, Page 67

  > ... that immediately after all the triplets have been
  > evaluated the state of the memory as it stands is read out
  > onto tape 8 as the new "base" image for the memory. ...
http://history.siam.org/sup/Fox_1960_LISP.pdf
Post reply on HN