Live data from Hacker News

The State of Atom's Performance

blog.atom.io

291–293 of 293 posts

Re: The State of Atom's Performance

#291

At this point, they would have saved themselves time by implementing it in C from the beginning.

Not that easy to make it work with all 3 OS.

If you don’t care about native look and feel, you just need std lib, POSIX/win32 library (threads/sockets), SDL and IMGUI. Do a handmade hero-style platform layer for the system stuff and you’re portablr.

Re: The State of Atom's Performance

#292
post #142

Earlier quoted context omitted.

Because building attractive UIs and doing graphical things is much easier on a web stack. Emacs can run in a terminal emulator, but as an editor in a development environment, that's not a use case I've ever had. I'd much rather be able to seamlessly plot some data with vega.js or slap together a quick UI for a tool, or be able to trivially inline images, animations, videos, PDFs, etc. without having to fiddle with na…

This makes me wonder what an editor would look like where you can hack at the text buffer/background data/etc in something lower level, but had that information also accessible with a web based layer for doing UI stuff. Might be best of both worlds, might just be insanely messy.

That is basically the ideal editor I have in my head. It would be messy, but in the way that Emacs is also messy, which is what makes it so great :). It significantly shortens the distance from my brain to running code.

Re: The State of Atom's Performance

#293
post #123
post #117

Earlier quoted context omitted.

That advice is good when you only report to yourself. If you report to a company and your decisions affect $$$$, directly or indirectly, then it's probably the worst advice.

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

The main gist is whatever you add to the company stack, the company is now responsible to maintain, possibly forever. My current situation is basically this times 10 since the people who did exciting tech left.

If the team and managers agree, by all means use the exciting tech, but it isn't a decision to make in isolation.

The canonical link on choosing boring technology is http://mcfunley.com/choose-boring-technology.

A relevant example is microservices which are all the rage right now. But, you have to be this tall to use them[0]. You cannot effectively just say you are going to do microservices, especially if you don't know how to do microservices.

Alternatively, consider the potential problems for your company if you had introduced React on your own in a core business element, and your company had a patent beef with Facebook, and FB hadn't switched to the MIT license.

[0]: https://martinfowler.com/bliki/MicroservicePrerequisites.htm...

Post reply on HN