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

21–30 of 173 posts

Re: Improving startup time in Atom with V8 snapshots

#21

Post by ruleabidinguser »

chickenfries wrote: post #16
ruleabidinguser wrote: post #14

Earlier quoted context omitted.

I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms. This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.

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.

Re: Improving startup time in Atom with V8 snapshots

#22

Post by brlewis »

ruleabidinguser wrote: post #14
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.

I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms. This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.

I hope you're right that this goes the way of emacs. I've been productive in emacs for 30 years, but I'm growing impatient for emacs to get a real programming language with lexical scoping like they were talking about doing with Scheme 20 years ago. Despite its lack of macros, JavaScript is arguably a better Lisp than Emacs Lisp. I've toyed with Atom a couple of times recently and am seriously thinking of switching.

Re: Improving startup time in Atom with V8 snapshots

#23

Post by ruleabidinguser »

brlewis wrote: post #22
ruleabidinguser wrote: post #14

Earlier quoted context omitted.

I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms. This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.

I hope you're right that this goes the way of emacs. I've been productive in emacs for 30 years, but I'm growing impatient for emacs to get a real programming language with lexical scoping like they were talking about doing with Scheme 20 years ago. Despite its lack of macros, JavaScript is arguably a better Lisp than Emacs Lisp. I've toyed with Atom a couple of times recently and am seriously thinking of switching.

See, I just don't understand why you would want to use emacs over an editor that does all the work for you. Thats why I avoid it, it seems like a big cost that I don't have to pay if I just use a different editor.

Re: Improving startup time in Atom with V8 snapshots

#28

Post by randomUser4 »

rcfox wrote: post #8
rattray wrote: post #6

Earlier quoted context omitted.

What kind of application are you building?

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

I recently evaluated all online EDAs that I could find. Some of them where quite slow because they used SVG for rendering. I would love to see your tool, too. Unfortunately, I couldn't find it in your profile. Do you have a link?
Post reply on HN