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

The State of Atom's Performance

blog.atom.io

Post reply on HN
Print view View original

231–240 of 293 posts

Re: The State of Atom's Performance

#231

Post by ExactoKnight »

oneweekwonder wrote: post #209
brennebeck wrote: post #186

Earlier quoted context omitted.

Which is a very substantial population.

Lowest common denominator. We put it on every kids desktop in the 1990's. We put it on every kids phone in the 2000's. We are shocked when they reinvent the wheel with in the 2010's. Now in 2020 they are trying to tell me all the kinks are worked out with frameworks and to get your javascript to work in a browsers you first need to compile/transpile it. Skip the whole multi-platform idea and focus on electron with al…

Indeed. The mess we're in is one of crap upon crap.

I wanted to use a CSS framework the other day, and I all but had to rip the project apart manually just to get the files without them stuffing a heavy build tool like Gulp down my throat.

All of this... just to get some !@#$ing CSS.

Re: The State of Atom's Performance

#232

Post by ExactoKnight »

shakna wrote: post #130
vog wrote: post #123

Earlier quoted context omitted.

Do you care to elaborate? That doesn't make any sense to me, as the advice given above is exactly what you should do in a company, if I understood it correctly. (Higher risk on a simple project, because that's the only opportunity to learn new stuff, as in the worst case you can start over. Lower risk for a complex project, because there's already enough risk in the project itself.)

Processing transactions at a bank is "boring". It's simple, apart from scale, and the spec is usually insanely well documented. But if you reach for that new language that hasn't been battle-tested yet, you're probably screwing the bank over.

I'm in banking at a startup level and I'd have to disagree with this.

There is tremendous fear in the industry right now over being seen as outdated or dinosaur, especially with all the blockchain hype.

You can make simple technology choices like moving from a stateful SQL database over to a blockchain ledger like Sequence, and in doing so, you will attract a way higher calibre level of talent. You will also have way more people interested in working for you, and the skillsets and knowledge learned within the company for doing it will future proof you far better than going the boring old route.

Re: The State of Atom's Performance

#233

Post by keymone »

tigershark wrote: post #214
keymone wrote: post #211

Earlier quoted context omitted.

i don't even.. for people making these claims there's just no way to convey how horrific js development was until quite recently (it still is far worse than most popular languages out there tbh) other than inventing a time machine and sending you there, but then it's a kind of punishment i wouldn't want upon my worst enemy. browser fragmentation rings any bells? were you actually doing js dev back then?

What is the connection between browser fragmentation and coffescript syntax? Coffescript was born to have a lighter JavaScript-like syntax, not to remove browsers fragmentation.

the connection is between fragmentation and claim that ecmascript and js 1.8 were released and everything magically became great in december 2009 as was implied by the grandparent.

Re: The State of Atom's Performance

#234

Post by qubex »

subsection1h wrote: post #160
rubyn00bie wrote: post #156

Earlier quoted context omitted.

My general dislike for Atom wasn't anything to do with the editor itself, I've just always been sore they used CoffeeScript which is a language I personally _loathe_. I was excited to have a sublime replacement I could hack on, but that killed it for me. It was that it was so inaccessible and for such a asinine reason (a language purely for syntactical sugar). JavaScript is the lingua franca of the internet for fucks…

> CoffeeScript which is a language I personally _loathe_. [...] it was so inaccessible You know JavaScript, yet CoffeeScript is inaccessible? WTF. I had never written a line of Lisp in my life before using Emacs, but that didn't stop me from writing hundreds of lines of Emacs Lisp during the first weekend that I used Emacs. What's up with the unwillingness (or inability?) that many web developers seem to have for usi…

> that didn’t stop me from writing hundreds of lines of Emacs Lisp

Oh, you wrote an A.I.-enabled missile launch control system in your first weekend too? ;)

Re: The State of Atom's Performance

#235

Post by dangamble »

QasimK wrote: post #222
eagsalazar2 wrote: post #217

Earlier quoted context omitted.

Dude you are so off base. Atom for daily driving is not slow at all and on OSX feels perfectly native and well integrated with the OS. So your entire point is dependent on assumptions that the UX sucks and the performance is worse than many native apps, both of which in this case are completely wrong. Please consider going back to the parent post and contrasting that with your way out of bounds response that ends wit…

The last time I tried atom a year ago (for the second time) it was so slow I had to write this to warn my future self: https://github.com/QasimK/my-setup/blob/master/atom.md (Nov 19 2016). This was on a modern powerful desktop.

I'd imagine after a year of updates it would be the perfect time to give it another spin. Not saying it's any better but to negate something entirely because of a bad experience over a year ago is a little over the top IMO.

Re: The State of Atom's Performance

#236

Post by shakna »

ExactoKnight wrote: post #232
shakna wrote: post #130

Earlier quoted context omitted.

Processing transactions at a bank is "boring". It's simple, apart from scale, and the spec is usually insanely well documented. But if you reach for that new language that hasn't been battle-tested yet, you're probably screwing the bank over.

I'm in banking at a startup level and I'd have to disagree with this. There is tremendous fear in the industry right now over being seen as outdated or dinosaur, especially with all the blockchain hype. You can make simple technology choices like moving from a stateful SQL database over to a blockchain ledger like Sequence, and in doing so, you will attract a way higher calibre level of talent. You will also have way…

I'm one of the contractors that rolled out instant transactions at CBA.

The feature is absolutely hype, and a selling point, or was til the RBA required everyone else to follow suit.

But it doesn't change the fact that fundamental things that cannot be allowed to fail should not be built on twigs.

CBA worked with Wells-Fargo to build a blockchain ledger, running atop skuchain, which itself Go and JS. That's a lot of hype and new in one place.

But it wasn't in a simple systems-critical place, it was done for one contract, with one customer first, with regulatory approval for the experiment, to see if blockchain technology was feasible. It was also not proof that this can scale, that needs more experimentation.

Lots of simple things are fundamental, and you do not mess with those.

Simple/complex isn't enough to say whether you should experiment, because experiments should be as far from impacting your bottomline as possible.

R&D should stay in R&D, until it is proven stable. You can't afford to build a house of cards.

Re: The State of Atom's Performance

#239

Post by romanovcode »

ExactoKnight wrote: post #227

Honestly, coming from a Ruby dev environment of all things, I have been really impressed Visual Studio lately. Never thought I'd see the day.

It's Visual Studio Code tho, Visual Studio is still alive and kicking as a huge behemoth IDE that works under Windows only.
Post reply on HN