I am not badmouthing JavaScript or bandwagoning on the "Electron is the devil. Long live native apps!" But I've been wondering more and more, especially through my own experienced biases at work: how much of the, "we chose x because y and z" is retroactive justification for the simple truth: "I wanted to use the technologies that make me enjoy my job."
I often have to fight with myself to pick the right tool for the job, not the tool that makes my job the most fun to do.
Is it really bandwagonning to be annoyed that so many bits of software, which many people run simultaneously, use a tool where a Hello World is over 100MB in memory?
At least the Electrino idea is more reasonable. Using a framework already loaded into memory by the OS and sharing it would go a long way toward reducing the bloat...though not toward the horrible battery problems it introduces. Seriously, people are still brushing aside issues with something where a blinking cursor caused CPUs to crank up to the max...
On android I think both Chrome and Firefox supports installing a website as an icon on the home screen.
It might already hide the address bar when opened in this mode. I personally expect that it's just a matter of time before this becomes an install mode for desktop apps as well.
Firstly, I agree with you! I like the philosophy that "Production should be as boring as possible."
That being said, using tech that makes you enjoy your job will help you be more productive and potentially attract enthusiastic developers.
I feel there's probably a balance (as in all things) between boring production/exciting development - but I don't feel I hear that discussed often enough.
Which is why TensorFlow etc. have a boring & hard C++ core, and a lovely & easy Python layer that transmits the computational graph to the core.
Electron is similar: a boring & hard Chromium C++ core, and a lovely & easy JS layer.
What pains me is that there is no reason to include libraries we don't use.
Each Electron embeds a large amount of memory-consuming libraries that do things that are way out of scope for most apps: screen recording, sound editing, GPU graphics libraries…
Python is a boring technology. It's a 10+ years old language, like ~20 years behind cutting edge programming language research and implementation. Also, as for the programming style it encourages, it strongly nudges you against any "cool" way of programming: even the most basic kinds of functional programming is something you end up avoiding in P and "dumbing down" your code to more procedural idioms, and OOP over-over-over-architecting is something you just don't do because of the performance penalty and the lack of serious refactoring tools for large codebases. The side effect is that all code is more readable and understandble to anyone, including self-taught devs. JS itself is a boring language at its core too, except that it evolves faster than anything else. And the ecosystem is anything but boring (and also anything but sane...).
Cooler and more advanced (in terms of language features) languages are Julia (it has real macros, advanced type inference etc.) and even R (yeah, it's a mess, but as a language it's more advanced and "cooler" than Python). On the "web backend" scene Ruby is a way more "not boring" language, but the ML and science communities avoided it almost completely (I have a few theories as to why...).
And then there's the "truly cool" and "0% boring" languages like: Scala, Rust, Elixir, Clojure, Haskell, Elm, Crystal, Pony etc.
But don't get me wrong, I like Python for being what it is: an incredibly boring scripting language, that encourages a "stone age level" style of dumbed-down programming. With slightly awkward but stable libs (on which people agree almost unanimously of which to use). Because with Python I can focus on the product instead.
Python was shown to the world in 1991, and hit 1.0 in 1994, making it roughly 27 years old, incidentally. You did say 10+, but most people don't realize just how lengthy a pedegree Python has.
I wrote C++17, just to hint how one should aim to write proper code as of 2018. At very least, one should be making use of C++11 and whatever the compiler already supports from C++14.
Of course, it will take time to move from "C compiled with C++ compiler" to something better, specially in the embedded domain where Assembly and C still rule.
The tools are there, and an incremental update into safer code is always better than throwing everything away, and rewrite everything, including the already fixed bugs.
The only thing that C++ cannot fight against is the C mentality. That is only possible in languages that lack copy-paste compatibility with C.
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.)
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.
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.
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.
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.
I would phrase the problem slightly differently: not "I want to use the technologies that make me enjoy my job," but "I want to use the technologies that I already know."
Electron is popular because it lets you write desktop apps in JavaScript, and there are a lot of developers out there who know JavaScript. By going with Electron, those developers can build desktop apps without having to learn anything new. They can extend their existing skills into a new arena, without having to learn any new ones. Developers are always asked to turn products around as fast as they possibly can (and, um, also people are lazy), so this is a very powerful appeal.
This "I don't have to learn anything new" factor is literally the only thing Electron has going for it. Using any other alternative will result in applications that perform better, fit into their host environments more naturally, and generally work better than an Electron app will. But there are a lot of JavaScript developers out there, and any other alternative would require all those folks to learn a whole bunch of new stuff to get started -- new languages (C/C++, C#, Java, Python, etc.), new toolkits (UWP/Win32/Cocoa/whatever, Qt, WxWidgets, etc.), new programming paradigms, etc. etc. etc. Whereas with Electron they can pick it up and be productive in a couple of hours, which is a hugely appealing prospect.
Tools that let people leverage what they already know will always do better than those that require a whole bunch of learning up-front to use. Electron is just the latest example.
The thing is, are those alternative toolkits better?
Done right, they're faster, for sure. But when you use Electron you're leveraging thousands of man-years of Google developer effort to build a web browser that works consistently and well across different platforms. Although the web platform gets a bad rep for cross-browser compatibility problems and general weirdness, a huge amount of that goes away when you target a single runtime. Suddenly you can use every half-baked Chromium API and prefixed CSS feature without worrying about how it's going to break in IE 11.
In that situation, you suddenly realise just how much power the web platform give you. You can style any element, any way you want. You have you have a complete, out-of-the-box object model for your whole UI, plus developer tools to help you debug it. You have advanced typography control. You can drop a canvas element in and get an immediate-mode 2D or 3D graphics API. You can layout stuff in flexbox or grid, or just as a plain old document (which most toolkits would delegate to an embedded web browser anyway).
There are better languages that JS, that's true. But whether there are truly better cross-platform app toolkits than the web is, in my opinion, rather more unclear.
That Google felt the need to invest millions of dollars into making a document delivery platform into something resembling an app platform is not really relevant here. Sure, it is robust. But the whole point of the thread is engineers are notoriously bad at asking what the customer _needs_ from a product vs what the engineer finds fun to write. You want to have fun as an engineer? Work on a side project.
The larger the dependency, the more it should have to do to justify itself. "It's fun to write in" is not a sufficient justification for a 70mb dependency. "I need a cross platform app" is better.
As an engineer, you're responsible for the transitive dependency graph that gets delivered to customer machines. If you want to take on gigantic dependencies because they are the current lovechild of ascendant Medium bloggers, be my guest. I prefer to go off of more than fun and social proof when making engineering decisions, however.
> The thing is, are those alternative toolkits better?
IME, yes. Most of those toolkits also have thousands of hours invested to work well across platforms, not consistently but natively, or at least a close facsimile of native.
> In that situation, you suddenly realise just how much power the web platform give you. You can style any element, any way you want. You have you have a complete, out-of-the-box object model for your whole UI, plus developer tools to help you debug it. You have advanced typography control. You can drop a canvas element in and get an immediate-mode 2D or 3D graphics API. You can layout stuff in flexbox or grid, or just as a plain old document (which most toolkits would delegate to an embedded web browser anyway).
So nothing that hasn't been true of desktop apps for decades then? If you want power then nothing beats being able to overide the paint method of a widget, you have complete and total control.
If you're interested in seeing how easy desktop apps are I built the canonical todo list in Gtk (https://gitlab.com/flukus/gtk-todo/blob/master/main.c), the goal is a demo that's a bit more complex than hello world. This is in a language not known for it's terseness, uses one of the nastiest parts of the framework (GtkTreeView) yet it still comes in at less than 100 lines of fairly straight forward and simple code.
> You can style any element, any way you want. You have you have a complete, out-of-the-box object model for your whole UI, plus developer tools to help you
And it only costs you 400MB of RAM and 20% CPU utilization!
Yeah, this is is actually one of the reasons I used Electron for a screen-recording project...because most browsers didn’t implement the experimental screen recording APIs yet but Chrome already had it.
And note that outside of C, C++, .NET, and java, making a desktop means using a library built in another language with documentation in another language. (C has GTK and C++ has QT.)
I started building an app in Rust against GTK with a Rust shim, but I only got so far before I had to start reading through GTK docs which meant understanding the C-derived documentation, on top of the Rust shim.
If the goal is to learn GTK, Rust, and C, then it's not a big deal. If the goal is to build something that you need, you end up scratching it and going back to something you know already.
(In my case? Java which has the underrated JavaFX 2.0. And I'm sure I'll look elsewhere some other time - I'd really like to learn Rust better, but I think I'll do something other than a desktop app, or at least wait for better documentation or more time.)
That said, Lazarus looks really cool as well and may be the thing I always hoped for...
I experienced this too. Strong Python developer wants to build a GUI in a few days to help others perform a task. Uses PyQt, runs into segfaults (in Python?!) and has to drop down a level, understanding the implementation and nuances of QT.
Forget Lazarus. There is no (finished) Cocoa for Mac. Development is not on Github. Syntax has no common style. Documentation is uneven. The whole ecosystem feels (well, is) dated.
Of course, Lazarus/FPC is still quite nice. But to really shine and be a valid alternative, it would need a large infusion of money and manpower.
This is true but in practice the Carbon backend will work fine and if that isn't good enough you can use the Qt backend which uses Cocoa (but then you'd have to bundle Qt with your app which increases its distribution size a bit). To preempt a "then why not just use Qt" reaction, this isn't the same as using Qt since you can use the Win32 and Gtk backends in the other platforms.
Cocoa is of course under heavy development, but keep in mind that there are only a handful of Lazarus developers that even have access to a Mac and they actually had to write a special dialect for the compiler (Objective Pascal) to be able to handle Cocoa objects directly without the need of an intermediate (like Qt that needs libqt4pas that exposes the Qt API as a C interface that is then linked dynamically with FPC through a C-to-Pascal binding).
> Development is not on Github.
This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.
> Syntax has no common style.
What do you mean? The IDE even provides formatting tools.
> Documentation is uneven.
Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).
> The whole ecosystem feels (well, is) dated.
Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.
> But to really shine and be a valid alternative, it would need a large infusion of money and manpower.
Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.
The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.
No mudslinging intended, I'm thankful for the community and Lazarus is a nice tool indeed.
>> Development is not on Github.
>This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.
(Most important is, what the fpc/lazarus developers want). -- Many people likely don't want to bother/install the 'ugly and stupid' SVN nowadays and Lazarus/FPC looses all those potential contributors at once. I don't like monocultures either but GitHub (maybe Gitlab) is the pragmatic choice and imho helps to have/find contributors.
>> Syntax has no common style.
>What do you mean? The IDE even provides formatting tools.
Comparing Lazarus, FPC, MSEgui and some component sets, I had the impression that there are many (small) differences, e.g. 'integer', 'Integer', 'INTEGER', where begin..ends are placed and many more 'non-conventions'...
Tool is good, but (imho) the issue is that there is no BDFL which would gently nudge towards a commonly agreed style guide. Likely not helpful is also that Pascal is not case-sensitive and that there are multiple modes (OBJFPC, DELPHI, FPC..)?
>> Documentation is uneven.
>Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).
I don't want to complain. Core FPC docu is high-quality, written in Tex. But I found it difficult to get an overview: which are the relevant pdf's/links, where is the source for it, how would I contribute or report an error? For a quick shallow fix, it seems too complicated: Tex, xml; inline help, huge separate svn docu project; FPDoc generator. Contrast this to many environments where you can quickly fix a typo or phrase in the browser and the project gets a PR.
>> The whole ecosystem feels (well, is) dated.
>Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.
Difficult to be specific. If you e.g. look at go (golang.org/), rust (www.rust-lang.org), julia (julialang.org) and/or haskell (haskell.org) and some of their tool-choices, it feels for me very different than FPC/Lazarus. This is not mudling, it's just a realistic look at the situation. Dated also doesn't mean that it wouldn't work any more.
It is imho a problem if e.g. there is newpascal.com site with a more modern feel instead of the old trusted projects moving to a more modern approach. Don't know details but this choice raises the complexity for a user as it is not clear, what to choose.
>> But to really shine and be a valid alternative, it would need a large infusion of money and manpower.
>Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.
Do you have examples for such companies / situations? As the code is mostly GPL-2 (components LGPL2 with link-exception or MPL), it seems to be difficult for a company to take over. And personally I wish that there were steerings towards a more uniform and easier-to-enter 'FPC/Lazarus-world'.
>The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.
Yes I hope things improve with new blood. For the 'Pascal universe' as a whole, lack of developers means 'not attractive enough'. As I really like the language I would blame the choice/proliferation of 'dated stuff' to be a contributing factor.
Last but not least, Lazarus worked well last November when I tried it out again. I was positively surprised. Nevertheless one has to have realistic hopes...
> And note that outside of C, C++, .NET, and java, making a desktop means using a library built in another language with documentation in another language. (C has GTK and C++ has QT.)
Not necessarily. D has dlangui and dwt, tcl (and also python?) has tk. Vala is also available for gtk. I think VB also lets you write GUIs although not sure I never used it. Objective-c has cocoa (gnustep outside of macosx).
> This "I don't have to learn anything new" factor is literally the only thing Electron has going for it.
Not completely, don't underestimate how hard it is to write a cross platform UI that runs on Windows, OSX and Linux.
Starting from a web framework not only gives you portability but also a common UI language(that may diverge a bit from native app conventions but that's a tradeoff you need to weigh).
I say this as a die-hard C++/native dev. I've done wxWidgets, QT and a bunch of others and it's never a trivial thing to do.
The other thing to keep in mind is that a similarly script-extensible Qt application carries the weight of Qt shared libraries, plus scripted wrapper shims. This can easily run 25-40 MB in Python-Qt systems, at which point 70 MB for Electron looks much less crazy.
(also a C++/Qt dev, jealously eyeing love preview, hot-reloading, and other niceties).
I don't disagree with your analysis, but I disagree that it's a simple rephrase. They are two separate issues:
1. Pros/cons of using tools we already know
2. Pros/cons of using tools we enjoy using
I am awful at Docker because I started using it yesterday. But upon using it, I'm suddenly so attracted to it and am thinking about what fun personal projects I can apply it to. It's a beautiful technology.
I am very strong in JavaScript but love avoiding it like the plague unless it is the appropriate technology.
Edit: okay I'm skeptical of a part of your analysis. Please show me a detailed example of building a desktop app that runs on Mac/Windows/Linux, looks reasonable, and takes the same or less time from a competent developer. I am genuinely starving for an alternative to Electron that doesn't come with a significantly heavier dev/support cost.
> Tools that let people leverage what they already know will always do better than those that require a whole bunch of learning up-front to use. Electron is just the latest example.
Yes.
In "Code Complete", Steve McConnell argues that although a programmer can learn a language syntax in a couple weeks, mastering the language, tools and libraries that make up a platform can take a couple of years.
In other words, asking developers to build and maintain non-trivial products in a language that they don't already know is an even bigger burden than you might think, to the point that it's probably an unreasonable request.
Familiarity, knowledge transfer is a big drive for technology adoption. The bad bit is when the decision maker leaves the team and the rest are unfamiliar with the tech. I think this applies to Electron pretty well as web developers can now contribute.
The "it would look good on my CV". I'm thinking about Kubernetes where it doesn't make sense to use most of the time but everybody wants to be doing it because it's hot.
I wish engineers and computer scientists would pay attention to that gut reaction more often.
Programming really at some level is as much about translating human ideas into physical computations as anything. In this regard, it is a fundamentally psychological process, as much about the programmer as the computer. There's a sort of psychological-cognitive -> math -> physics process, and I often feel as if the emphasis is on the second two steps, and not so much on the first two.
There's good reasons for this, but it's resulted in a sort of blind spot that often comes out as people just preferring languages like python or javascript or whatever, and not wanting to acknowledge that those fuzzy, poorly understood preference processes are driving development as much as the choice of algorithm or hardware constraints.
I think it's poor ergonomics, really, and effects things as much as memory management models, etc.
We're at a stage, though, where languages like Nim, etc. offer some promise of ergonomics and performance, and I hope people will pay attention to it carefully, so we don't end up in the same situation as the one Atom exemplifies. I like Atom, and don't have any particular attachment to Nim, but do think there's something we shouldn't be ignoring anymore. Often when a language is difficult to intuit, the reaction is to shame the programmer, to characterize them as not smart enough to understand the language. Sometimes there's some truth to that, but sometimes I think it reflects deficits in the language, whose sole purpose, really, is to translate human thoughts into computational events.
"There's good reasons for this, but it's resulted in a sort of blind spot that often comes out as people just preferring languages like python or javascript or whatever, and not wanting to acknowledge that those fuzzy, poorly understood preference processes are driving development as much as the choice of algorithm or hardware constraints."
One language that openly acknowledges it is designed first and foremost with psychological factors and ergonomics in mind is Ruby:
"For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy."
Free software is obliged to use technologies that make contributors enjoy their job, especially for a project like Atom where you can't expect an individual or small group to do all of it.
I do go back to Atom often because of a few details that I like better over VS Code, but it's a lost cause, and reading this proves it.
Who cares about start-up time? I only open the thing once/day. Same thing for large files: it's a edge case. Memory usage? Sure, but as developers we probably have GB and GB sitting there, if the thing worked it wouldn't be a big deal for the most important tool in your arsenal.
What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
What they'd need is a huge architectural overview, and the fact that they're showing off how much they're optimizing proves that they'll never be as performant (or even close) as they'd need to.
Also weird that they blame extensibility. Emacs does it, Firefox does it, Chrome does it, and most importantly VS Code does it. I'm sure it's not easy, but it's done by other projects.
Too bad, because the UI is very nice, package management is very good, as well as not having to edit JSON files for settings (which sure I can do, but I see no added value and I'm lazy).
Memory usage? Sure, but as developers we probably have GB and GB sitting there
GB and GB which I had hoped to use for running an entirely other operating system, and all of its apps, in a VM, not run a goddamned text editor.
And that’s what annoys me about the “so what?”s. Start up time? Even just an update that requires a restart will make me wonder “I’m in the middle of something, how badly do I want this?” Resource hungry? See above, I have those resources for other stuff, not your piggish version of Notepad. A lot of these things can be excused for an OS, a database, crypto currency worker, but NOT AN EDITOR.
But even if I were more tolerant, as you point out the general use case has been abysmal in my experience. If this kind of thing is what you want, I fail to see why one wouldn’t just use VS Code.
You know, I'm not saying those things aren't important.
I'm just saying that the general use case sucks enough that I'd think you'd want to worry about that _first_, then perhaps think about startup time (maybe).
Sorry, wasn’t really arguing with you personally. And I agree, I am way more tolerant than I should be because “shiny”. Last I used VS proper (and it has been a while), it was a pig, but kinda worth it for the developer experience. But as you point out, all that piggishness and the experience is less than great? Umm, someone needs to do a rewrite.
VSCode is really bizzare, in a good way. All the configuration is done through JSON files. It's a good editor as well as an IDE. There's no "projects" or "solutions" or wizards. I almost never run into issues with it.
It doesn't feel like a microsoft product at all. Nothing like Visual Studio.
I disagree. It has smart auto-completion, refactoring, it informs me of errors in my code before I run or compile it, integrated version control, auto-compilation, and many other features.
I use vscode as a Golang IDE. It's pretty comprehensive with the extension that integrates the Go toolchain.
I tried Gogland EAP for a while, and liked it a bit better, but now it's a paid product, I'm happy with vscode (which has 95% of the features I use and 0% of the price).
Atom can also configured via JSON files. They create their config file as CoffeeScript Object Notation (CSON) by default, but nothing is stopping you from changing it to ~/.atom/config.json
VS Code is basically everything Atom tries to be and/or should have been. To me it’s the spiritual successor of the original TextMate: works great out of the box, but can also be customized to fit your needs.
VSCode won me over grudginly. It's faster, lighter, and just as extensible. I was conditioned at an early age to throw holy water at anything Microsoft, and still, I like VSCode better than Atom.
Man you are so pissed and condescending. Do they make you use Atom at your work or are you really that angry that other people use an editor you don't like?
> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
They specifically address those issues in the post:
> Text Rendering Rewrite - Atom renders text... we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible... The result is that when typing, typical DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage.
> Removing remaining synchronous IO: - Atom still uses synchronous IO (which blocks the UI thread) in some places... Much of the synchronous IO has been eliminated, but there are several Git-related code paths that we still have not updated, and which kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths and convert them all to use asynchronous IO.
Turns out that for the important things in an editor, React has a hard time optimizing as much. I'm a huge proponent of React, but the right tool for the right job is an important principle for the pragmatic.
I think since then, they've circled around to a much more restrictive and faster virtual dom. React could be made quite a bit faster (as proven by Inferno) without changing the API and moving to a more monomorphic, but verbose API could probably offer a big performance boost.
I've wondered in the past if the best solution wouldn't actually be to render the editor part as a canvas element and remove the normal DOM from the picture completely. VS Code did something similar with their console a few versions ago.
EDIT: Looks like they've given some thought to canvas already (for the next go around). With webassembly, they could even offload to a nice C++ or rust library running and repainting a canvas element in another thread.
This is the exact reason I've commented (and been shouted down for) saying that React is a fad. It's trying to replace fundamental core system with a layer, and do it better. It will never work, it can't.
Eventually everyone will figure out that building "apps" with DOM manipulation will never be as performant as lower level coding (ie, not a script layer), and they will move on. And the DOM will return to light apps and general purpose websites with basic interactivity.
How can it go any other way? Btw, the only reason I am posting this is bit out of frustration that stating something so obvious makes some people really angry. I suspect its because they have invested so much in React, and don't want to consider it a temporary hack until webassembly or shadow dom or some other tech makes it completely obsolete.
I tried out Atom, it's miserably slow. And I recently downloaded VScode, just to give it a whirl, and it's impressively faster. But I use Komodo, and that is based on Scintilla and Firefox, and it works just fine.
React’s declarative Api is much easier to read and update than working with dom calls directly. And React itself doesn’t even have to target the dom, as with react native which generates native system UI
That doesn't make sense...the browser always does the rendering of the dom. Not react.
React speed when keeping your states and data in sync is that React makes all changes to the virtual dom then it makes it to the browser dom.
It not different then the concept of batching graphic changes in a 2d game. You blit batches of sprites that need to be changed around the same frame instead of making 500 draw calls you make 1.
Instead of the developer worrying about trying to gather all their dom changes dependent on user interaction and data syncing you interact directly with Reacts vDom and then react takes care of making the dom changes.
Virtual dom frameworks are a huge thing now cause UX/UI are more complex and we were fighting those issue before. Angular, Ember now, Vue, react ect cause we get speed back when making many state changes to our UI.
If a bottleneck is dom manipulation, then something that smartly batches them and reduces the number of times it's called would help. How would that not apply to Atom?
> In May, we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible. We made use of the latest DOM technologies and rendering techniques, and built a tiny React-like library called etch that allows us to structure our rendering code cleanly while still allowing for imperative DOM manipulation for maximal performance in certain code paths. The result is that when typing, typical DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage.
Because they already implemented something similar as per the blog post.
React has an implementation of a virtual Dom. They don't have to use react to do that and as discussed in the blog that is the major slow down on their UI.
> Memory usage? Sure, but as developers we probably have GB and GB sitting there, if the thing worked it wouldn't be a big deal for the most important tool in your arsenal.
Adding to the other comments about having better use for my memory than piles and piles of JavaScript bloat, how do you think GC performance is affected by the amount of memory it has to manage?
All the micro lags in rendering and input handling are affecting your performance consciously and subconsciously.
You know, the exact thing you complain about:
> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
> Who cares about start-up time? I only open the thing once/day.
I care.
I live in three editors: Xcode for iOS/Mac/Swift on server development, VS Code for Rust, Go and Python, and Sublime for a thing that starts up fast, opens new windows fast and can deal with huge amounts of text. I wouldn't mind reducing that number to two, but it doesn't seem likely to happen anytime soon.
We as developers might have plenty of RAM to waste, but our users usually don't. If it runs well on our machine but not in the users', what good is it?
Even if it runs well on the users' machines, how many resource-heavy applications can they run concurrently? Will they have to close one to open another?
Unfortunately the attitude is pervasive and electron is also used for applications more in line with what your mom would be using. I think many would be shocked that a good chunk of their audience has less than 8GB: http://store.steampowered.com/hwsurvey
It's also a mistake to assume developers have plenty of RAM to waste. A couple of years ago I was using a potato for coding on the way to work that only had 2GB, which made atom a no go.
Also, what happened to the idea of dog-fooding? It's not dog-fooding if your on a machine much faster and with more memory than your users. I think the problem with windows 10 is that all the devs were dog-fooding on top of the line surface pros.
Reading updates like these from Atom reminds me a lot of some struggles I've seen with my teams in terms of how to breakdown problems you need to solve. I try to emphasize the idea of challenging the base assumption that current problems are stemming from to determine whether we've created our own issues or are truly facing problems we need to solve for our business.
People tend to ignore the base cause/assumption and hone in only on the problems that stem from those base causes/assumptions. Sometimes that's unavoidable, but often it's at the very least a good thought experiment to back up even further along the decision chain and challenge the original ideas instead. "Think outside the problems" or something I guess. It's really just making sure that you're being as methodical/objective as possible.
Atom seems to have been built with a set of initial goals/assumptions that triggered a massive chain reaction of problems to solve. Rather than challenging those original goals/assumptions, a lot of engineering talent and time is being invested in essentially cleaning up these problems that were self-imposed.
When Atom makes serious changes to APIs, they find all published packages using those APIs and notify the authors that things are changing. Often the notification arrives as a pull request implementing the needed changes, along with an apology and an explanation of why the changes are necessary. It's impressive.
I'm guessing the OP is hinting about moving off Electron?
Performance is the reason I switched from Atom to Sublime Text in the first place. I was annoyed that it took seconds to start, and even then it felt sluggish. At some point I might give it another go but for now Sublime Text suites my needs perfectly, even if it has a smaller package ecosystem than Atom.
It must be tough to see how quickly the community turns on you when something better (in some ways) comes around.
Atom clearly offered something that struck a chord when it initially appeared. I remember having an idea, and implementing it as a plugin, all within a lazy Sunday afternoon. This allowed the ecosystem to flourish, and new ideas being extremely easy to at least prototype.
It also allowed unprecedented[0] access to almost everything.
The latter turned out to be somewhat of a curse, unfortunately. Because the wide-ranging access allowed extension authors, and their users, to shoot themselves in the foot: It often lead to performance degradation, instability, murky UIs etc. Such troubles would usually be attributed to Atom itself. This was the groundwork for the narrative to almost instantly flip when VSCode appeared.
VSCode itself took the lessons from Atom, which must make it even more painful to now see it glorified vis-a-vis Atom: Extensions have to work through tightly defined protocols, and are never run on the main threat. This works well to avoid performance issues and to keep the UI from disintegrating. But it is also a severe limitation on the freedom to experiment, which is why that extension I once tried my hand on could not possibly be build in VSCode (it renders block comments written in Markdown as HTML right in the source code, including images, diagrams, links etc.)
[0]: Yeah, I'm sure there's some other editor that did it before. But somehow Atom got it right with Javascript as the language, and maybe the UI and documentation steering people to actually try it.
Microsoft has a ton of experience with misbehaving third party developers. Distrust of code written by others is by now a second nature to them. I am sure that they would have gotten this right even without Atom falling into the "open internals" trap first.
Which, to be fair is understandable on Microsoft's part. Blindly trusting others to create in your ecosystem while novel, is a _very_ scary place to be if you are the one who has to answer to the shortcomings of the platform
>It must be tough to see how quickly the community turns on you when something better (in some ways) comes around.
I agree, and i want to like atom. I love the motivation and i love how they have moved the "friendlier than VIM but not quite an IDE" market forward, because that's exactly the sort of editor I want.
but ultimately i'm trying to do a job, and that job is a lot easier when i'm not waiting for a text editor to catch up to my keystrokes. Even if it is some plugin's fault and not actually Atom's fault that the editor is slow, I don't have time to troubleshoot that when other editors don't let plugins screw up the editor.
Even I (as someone who has a profound hatred for MS and their business practices) have to admit that VSCode is vastly superior to Atom, which is why I have used the former instead of the latter for a long time.
Weird question, I know, because I use VS Code as well, every day for about 6 months and love it, but, I’ve never used these other popular editors. What makes VS Code so much better? I chose it because it had some integration with DCC apps I use use, and I like the GUI and general simplicity. What other reasons do people have for loving it?
I was a long term user of Brackets (since 0.14!) before I switched to VS Code sometime in 2016 because it just worked so well with Typescript. I tried to switch to Atom several times but could never get over the slugginess of it compared to the other two editors.
There were other issues too, the way they handed project folders, intellisense for Scala, but the slugginess was the main issue. I often had to debug large JSON files and while Brackets and VS Code would open them almost immediately, Atom would take several tens of seconds.
Also, personal issue was that I didn't like the default keybindings they had for macOS. I don't remember what they are anymore but there were lots of what I thought should've been obvious defaults that weren't.
Relative to Atom, which I left for VS Code: Code is faster and lighter, just as extensible. Better git integration and code analysis, even for Javascript (I finally understand what devs from other languages were talking about!). My workflow is just smoother for everything except Clojure and system admin (but I use emacs for those, atom isn't any better there).
VS Code was my first not-Sublime, not-vim editor, but...I really, really missed my four-up display with four editors in a square configuration. I went to Atom because of that and because of VS Code's inability to keep a pane open even with no tabs (just because nothing's in it doesn't mean I want it closed).
I've been learning emacs over the last 6 month or so. How is the "hackability" of atom compared to emacs? I threw away spacemacs, started over, built all my config, am starting to build plugins etc. While the learning curve was steep, the flexibility of emacs is quite amazing and I've only just scratched the surface of the extensibility. It makes me very intrigued to hear about how other people are using editors like Atom.
I tried out Atom and found its "hackability" sorely lacking compared to Emacs. Which made me sad, because it's the only new-gen editor to really claim to be "hackable".
Specifically, what I'm looking for in an editor is the ability to introspect most/all of the editor's internals from the editor itself (including documentation, debugging, live modification of the editor, etc.). In Emacs, all of that is just a few keystrokes away. Atom is somewhat introspectable in that I can pop open a Chrome dev console and poke around at the DOM and the JS files, but it isn't at all as straightforward as in Emacs (e.g. given some keystroke or some function in Emacs, it's extremely trivial to jump to the source code and start modifying/debugging it). Given that these activities aren't clearly documented in Atom documentation, I can only assume that they aren't priorities for Atom and that, in fact, Atom isn't designed to be "hackable" in the sense that Emacs is "hackable".
Which is really disappointing, because a truly "hackable" editor a la Emacs, built on a web stack like Electron, would make me giddy with excitement.
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 native libs.
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.
>Specifically, what I'm looking for in an editor is the ability to introspect most/all of the editor's internals from the editor itself (including documentation, debugging, live modification of the editor, etc.).
Although it is ugly, and the documentation is poor, and web site looks like it's from the 90's, and the project lead is a bit eccentric, you may want to consider the Leo editor:
It's written in Python, and pretty much gives you access to most/all its internals. Unfortunately, the state of the documentation is pretty poor which is why I never had the time to spend mastering it. But I've followed it enough, and it really is a very powerful editor. I think only Emacs surpasses it in self-scriptability. A lot of non-programmers have used it to do pretty interesting things (helps that Python is "easier" for them than Lisp).
I would also like further discussion on this. I am full-time emacs. I hear from other colleagues that they will split time between editors. "vim for writing and VSCode for refactoring".
Ya I do periodically spend time in intellij when I work with scala, just because of the discovery and refactoring capabilities. Particularly very large/involved refactoring is helped by the tools. I did a core redesign to support an entirely new use case in a product I'm working on now. I tried to do it by hand and burnt a day, threw away everything, opened intellij, and applied a couple refactoring. In 40 minutes I had the tests passing for what was a very broad and wide refactor.
If anything the thing that is a killer feature that I always try to get out of emacs but ends up being half baked is the code completion/code aware tools (like the example given of refactoring). With emacs and yasnippet I can emit a ton of code but if I ever have to do a big surgery and have some level of assurance it's right as I go along is nice and I end up falling back into Eclipse/Visual Studio for those sorts of things. I have rarely gotten Emacs to have good code completion with most large software projects, and I end up using tools like opengrok to do the initial search because it just indexes better before diving in with emacs.
Because emacs in most implementations is not project aware the same way an IDE is (like the ways eclipse preprocesses the project and holds a coherent data model in memory while you edit) it just doesn't have the tools available to even build off of. It was only post-LLVM that tools for that kind of formatting and editing are expected to be coming from the compiler's AST itself (things such as https://langserver.org/ is pretty exciting). I think Go has some of the best source code at command line tools, but they are leveraging that there is a 'one true way' of go tools to work that is easy enough to deal with so a simple command can do just enough work to do what needs to be done as opposed to a C/C++ application that is a #define soup with custom build infrastructure that emacs has no way of getting a coherent model out of to decide whether it can refactor things or not.
I keep trying to make emacs work for it, but it turns into a lot of custom tooling that I really don't have time to build for the kinds of applications I end up having to work with. Emacs is still superior for actually reading and writing large bodies of code, just it is awful on operating on the code at a syntax-aware level and doing the same quality of IDE-grade checks to make it a mechanical thing as opposed to a brain-driven thing.
This isn’t really relevant to Atom, but... Emacs is working on this, on several fronts. In many ways, this isn’t (yet) an improvement, because what we have now are a bunch of partial implementations that mostly get different parts ‘right’. On the other hand, progress.
TBH, one of the big stumbling blocks is that a lot of the most adept Emacs hackers simply don’t do much of the sort of ‘IDE-grade’ stuff, so in a real sense, they don’t understand what they (and Emacs) are missing. (Fair cop: I’m largely in this boat myself.)
For example, Emacs has had dynamic adaptive customizable electric hippie completion for longer than there has been a publicly released Java language, BUT many (is it still most? My experience is old) Emacs hackers just never did the sort of refactoring that made people tolerate Eclipse — and that was over a decade ago.
One more thing: if you are interested in lisp, can stand to see C code, and are interested in LSP, look at Emacs-devel.
There are nice possibilities for this project, it could be abstracted out to work with FreeBSD and stuff. Grunt/gulp/etc. watch features may be able to utilize it in library form.
I'm a full time VIM user, but I'm happy and glad anytime I see VSCode/Atom/etc win. I see it as a great editor for the sake of having one to recommend. Cross-platform, free, active plugin ecosystems.
It’s a cross platform file monitoring daemon with a json (and bser) querying API, with support for opaque cursors so you can poll for changes since the last time you checked.
Every time I type `git commit`. Every time I visualise files with ranger (terminal based file browser). Every time I typed an email, back when I was using Mutt —which I might again.
For such quick jobs, launching the editor should be instantaneous. And I don't want to use another editor for them, I like the key bindings of my main editor.
This is true with something like Vi but with a separate GUI app, wouldn't the most common case be setting EDITOR={atom,code,etc.} and it simply opening a new window in the already-running app?
(Or, for that matter, don't most people using something IDE-like use the built-in UI to make a commit?)
No doubt but e.g. VSCode’s sub-second performance shows that’s not a huge stretch while sticking with Electron and it has a subset of the challenges for startup performance
I don't think that's a good justification for slow startup time and general sluggishness. Despite having 30+ plugins and 800 color schemes installed vim starts up in just a few milliseconds on my work rig. I code all day every day.
I use vim, which launches almost immediately. I launch a new instance for every file I open, each in a new screen. It seems to work fine. Yet I wouldn't be able to do that under atom... (ignoring the issue of it doesn't work with tty).
I don't either. It's pretty fast as it is. Even if it took 10 seconds I don't think I'd mind too much as I close atom maybe once every few days, mostly by mistake (stupid cmd+q)
If you're on the insider channel, the update cycle is daily. Microsoft's Code group is really knocking it out of the park with attention and responsiveness.
I would like to be the first to welcome you to the world where your personal preferences and experiences aren't universal. I don't use my computer exclusively for editing text, and therefore my text editor is not open all the time.
> I don't use my computer exclusively for editing text, and therefore my text editor is not open all the time.
Ok, well if I was developing a programmer's text editor I'd consider you a marginal user and design for the use case of the editor staying open 24/7. Startup time seems pretty low on the priority list.
Design for whatever you want to design for. Plenty of us are programmers who program all day every day and still don't agree with you. What you choose to prioritize is different from what you understand, though. So at least now you should "get" the gripes.
Well if the Atom developers are reading this I want to encourage them not to waste energy optimizing startup time due to Hacker News complainers who are using the product for a use case better suited to Notepad.
> Note also that these numbers are for users running Nuclide, which adds substantial functionality to Atom and increases its memory usage. Typical Atom users should see lower memory consumption.
It was a really odd graph to show actually, there's no context and it makes me suspicious. How are we supposed to know if all the memory improvements have come from atom or nuclide?
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.
Just want to point out that SDL implementation would be native as in 'not running on top of VM', but not native as in 'good citizen of host OS'. It would use non-standard widgets, likely would have problems with keyboard shortcuts, clipboard handling, drag & drop integration and window resizing. Depends how much time devs spend re-implementing stuff that's already supported by OS.
I don't think that would be too much trouble, you can find fully custom widget toolkits with excellent performance and seamless OS integration (check blender or UE4 for example)
We are working with electron, and make a simple solution for starting app, if already,
Just create new entry point, in this entry, dont do anything except check the makeSingleInstance function
If an instance already alive => just quit :D
It's make our app seem very fast
const app = require('electron').app;
const shouldQuit = app.makeSingleInstance((argv, workingDirectory) => { });
if(shouldQuit){
app.quit()
}else{
app.on('ready', ()=>{
require('./startUp')
})
}
I love JavaScript and the IDEA of Atom ( I recently tried it again last week ), but a 1/2 second-per-keystroke lag ( on a kinda beefy PC IMHO see: https://pcpartpicker.com/user/jeffallen6767/saved/#view=KT9R...
) is a deal breaker for me. If I can't type 60 words a minute in your IDE, I'm just not able to use it sorry.
It's funny reading this article that details how many core issues still exist, yet all the while both Atom and VSCode have spent significant engineering time and resources building superfluous features like shared real-time code editing and (Atom's) github integration. They are marketed as "text editors" and the feature work should be prioritized as such.
I gave VS Code a try recently for Python development. VSC almost won me over. However, in the end I found important features / packages that are available in Atom weren't available in VSC, so I moved back. For instance, autocomplete ("intellisense") failed to recognize functions that were written in files open in the editor!
As far as I know intellisense, it’s based on their model of your AST and import paths in the current file, not which other files are open. Open files are more of a “word complete” feature. i.e. text, non-semantical. like C-N in vim.
(Not to say you’re wrong to expect it—just for context.)
>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written in JavaScript as opposed to C or C++, which is important for Atom’s extensibility, but makes it more challenging to ensure that the app starts quickly.
Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it down, but Atom's refusal to admit their performance issues for so long are also to blame
From the atom FAQ in answer to the question "Atom feels slow or is consuming too much CPU or memory"
"Atom isn’t designed to be a tiny native-code editor. If the ultimate in speed is what you’re after, Atom probably isn’t what you’re looking for at least for now … and possibly not ever depending on what you’re expecting."
I tried Atom as an alternative to Eclipse, about 3 months back, as I consider Eclipse to be pretty bloated and slow, but Atom made Eclipse look like a speed demon. I tried running with --safe, removing plugins, but nothing seemed to help, it was still painfully slow. Perhaps it's my machine or some other local issue, but I run Eclipse with lots of plugins and it runs great, in comparison.
After reading the above in the FAQ and many many posts about how Atom was running slow and the responses those issues received, it seemed to me like they actually do admit there are performance problems but have the attitude of "That's just how it works, if you don't like it use something else"
I don't know why you would characterize it that way when they very clearly describe what they've done to improve this and their plans to improve it further. I wish every company would "refuse to admit" the same way!
Because their direct statement, at the end of the day, just unilaterally shifts blame to Electron for something that is partly their fault. So while they do have improvements in 2017, and it's great to see their steps for the future, they still have a fundamental issue in not admitting that they are slower than their direct competitors, who also are burdened by the same issues Atom is saying are the reason for their performance.
The problem I believe is not with the startup time. If you load bunch of scripts in your emacs, it also gets sluggish at start. The way Emacs people solved this problem was to use a server client architecture and run Emacs as a daemon.
I think the real problem Electron apps face is that rendering everything on the DOM is really expensive. I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution.
Emacs was critisized, heck even banned from uni labs back in the day, because it used too much RAM. Now the time has come for us to mock Electron based editors :).
> I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution.
I believe that was actually due to a quirk in the way CSS animations worked in Chrome. It was fixed by changing to setInterval which is what was used before. GIF animations were proposed, but AFAIK never actually used.
I just started writing a GAE Python app, and I needed a good, free editor for my Mac. I chose vscode, and it's been superb. Hitting shift+cmd+p for any command, the python tooling, and the default keyboard bindings are great.
I wouldn't recommend switching away from Visual Studio to vscode, for .NET work, but for a new language/project, it's a great choice.
So now I started editing an asciidoc file in vscode on windows, since it's a productive text editor, but the back, forward, previous, next, kill, killall key bindings are all Windows-like and not Emacs/Unix like. Fortunately, it's was easy to add the six bindings in their fancy settings cascade text editor.
Apparently they use a lot of windows apis and dlls -- except that it works on linux and there's no c/++ to generate a dll, and I forget where I read that. (Somewhere on HN.)
It is not "much faster" at all, both are horribly slow. (I can see how one would be convinced VSCode is fast if they're comparing it to Visual Studio which has absolutely abysmal performance). Though I could be convinced with newer benchmarks. All I could find was this experiment from a year ago that shows Atom and VS Code opening within a fraction of a second of each other, but Sublime and TextEdit beating both of them by an order of magnitude:
I dev on a Mac, I'm anti-Microsoft through and through, and I thought the same. But seriously, their Mac version of Visual Studio (which I use) is now mature and I think in parts thanks to Microsoft taking steps to support bash, the ruby support so far has been great if you add the appropriate add ons. https://www.visualstudio.com/vs/visual-studio-mac/
Seriously as a ruby hipster I know all the love our community has in hating enterprise IDE's, then I grew up and realized they give you out of the box amazing functionality (like dynamic runtime variable value inspection and automatic app-wide class name refactoring) that makes manual refactors look like amateur hour.
These features are so powerful that I implore any Ruby dev using Atom or Sublime to at least give RubyMine a look if they don't want to give VisualStudio a look. You will be a stronger and faster programmer having them in your toolkit. Especially, and I repeat ESPECIALLY, for refactors of class names.
Interestingly enough, the tool he uses there (Sysprof) I rewrote last year to modernize it and we use it to both keep GNOME Builder¹ fast, and profile applications within Builder.
jQuery also provided a ton of usability improvements which many developers learned how to use. In many cases those are now obsolete[1] but there's a lot of habits and, more importantly, library code which uses jQuery. Migrating away from that would require replacing all of that code as well before you can see any savings in network transfer or memory usage.
1. For example, how many projects could basically use this for a significant fraction of their jQuery calls:
Meh, tried it a while ago. VSCode is better, but still a bloated piece of software. Glorified text editors that use megabytes of memory when running...
You never have used any of those java based IDE, have you?. A clean install of Eclipse takes about 400 mb before even creating a project. Android Studio is a nightmare of epic proportions. VSCode provides the same level of autocomplete and features at a fraction of memory without lagging at every keystroke.
I want to like Atom so badly. I really buy into the features it offers over my beloved Sublime Text (3). I want the connectivity to the greater community, the ease of styling, and the ease of extension. I want everything Atom claims to offer!
In my last year of switching from Sublime Text 2/3, I have pretty much just gained one thing: cooler language syntax styles. I havent actually taken advantage of all of the ideas behind atom - I guess, when it comes to the grind, Im not interested in them enough to actually take advantage. When it comes to how I use my code editor, I seemed to have focused only on my career's needs, and not the joy of customizing, extending, and contributing back (to the code editor's community, that is).
What is important to me is productivity. In my year of using Atom, I lost a lot of productivity. First I lost lots of productivity configuring Atom to be in a similar state to how I use Sublime Text 3. That wasnt hard, Atom is just different, so there was some learning that distracted me when I wanted to focus on work. Thats cool, I can accept that for any "next big new thing." Then I lost a lot of productivity due to things related to package-management systems, configuration issues, and I had to wipe and reinstall a few times as it was easier to get back to work than to figure out what tidbit of an advanced feature I was misunderstanding. Then I lost a lot more productivity after package updates broke other packages (mostly language syntax stuff, but enough to be a big distraction when coding). It felt like getting into ES6 JS for the first time after only using jQuery - except in Atom's case, it was a tool getting in the way of me working.
I also really loathe all of the git-integration features, though they sounded great at first. I am constantly having to git reset and git checkout <filename> etc because I diddnt realize I had the @#$%ing sidebar in focus instead of the text area for the zillionth time. I diddnt realize when I was trying to select and delete text with a keystroke, that I deleted files from the sidebar view yet again. So on and so forth - its given me a major fear of using the software as misclicks and such lead to pain that I have to undo via my terminal. Dont get me started on how bad its auto indent or copy paste intelligence is... and again, zero of these issues with ST3.
Atom might be "free," in theory, but it cost me many hundreds (possibly low 4-figure number) of dollars worth of billable hours in my 2017 fiscal year.
Ive probably lost a cumulative total of 4-5 billable hours to Sublime Text in my whole life, and that was usually to Sublime's wonky updating patterns.
Id really like to like Atom, but Im "thiiiiiiiiiiiiiis close" to deleting it off my work machines and going back to Sublime Text 3. It has taught me that productivity it way more important to me than modern web-enabled features.
Here is to hoping 2018 is a better year for the Atom IDE, as my relationship with it has about 1-more incident worth of tolerance left.
> First I lost lots of productivity configuring Atom to be in a similar state to how I use Sublime Text 3.
> Ive probably lost a cumulative total of 4-5 billable hours to Sublime Text in my whole life
It sounds like you haven't spent any time customizing Sublime? If so, then why did you need to spend so much time customizing Atom? They have a very similar out-of-the-box user experience (except for speed of course).
Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas?
I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip.
I love that it's an entirely open source system and that it is written in the accessible Javascript language so that anyone can contribute. I love that I feel like I can change any aspect of the editor fully, without limitations imposed by some vendor.
Atom, like any editor, is not for everybody. I don't care much for Sublime but it certainly has its strengths- I don't pounce on HN posts about Sublime spouting negativity because it's not my preferred editor.
Please, fellow engineers, before you post something negative think about a project you've worked on that you were most passionate about and cared most about and then remember that projects like Atom do require passionate developers and those developers likely deserve a bit more than snark or non-constructive negativity.
Thank you Atom contributors! I think the idea and ongoing evolution of Atom is a special project and I hope to one day make some contribution of my own, in some form, to the core or plugins!
> Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas?
Why would you build a text editor on top of a web browser engine? Who would think that is a good idea?. Of course it is not going to be performant, it is being used for something it was not designed for. On top of that, cross-platform apps built using the one stack are horrible. They never feel exactly like native apps.
If this was 20 years ago, atom would be built with java using swing. It would be just as slow and just as un-native. Java apps on the desktop are ridiculed for a reason. The only difference is that now they are using 'trendy' things.
I think blind Freddy could tell you that, yes you can build a text editor on top of a web browser, but performance, and usability will suck. That is why everyone is so cynical, because it is so obvious.
I, and many others, don't care about "native". I've used Java applications and I will keep using them when they're useful.
And regarding Java application speed, IntelliJ is pretty much comparable with the "native" Visual Studio.
About the looks, I'm using right now Vim (GTK), Skype (I don't even know what toolkit it's using, but I'm pretty sure it's not native), Eclipse (SWT - sort of native), Pidgin (GTK), Firefox (XUL? I'm not 100% sure after 57), Chrome (Skia?), etc.
Users don't really care as long as the applications are useful and developed properly. I've used many crap and butt-ugly "native" apps...
I don't even use Atom, but this vitriol annoys me.
Look, I was being a bit snarky. I think all apps that are not native, or don't follow system convention, create an impedance in that they don't always follow system conventions, or something about them doesn't work exactly as it would in a native app. This can cause confusion in users. The level of impedance depends on the user skill, experience and expectations. I know traditionally, Mac users have cared a lot about consistency and following the HIG, whereas Linux users are more likely to pick the application they prefer and not care whether it is GTK or QT.
If you are someone who jumps between Windows, Linux and macOS using the same app then consistency in how the app works is a big gain for you, and then the impedance comes from the system you are using.
I didn't mean to imply that Java apps are bad, far from it. Many java apps are good, they just stick out like the proverbial, and performance historically was not as good as native apps. There was a time when the go to torrent application was java based and Netbeans and Eclipse were the IDEs of choice. But they made trade-offs, and two of the key ones are performance and consistent UX with the operating system. For many applications / users, this is a fine trade off to make. But Atom made a similar trade off and then the developers have spent all this time and effort trying to improve performance, and that is what I was trying to be snarky at, that its obvious why performance will always lag.
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 with "everyone is so cynical, because it is so obvious" in light of the fact that all the outcomes you assume are just not right.
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.
It proves that there was a need not met by other options. Do you resent Atom developers for giving away free tool that you consider subpar? Or are you angry at its userbase for choosing Atom over your preferred option?
I don't use Atom but I'm glad it exists. It improves on state-of-art in some areas and that benefits everyone.
I meant in terms of performance and nativeness. I was thinking of like Netbeans and Eclipse, which were both great IDEs yet sucked with performance (i.e. start up time, memory consumption) and fitting in with system idioms.
> Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas?
My experience is that Engineers are just snarky and cynical. Especially about text editors. Frankly, HN is a lot more constructive than Slashdot or Reddit was back in the day.
Personally, Atom is not my editor of choice (team Sublime!), but I really hope Atom succeeds. I do love it's hackability, and I would much rather have my plugins in JS, but alas, it's just not fast enough for me, yet.
However I held onto Textmate until 2010 and Sublime wore me down, so I'm a laggard as well.
So no negativity from me, because I just want a great editor that I can control and hack on. But I'll be real, I don't see it happening for a little bit.
If sublime were to support JS plugins, I fear Atom might be in trouble at that point, TBH.
This may sound like heresy but I seriously encourage checking out today's version of Visual Studio.
I dev on Ruby and I am a hardcore Sublime user, which is about as far away from Microsoft-friendly as you can get, and I have been really impressed by it.
Their app store is advanced, and crucially they allow Visual Studio to be setup with key bindings that match Sublime's, meaning switching over is really easy with almost little to no need to learn new macros. IDE's like Visual Studio can allow you to do code and class refactorings that make Sublime look like a joke.
Yeah, but the Visual Studio installer still sucks, there's no portable version that I know of, and extending it is a major undertaking. Plus, it's Windows only (the version for Mac is mostly a different app).
It is a great app, I agree, but it also comes with its own legacy.
I'm using the Mac version. Started with it today. It felt like getting all the benefits of RubyMine without the learning curve of needing to learn its non-Sublime macros, thanks to Visual Studio's option to automatically map key commands to mimic Vim, Sublime or Atom.
Not sure how difficult extending it is, but on day one in their app store I found all the important ruby bindings I needed to replicate what I value most in my Sublime set up: i.e. ruby linting and rubocop.
The switch was so painless I hardly noticed I wasn't using Sublime -- except in the moments of joy when I found the other powerful things it can do.
This stands in big contrast to RubyMine -- an IDE I absolutely also adore for its power -- but one that I found challenging to pick up due to its custom macros.
If you're talking about VS Code, I tried it a few months ago, and while it was faster than Atom, it also aggressively took over file associations, which is pretty irritating, TBH.
I'll have to look into the plugin API, though. I'd have to convert a lot of custom plugins, but that could be a fun weekend distraction.
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 sake... I'll stop ranting about that.
BUT NOW.. for anyone else like me-- it looks like, from my quick glance, there's not much CoffeeScript left in the repo. So maybe it's time to give it a chance again.
> 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 using more than one or two programming languages?
Why would I learn something which doesn't offer me any value? CoffeeScript is literally syntactical sugar, which I believe, adds levels of indirection to the code and makes it more difficult long-term to support, read, and develop. Not only that, but JavaScript's evolution has made nearly every reason to use it moot.
Also FWIW-- I've done vastly more native and server-side programming over the last... oh, seven years than "web." So... I don't think this is something with "web developers."
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?
Actually started webdev in 2004 php3 and basic js. Back then the joke was "nobody know how to code js, everybody just copied this one piece of code and mutated it from there".
It sadness me to think such behavior is more entrenched in todays development environment with sites like stack-overflow.
Don't get me wrong I'm grateful that sites like SO exist. I'm also grateful that when I had to learn the ropes or solve "hard problems", I could not turn to my browser. Like I do today; every fsck'ing time; because it is easier and I'm lazy.
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.
> magically became great in 2009 as was implied by the grandparent.
I implied nothing, I asked you a question. Might have been a bit open ended but you made a claim that did not reflect with my reality. So I did a reality check.
If there was a "magic" moment I will give chrome released late 2008 and firebug 1.4 released early 2009 the attribution for a turning point in webdev.
X was horrible ten years ago -> but X' was actually released 10 years ago, what was horrible about X'?
sorry, there is no way for me to interpret that other than implying that my statement was false.
there were multiple magic moments, but js didn't stop being horrible on daily basis for another couple years. having chrome debugger or firebug didn't save you from having to support internet explorer, did it?
Honestly, the strongest text editors are those that integrate with an IDE that also syncs with your runtime.
The kind of debugging and refactorings you can do in that kind of set up are mindblowing, and it took me years of doing it the old vim/sublime/atom way before realizing this.
I tend to see the cynicism/ridicule only at first. As comments accumulate it balances out. Overall it is not cynical. I would say it has improved over the years actually!
Perhaps there's lots of cynics hunched over their keyboard hitting refresh on HN so they can jump in. Who knows?
> Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas?
The moderators have almost certainly played a part. Selectively permitting snark from the in-group is easy in the short run, but eventually incurs a cost to the community.
I think the moderators do an excellent job on HN. The signal to noise ratio is pretty high here and while there is snark, there's far less than in most other forums.
One stark difference between HN, Product Hunt, and other maker forums is that HN is a very critical audience. It's even been specifically called out as such by Pieter Levels in his new book, Make.
Snark is against the guidelines, and I can tell you that the moderators find it dreadfully boring, whomever the source. We could use your help if you come across highly-ranked snark to please downvote, flag, or email hn@ycombinator.com. We don't see everything on the site, but we do read all of those emails.
This is a wonderful subject, memes and group think, I would say everyone feels like they are part of an minority/snowflake community in some of their views. Memes just makes it easier to get that feeling.
So it is not possible to have these discussions without the out-group interpreting your remarks as snarkiness. Handling that is hard, FUD is one way to handle it, compassion another. Social interactions are hard.
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 all the custom bells/whistle not available on all the platforms. Btw how does meltdown/spectre affect the outlook on security with all these application in their own little v8 kingdoms?
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.
The only one of those I'm not sure on is the expose one. The rest seem like they already exist in emacs.
It is probably mentioned in every editor thread, but org-mode is enough magic with an editor to mystify most developers. Syntax highlighting for multiple languages in a single file is already stretching most boundaries.
What's the point of the graphics in git-time-machine? The bubble plot seems less useful to me than a readable log. If it were useful there would probably be an equivalent findable from https://www.emacswiki.org/emacs/Magit
The question isn't "do I like these extensions?" It's "does Emacs let you build these extensions?" The Atom developers thought that providing this flexibility was important, which is at least in part why they used the technology they did.
The first question was "How would you do any of the below?" which is easier to answer when it's apparent what problem an extension is solving.
The second question was "Where is this git-time-machine equivalent?" which is easier to answer when one knows what a user is expected to accomplish by using it, specifically the graphical part.
I think the Atom developers are doing the right thing now by focusing on performance more than useless graphics. Right now I recommend vscode to other people even though I'll probably always use emacs myself.
I don't know on the actual charts, as I just don't use that sort of thing. Seeing anything git related and I think magit. Pretty much period. That is, I didn't see the chart.
You can do graphics in emacs, though. I typically just use it to show email and inline images for org-mode.
Calling it "web 1.0" seems amusingly critical. That said, taking it back to the question at hand, there doesn't seem to be a technical reason you can't do the images in the time machine thing. Most of my emails in gnus show graphically in a correct way. (Some of the more heavily formatted ones mess up, but usually not terribly so.)
For a better idea of what it can look like, enable LaTeX previewing inline in a buffer. Again, I'm usually in an org-mode buffer. And I confess I probably can't fight off a "web 1.0" argument. I have not gone for more modern UIs for some time. :( I grant it is a preference, but helm and similar UIs are much preferrable to me over what I typically see in the newer apps.
Also, it’s a portability PITA, and it can be a serious impediment to bringing new developers on-board. Emacs is looking (in the long-term, serious project sense) to replace or remove dumping and unexec if it can.
emacs can be very slow to start if you install everything and the kitchen sink. I had spacemacs installed with everything for working with elixir and it took maybe 5 or 6 seconds to start. I started over from a blank init.el and I have it much quicker but it doesn't really matter because you just run a daemon and connect to it.
> it doesn't really matter because you just run a daemon and connect to it.
I'm writing this because I think many people are unaware of this feature of Emacs and might gloss over it in your post.
As far as I'm concerned startup time is next to irrelevant in Emacs, since you can start an Emacs server once when you boot up and then just run clients that open and connect instantaneously. That is, you can then run 'emacsclient' from the command line in any terminal you want, and it will open a working Emacs instance in a few milliseconds.
On macOS, I have the following defined in ~/.bashrc:
alias emacs="/Applications/Emacs.app/Contents/MacOS/Emacs -nw"
alias e="et"
alias eb="/Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q --eval \"(load-theme 'misterioso)\""
alias et="emacsclient -t -a ''"
Explanation of the `-a ''` option per `emacsclient --help`:
-a EDITOR, --alternate-editor=EDITOR
Editor to fallback to if the server is not running
If EDITOR is the empty string, start Emacs in daemon
mode and try connecting again
So what? There’s no reason the Atom team couldn’t optimise their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it.
> There’s no reason the Atom team couldn’t optimize
their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it.
I believe that's what the Atom team is doing. They've detailed several critical paths that can and will be rewritten in C++/Rust in the linked post.
> Emacs is written in Elisp which is a dynamic language just like JavaScript
All dynamic languages are not born equal when it comes to performance. 2 implementations of the same language aren't even equal. While V8 is a fast JS engine, the DOM isn't. Emacs doesn't rely on the DOM unlike Atom or VSCode.
I often have to fight with myself to pick the right tool for the job, not the tool that makes my job the most fun to do.