[HN Gopher] Sunsetting Atom
___________________________________________________________________
Sunsetting Atom
Author : ewired
Score : 1041 points
Date : 2022-06-08 15:06 UTC (7 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| KronisLV wrote:
| What was Atom good for, when compared with something like Visual
| Studio Code?
|
| I recall reading about typing latency and it seemed to come out
| as one of the slower options: https://pavelfatin.com/typing-with-
| pleasure/
|
| I guess it would have occupied a similar place as Brackets,
| another vaguely similar project? https://brackets.io/
|
| Then again, with how popular VSC has become and with how insanely
| many extensions there are for it, using any other editor feels a
| bit... counterproductive at times?
|
| Personally, i'm using the following: - CLI: nano
| (vim works too, I just like the simplicity more) - Simple
| text editing: Notepad++ or similar (usually whatever is on the
| system on *nix) - Some scripting, but nothing too serious:
| Visual Studio Code - Development in larger and more complex
| codebases: JetBrains products (e.g. IntelliJ IDEA, WebStorm and
| so on)
| swlkr wrote:
| I loved and used atom for years, despite the performance.
|
| It was just such a nice editing experience.
|
| Also never got on the vscode train and opted for neovim instead
| (been using vim and bindings since 2012)
| foxhill wrote:
| peter_retief wrote:
| I actually used atom for a while, it was a bit bulky but not
| terrible. I had forgot that it was an option.
| wellsjohnston wrote:
| I tried "hacking" on Atom recently for a side project and found
| it was full of bugs and not performant at all. Next.
| dokem wrote:
| LOL this is why you just use vim/emacs/bash and move on with your
| life.
| jstx1 wrote:
| It's what kickstarted Electron which eventually gave us VSCode,
| Slack, and lots of HN comments about memory usage. It also had
| the sweetest default theme of any code editor. RIP.
| marricks wrote:
| Also all have the same magnitude of latency and lag. At least
| you know if one of them bugs you, they all will.
| dewey wrote:
| There's a bunch of Electron powered apps that feel really
| snappy, definitely faster and snappier than some default apps
| Apple ships on macOS these days.
|
| Examples for me would be: VSCode and Linear
| marricks wrote:
| I should have put the example I was comparing to: VIM. I
| like VIM as an editor because it's extremely fast and works
| well once you adapt to it.
|
| I'm sure VSCode and Linear are fast, nice, and fine. I just
| hated the lag/latency compared to my terminal text editor.
| redox99 wrote:
| A few Electron apps are _acceptable_. But it 's still very
| noticeable how less responsive they are compared to Win32
| programs.
| faizshah wrote:
| Does anyone remember brackets? I cant remember if brackets or
| atom came first but I remember switching from sublime to
| brackets to atom. Good times, I heard DHH is still using
| TextMate.
| whywhywhywhy wrote:
| I still use Textmate, think it's actually excellent these
| days and still updated a few times a year.
|
| Spellcheck always works, nothing ever crashes and acts weird
| I run it for 10+ months without issue. VSCode on my PC the
| spell check is inconsistent and weird and on a long enough
| timeline it actually crashes the whole operating system if
| you leave it open.
| solarkraft wrote:
| I do, it was quite cool! What stuck most with me is the CSS
| color picker.
| ketzo wrote:
| Did my first ever paid programming work in Brackets, helping
| some friends build a Wordpress blog. Good times.
| [deleted]
| zikani_03 wrote:
| Brackets was cool and will always be in my memory; made a
| close friend (who we eventually hired to become a co-worker)
| because I mentioned that I was working on a Brackets
| extension on a Facebook group.
| ngc248 wrote:
| I am still using brackets on the mac and I have to say very
| satisfied with it. I came from windows where notepad++ is
| unbeatable.
| IncRnd wrote:
| I've used TextMate for a long time. It works great.
| ubermonkey wrote:
| I was in TextMate all day every day for a long, long time
| but gradually shifted to Emacs, hilariously, AFTER I quit
| coding for a living -- because of OrgMode.
| dangoor wrote:
| I worked on Brackets full time at Adobe. It came before Atom
| and had a bit of a different target (designers-who-code vs.
| developers in general). Brackets was great fun, but it too
| ultimately needed to be sunsetted.
|
| Brackets was the foundation of Adobe Edge Code, which was
| part of Creative Cloud, so there were some bigger plans
| there.
| throw_m239339 wrote:
| Brackets came first.
| mjmsmith wrote:
| I still use TextMate, mainly for the excellent search &
| replace preview.
| antileet wrote:
| Electron was originally known as "Atom Shell"!
| davidkunz wrote:
| Ha, that makes sense from a physics perspective as electrons
| orbit the nucleus.
| d82nsjk9 wrote:
| Noice
| skohan wrote:
| Electron is both an amazing enabling technology, and also an
| artifact of the sad state of affairs for computing platforms.
|
| One could imagine a world where strong standards have been
| established which would allow you to easily deploy lean native
| applications across a wide variety of platforms.
|
| Instead we ended up in this bizzare world where if you want to
| maintain a desktop GUI app, you either need a large team to
| support multiple platforms, or you need to target minified
| javascript of all things, and run your software on top of a
| large, arcane compatibility layer.
| danuker wrote:
| > One could imagine a world where strong standards have been
| established which would allow you to easily deploy lean
| native applications across a wide variety of platforms.
|
| Here is a unified binary format that can run on Linux, MacOS,
| Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot
| from the BIOS.
|
| But it doesn't support GUIs (yet?).
|
| https://justine.lol/ape.html
| shp0ngle wrote:
| That's more of a hack than anything actually serious.
| cxr wrote:
| Category error. The creator certainly seems to be
| committed to putting this hack towards serious use.
| dijit wrote:
| I still think of these inefficient things as being great
| multipliers of potential, even if wasteful.
|
| FWIW: I'm probably one of the most "IT Conservative" people
| on this site, I still believe in sysadmins, dislike systemd,
| hate electron etc;
|
| But there is something to be said about developer
| productivity: if you can build a prototype in 10 days when it
| would have taken 10 weeks that can be a huge differentiator
| between companies; it means you can make 6x more prototypes
| in the same time window, or work through different iterations
| of the same idea.
|
| That's _hugely_ beneficial.
|
| I think if you treat inefficient things this way (I consider
| Ruby/Python in the same way) then we all benefit, test your
| ideas then go for gold on a more efficient platform.
| skohan wrote:
| Yeah I think I am in a similar camp. As a person involved
| in product development, I love the speed at which web
| technologies allow us to move.
|
| As a computer scientist, I can't help but cringe at the
| massive amount of collective inefficiency in the current
| state of computing.
|
| But don't get me wrong, I'd rather have the inefficient
| thing which creates value than nothing at all.
| vdnkh wrote:
| > One could imagine a world where strong standards have been
| established w
|
| And yet this didn't happen and Electron did. The "free
| market" of FOSS development settled on Electron as the winner
| for cross-platform development.
| redavni wrote:
| Indeed.
|
| Imagine a world where everything had to be deployed to the
| JVM and all progress depended on Sun/Oracle. Or god help
| us, IE/VBScript.
| pessimizer wrote:
| Electron piggybacked on the established (and enforced) open
| standards of the web to make up for a fragmented
| proprietary mess of software standards.
| skohan wrote:
| Yeah but that's not the whole picture - it's not just FOSS
| choosing Electron so much as platform holders being hostile
| to cross-platform development.
|
| For instance, if Apple had actually kept pace with OpenGL
| standards, and had embraced Vulkan, it would have been
| fairly straightforward to to build a native GUI framework
| which works across platforms.
|
| Electron won because all the platform owners basically had
| to embrace the implementation of web standards on their
| platforms. So they couldn't prevent those tools from being
| used to deploy local software as well.
| matthewmacleod wrote:
| The absence of Vulkan on Apple platforms--something that
| it's worth noting was developed _after_ Apple's Metal
| equivalent--is in absolutely no way even approaching a
| barrier to building a "native GUI framework".
|
| There literally _are_ cross-platform native GUI
| frameworks. Even Electron itself is a third-party
| implementation of a GUI framework - it doesn't use the
| platform's web tech implementation and bundles its own.
| skohan wrote:
| It's just one example of an impediment. If all the major
| platforms used a consistent standards-based graphics API,
| you could have one implementation of the drawing layer
| shared between all platforms.
|
| All these little wedges add up.
| toyg wrote:
| It wasn't FOSS that settled on Electron - it was businesses
| and corporations.
|
| Decisions were taken with an eye to balance sheets and P&L
| reports; Electron remains the cheapest option of them all,
| because the supply of moderately-skilled HTML/JS labor is
| naturally larger than for any other language - all thanks
| to choices the Netscape Corporation made in 1995, when they
| needed interactivity in their product and they needed it
| quick.
| Drew_ wrote:
| Businesses and corporations are part of FOSS. The
| majority of FOSS doesn't exist without them.
| matthewmacleod wrote:
| This is the most sensible take in my mind too.
|
| Electron _clearly_ means that we end up with a bunch of apps
| that would be otherwise unavailable, while at the same time
| meaning that we have a bunch of embarrassingly bad GUI
| experiences from companies who can afford to deliver better.
| vlunkr wrote:
| Agreed. I know Electron isn't ideal, but as a Linux user, I
| have a pretty hard time complaining. In the pre-electron
| world, something like Slack for linux either wouldn't exist,
| or would be several versions behind other platforms and have
| some goofy UI that didn't match the rest of your desktop. At
| least we have it and it works.
| mmcnl wrote:
| It's easy to criticize tools that actually exist. Makes you
| forget about all the tools that haven't made it to your
| computer.
| exyi wrote:
| This so much. I'm not fan of electron apps, but it's 1000x
| better to accept the chromium memory usage than a Windows
| VM memory usage. And I think that sharing the code between
| web and desktop also gives us very usable web apps (at
| least in case of Slack).
| bluehatbrit wrote:
| I completely agree, I'd rather have a memory hungry app
| than no Linux version at all. Slack is an odd one because
| you can run it in a browser, but things like 1Password are
| also good examples. I'd rather buy more ram than have
| companies pretend Linux just doesn't exist at all, at least
| it gives me options.
| mixmastamyk wrote:
| Are you kidding? It's a chat client that works in a
| browser. About as Linux friendly as it gets.
| vlunkr wrote:
| That's just an example. You want some more?
| https://www.electronjs.org/apps
| santiagobasulto wrote:
| I'm wondering how viable a for-profit electron replacement
| (with native support) would be? Like Unity (similar business
| model), but exclusively thought for apps.
| shp0ngle wrote:
| I am honestly not sure why do people minify javascript in
| electron apps.
|
| It doesn't really bring any advantage? You need to package
| whole Chrome with your app, the few MB you save with
| minification does not matter??
|
| But people here can enlighten me.
| cellis wrote:
| Minification also does some tree-shaking, which results in
| unused branches and libraries being pruned ( and therefore
| not needing to be loaded into memory ) and a smaller source
| size. Some constants can be inlined, which leads to faster
| execution times as there is no need to wait for a variable
| to be bound as its value is just written directly into the
| source everywhere it appears.
| jakear wrote:
| Minification helps the parser too, try running VS Code from
| sources and you'll notice startup is significantly slower.
| shp0ngle wrote:
| huh I would think there is no measurable difference
| there.
|
| However I honestly have no idea how much time does JS
| parser spends on what exactly. Are longer variable names
| and less tabs that big of a deal? It's all in memory
| anyway, no... the lexer or tokenizer or whatever (...I
| never finished my compiler course...) just goes through
| that
| skohan wrote:
| My best guess is maybe faster hash-map lookups on
| variable names?
| zackmorris wrote:
| I feel that we were well on our way to a cross-platform, web-
| based future before mobile smartphones arrived around 2007.
| Also CSS and frameworks like Angular and React really
| derailed browser progress because they convinced everyone to
| use recycler views by hand instead of just making tables and
| the DOM itself more performant and memory-efficient in the
| browser itself.
|
| I may be wrong in the moment, but I base my arguments on
| trends. Processing power, storage costs and bandwidth are
| always improving. So human productivity should always take
| priority over efficiency as time progresses.
|
| I'd vote for a real Web 3.0 based on first principles like
| declarative and data-driven programming, idempotence,
| immutability, one-shot scripting (perhaps even a Turing-
| INcomplete DSL) for initial render without side effects (like
| CSS variables but for HTML), dynamic element loading with
| something like HTMX, secure server-side includes, distributed
| databases using Paxos/Raft, even distributed computing with a
| real Docker that provides an actual secure sandbox and
| repeatable builds of untrusted secure/private code (maybe
| with something like homomorphic encryption). I can go on and
| on about what real (not phantom) tech looks like. And it
| looks nothing like SPAs.
|
| Also I think a lot of people recognize the need for this
| stuff, so ideas aren't the problem. The problem is, always
| has been, and always will be funding. In fact, my single
| greatest disappointment about the modern web is that stuff
| like advertising and eBay got coopted so there was never a
| viable way to make enough residual income to live on after
| the Dot Bomb around 2000/2001. The closest things we have are
| Uber and donating plasma. So we have a generation of highly-
| effective programmers spending the most productive years of
| their lives at a day job making rent, which is why rent
| increases. Hustling without understanding that the hustle
| itself is the failure when viewed through this lens.
|
| Blah I dunno why I write this obvious stuff anymore. It just
| ain't never gonna happen. It may as well be impossible. Or I
| should say, it may take another 20 years to get here, and I
| just don't think we have that long anymore.
| shp0ngle wrote:
| By the way "write once, run anywhere" was the original
| promise of Java. Back in the 90s! Before JavaScript was even
| a thing!!!
|
| People wrote Java applets that were supposed to be same
| everywhere. It even had GUI.
|
| Nobody expected that not Java, but _JavaScript_ will be the
| actual write once-run everywhere.
| bornfreddy wrote:
| Yes. But in reality it was more "write once, debug
| everywhere". It was actually quite a nice concept, but the
| resulting UIs were inevitably clumsy and had that
| distinctive (ugly to me) look, no matter what the platform
| promised. If it doesn't look good out of the box, it won't
| look good later either.
| llllllllllll9 wrote:
| one could imagine many things ...
| doliveira wrote:
| I'd describe it, together with Docker, as good solutions for
| problems we shouldn't have anymore
| donatj wrote:
| Replace "good" with "mostly workable" and I'm on board
| doliveira wrote:
| I was trying to be more agreeable but yeah, "mostly
| workable" is a better description.
| rvz wrote:
| Translation: 'Extinguishing Atom Text Editor'.
|
| Really expected and unsurprising.
| bm5k wrote:
| It took longer than I expected.
| Atreiden wrote:
| Called this ~4 years ago when they were acquired by M$.
|
| But it's still really sad to see. I use it because it was trivial
| to CSS style it to match my Desktop. It's comfortable to me in a
| way that other editors thus far have not been.
|
| Are there other editors with this level of customizability? I
| know VSCode and Sublime support theming but from what I can tell
| it involves installing pre-packaged themes.
| aordano wrote:
| there is an extension that lets you set arbitrary css in
| VSCode, albeit it's a bit cumbersome to use.
|
| https://marketplace.visualstudio.com/items?itemName=be5invis...
| wiseowise wrote:
| VSCode killed Atom long before GitHub acquisition.
| brundolf wrote:
| You can do a lot of customization in VSCode. Not as much as
| Atom, but way more than the average editor. I'm not positive
| whether or not it would be enough to serve your case
| [deleted]
| piefayth wrote:
| Well, if you just want a custom VSCode theme, you can try Theme
| Studio for VSCode: https://themes.vscode.one/. Login/signup
| required, though. No affiliation.
| WorldMaker wrote:
| You can override any color you want in VS Code with a couple
| easy settings in your settings.json file:
| workbench.colorCustomizations and
| editor.tokenColorCustomizations
|
| https://code.visualstudio.com/docs/getstarted/themes#_custom...
|
| You have to package it if you want to make it easy for other
| people to install, but if you just want to play with it, just
| open settings.json and start feeding it colors.
| jw14 wrote:
| I've made extensive use of this and it is a killer feature of
| VS code for me. Still, I wish it supported all of CSS like
| Atom did.
| rgoulter wrote:
| If level of customizability is your main metric:
|
| Emacs can go from this:
| https://emacshints.files.wordpress.com/2013/09/spash1.png
|
| to this: https://github.com/rougier/nano-emacs
| whiskey14 wrote:
| +1 for nano-emacs
| ericd wrote:
| Every now and then I'm reminded of why I decided to stop chasing
| the shiny new and just go back to emacs.
| lanstin wrote:
| Yeah. Which Linus uses, so probably works well enough for all
| non UI work whatsoever. Except maybe SQL?
| akagusu wrote:
| Emacs is up and running for the last 40 years and it will be
| for the next 40.
|
| Definitely is a software you can bet on.
| kylebarron wrote:
| I personally found Atom + Hydrogen [0] to be the most productive
| interactive Python environment I've ever used. I really want to
| see VSCode adopt some way to run a Jupyter kernel for a Python
| file (with a notebook UI) and have rich results in line with the
| code (i.e. not a terminal output off to the right side of the
| screen).
|
| [0] https://github.com/nteract/hydrogen
| amanwithnoplan wrote:
| VSCode already does that as of some versions ago.
|
| https://code.visualstudio.com/blogs/2021/11/08/custom-notebo...
|
| https://code.visualstudio.com/docs/datascience/jupyter-noteb...
| kylebarron wrote:
| oh I had a typo in my original comment. I meant *without* a
| notebook UI. i.e. I don't want to see a cell UI like a
| notebook. I want it to be just a normal Python file where the
| output shows up in line.
| tlhunter wrote:
| Even though Atom was much "lighter" than VS Code in terms of UI,
| VS Code had so much more development resources thrown at it that
| it was ultimately much speedier than Atom. IIRC, even Brackets
| was faster.
|
| I see people complaining about the death of Atom, but in the past
| few years there just hasn't been a use case where Atom was the
| best choice.
| deeptote wrote:
| Seriously, who actually uses Atom anymore? Before VSCode was a
| thing, I used it but then I got into Vim, Neovim, and now
| VSCode with the Vim plugin.
| nerdponx wrote:
| Atom to me was always "toy version of Sublime Text for web
| dev hipsters".
| sheepybloke wrote:
| Exactly. I used Atom for a while, but then it started getting
| so slow. My coworker mentioned I should try VSCode, and it
| did everything I wanted Atom to do but faster.
| gjs278 wrote:
| betamaxthetape wrote:
| The video produced to introduce Atom 1.0 [1] is my all-time
| favourite tech announcement video, and I honestly don't see that
| ever changing.
|
| [1] https://www.youtube.com/watch?v=Y7aEiVwBAdk
| spicysugar wrote:
| Vscodium + LiteXL[0] replaced Atom + Sublime for me.
|
| [0]https://lite-xl.com/
| zanethomas wrote:
| sad to see it go vscode? i've been trying to avoid it
| stefanos82 wrote:
| Kraken, the company behind https://cryptowat.ch use the following
| cross-platform GUI library for Rust https://github.com/iced-
| rs/iced
| rubyist5eva wrote:
| Who didn't see this coming after Microsoft bought GitHub?
| DarkContinent wrote:
| Is Julia's Juno IDE going to be affected by this?
| eigenspace wrote:
| No, because they already transitioned to VS Code years ago.
| eftychis wrote:
| Why would I want to learn a new editor, if it is going to be
| sunset -- there are many great options out there that are
| unlikely to disappear or be unsupported? Meaning Github's new
| editor has to offer something unique and great.
| Matthias247 wrote:
| Quote:
|
| > It's worth reflecting that Atom has served as the foundation
| for the Electron framework, which paved the way for the creation
| of thousands of apps, including Microsoft Visual Studio Code,
| Slack, and our very own GitHub Desktop.
|
| This is so true! Atom spearheaded a new generation of exciting
| apps and set them up for success. That is a huge achievement on
| its own - so thanks Atom team for everything you have done!
| a1371 wrote:
| Good memories with Atom. I had a silly "super mode" extension on
| it that gave me streaks when typing uninterrupted. It has lots of
| action graphics and screen shakes, I loved it.
| haolez wrote:
| I still prefer Atom's UX design over VSCode and I can't explain
| why. Amazing job on that front! I hope it gets traction with
| community support.
| eating555 wrote:
| Same here. I've tried VSCode multiple times but still switched
| back to atom. Just FEELS RIGHT.
| ehayes wrote:
| Me too. Even if you have a great theme in VSC you're still
| stuck with the sidebar and the bad Microsoft-y typography
| choices everywhere.
| bckr wrote:
| I was able to make VSCode look pretty great with a bit of
| work by following the ebook Make VSCode Awesome:
| https://makevscodeawesome.com/
|
| great fonts, minimal visual clutter etc
| brundolf wrote:
| It feels a little more natural/human. VSCode's default theme
| looks like Tron. Both are valid, but I can see how Atom's is
| more "cozy". It also had some fun "squishy" animations that
| were nice
|
| For the colors at least, there are VSCode themes that will try
| to mimic it for you
| imbnwa wrote:
| Yeah, have the same relationship, wish a UX expert could
| explain why my psychology is different with Atom vs VSCode
| ilovecaching wrote:
| Embrace. Extend. Extinguish. I won't touch VSCode with a 10 foot
| pole. Pick an editor that will last 40 years and isn't run by a
| mega-corporation that wants to eat FOSS so they can get us to buy
| into their subscription ecosystem.
| mproud wrote:
| What recommendations do you all have for alternatives?
| wly_cdgr wrote:
| WebStorm and the rest of the IntelliJ suite
| ghshephard wrote:
| There are a couple credible alternatives that get a lot of
| maintenance (I use them both for 3+ hours a day):
|
| If you are coding: Unless you are using IntelliJ (which a ton
| of of my colleagues do, and love) - it's a vscode world.
| Everyone at every company I've seen bangs away using that. It's
| kind of amazing how much inertia it's picked up (currently).
|
| If you are working with text: 90% of the time if I have a
| couple gigabytes of text I need to do a lot of work with - it's
| Sublime Text. Actively Developed. A really solid _text_ plugin
| architecture. The other 10% of the time I still use vim -
| mostly because it 's in my finger DNA. Emacs is the obvious
| alternative which lots of smart people I know use.
|
| I'd be interested in knowing if there are people who have used
| all five of these for > 100 hours that would recommend
| something else - (I haven't used Emacs that much - but I have
| well over a couple hundred hours on each of
| intelliJ/vscode/vim/Sublime. Probably close to 1000+ hours on
| the last three). (okay, small fib - close to 5,000+ hours on
| Sublime. I spend almost as much time in that tool as I do
| bash).
| ilrwbwrkhv wrote:
| I don't know why anyone would ever move away from Sublime Text
| in the first place.
| wiseowise wrote:
| Proprietary? Lack of quality plugins?
| adregan wrote:
| Sublime Text came pretty close to dying during the Sublime
| Text 2 years. I recall development slowed down substantially
| (it was a solo dev, IIRC), and it being pretty surprising
| when Sublime Text 3 came out.
| kasabali wrote:
| Sublime Text has never came close to dying.
|
| It was only adderal driven developer crowd making mountain
| out of a mole because they felt uneasy their frigging text
| editor hadn't been updated every other week.
| adregan wrote:
| ~10 years ago I was a Sublime 2 user surrounded by sad TextMate
| users--sad because TextMate had stagnated and was clearly on
| its way out and "everyone" had jumped to Sublime. When Atom was
| released, Sublime became the editor in decline.
|
| It seemed to me that there would always be an endless cycle of
| boom and bust with editors. It was a cycle with more in common
| with fashion than craft, and I wondered if I might end up
| wasting an inordinate amount of time switching editors
| throughout my career without any upside. So rather than switch
| to Atom, only to switch again a few years later, I set about
| with adopting Vim.
|
| The choice seems to have been correct as there will always be a
| new editor (that's more or less the same as the old editor)
| that catches hold, but I wanted stability. Vim gives me
| stability, and the only other editor I'd consider would be
| Emacs for similar reasons.
| acwan93 wrote:
| I really wanted to use Coda (now Nova [1]) from Panic, but I
| kept coming back to VSCode. VSCode seems to be the path of
| least resistance.
|
| I think I'll try it again after seeing the news about Atom.
|
| [1]: https://nova.app/
| trinsic2 wrote:
| Isn't this for MacOS only? Sorry, [I just left Windows](https
| ://www.scottrlarson.com/publications/publication-transi...)
| recently for it's anti-customer changes in Windows 11, Apple
| is way worse than Microsoft regarding its anti-choice
| position on all its products.
| drcongo wrote:
| I bought and really wanted to love Nova, but I just didn't.
| It's so clunky compared to ST.
| akagusu wrote:
| Just buy a license for Sublime Text or any intelliJ IDE.
|
| If you use your text editor professionally, they more than
| worth the investment.
|
| And if you want to build a text editor for your own needs,
| Emacs and Neovim are your friends.
| derbOac wrote:
| I've used many text editors back and forth and keep going back
| to Kate. It's what I use now. I'm not sure I'd say it's the
| best choice for everyone but it's what works for me the best it
| seems.
| kevinwang wrote:
| I think the reason it's unused these days is because it's
| largely been replaced by vscode
| Grazester wrote:
| Visual Studio Code is the most obvious. I actually forgot Atom
| existed. I move from it to VSC because Atom was just such a
| resource hog.
| Night_Thastus wrote:
| VSCode seems to be the go-to for most.
| shusaku wrote:
| Sublime I guess. I made the switch awhile back because if just
| how much snappier it is, but it's sad to see Atom go with all
| its nice add-ons...
| mtkd wrote:
| I moved from Sublime to Atom ...
|
| "Atom community involvement has declined significantly"
|
| Probably because it works well enough, some tools don't need
| endless enhancing
| forgingahead wrote:
| BBEdit.
| wsc981 wrote:
| I've used Sublime Text for many many years now and it's still
| my favorite text editor. I mainly use it for writing small
| reminders as well as Lua / LOVE dev.
| sph wrote:
| vim -> Sublime -> Emacs -> VSCode -> Emacs
| ^^^^^ I am here.
| akagusu wrote:
| My path:
|
| Sublime -> Atom -> Vim -> Emacs -> Emacs -> Emacs -> Emacs
| ARandomerDude wrote:
| vim -> Sublime -> vim -> Emacs -> vim -> VSCode -> vim
| ^^^ I am here.
| rgoulter wrote:
| If you're retaining vim on your workstation for quick editing
| of files, I'd encourage you to keep an eye on the Helix
| editor. https://helix-editor.com/
|
| There are three nice things about it: it flips vim's
| <verb><motion> into a <motion><verb> (like kakoune); it's got
| tree-sitter support out of the box (including for
| navigation); it's got LSP support out of the box.
|
| Its keybinding is perhaps in "uncanny valley" of vim's.
| Overall, it still feels well thought out.
| sph wrote:
| I've tried, but it's still a little immature for me.
| Definitely an interesting idea worth exploring more.
|
| And the reason I went back to Emacs is because of elisp and
| M-x. Those are the true killer features of that editor,
| still unrivaled.
| gaetgu wrote:
| Yep. I am waiting for its plugin support to come out to
| start really using it but I have it installed and I use it
| from time to time. It is pretty nice!
| ollien wrote:
| and then vim again. It will come full circle :)
| melling wrote:
| vim bindings in Emacs. :-)
| sph wrote:
| I went for evil-mode for a while, then I decided to just
| go full Emacs. I still use vim sometimes, but I've come
| to enjoy the Emacs bindings.
|
| Now I just need to install keymapper and convert all my
| M-w and C-y inputs to Ctrl-C and Ctrl-V.
| kklimonda wrote:
| vim bindings in Emacs are so great that when something
| isn't implemented properly (eg. editing macros, global
| marks) it hurts so much more.
| ollien wrote:
| I end up with vim bindings in VSCode at the present. It
| doesn't do everything but it does most things I want.
| There is neovim integration, but last time I tried it
| there were a bunch of glitchy things that didn't work
| right (I remember selection being buggy but I can't
| remember the specifics). Maybe I'll have to give it
| another whirl.
| indymike wrote:
| Why use and editor when you can use an operating system?
| Really love all the editing options. It's a good time to be
| a developer.
| Nicksil wrote:
| Sublime Text
|
| https://www.sublimetext.com/
| ghishadow wrote:
| https://github.com/lapce/lapce is slowly becoming my favourite
| editor specially for writing Rust.
| jlduan wrote:
| VSCodium
| bitwize wrote:
| Honestly? Emacs. Gonna be around for at least as long as RMS is
| still alive. I'd accept Vim as a runner-up; I'm conversant in
| it and can see where people might prefer it (though honestly,
| those people should probably enable evil-mode in emacs).
|
| But realistically? A significant majority of developers use
| Visual Studio Code; Atom is still only being used by absolute
| diehards. Visual Studio Code's complete supplantation of Atom
| (with which it competes for resources in the same organization)
| is why we're having this discussion.
| pantulis wrote:
| I used to say that investing some time in becoming proficient
| with Emacs (the One True Editor!) or vim will deliver returns
| over a lifetime-spanning career. But Visual Studio Code has
| already joined them and it is a pretty sensible editor
| platform to learn.
|
| Also totally subject for discussion: I suspect VS Code will
| see more innovation in years to come.
| natrys wrote:
| RMS hadn't been involved with any technical contribution or
| project level decision making for a while. I would say people
| like Eli Zaretskii are far more important. While there is no
| shortage of people willing to hack on elisp, I get the
| feeling that people who can hack on the C core, and
| possessing deep knowledge of core subsystems is slowly
| dwindling.
|
| But I do think Emacs will be fine. I don't think VSCode is an
| existential threat to Emacs in the same way Toyota is not a
| threat to Lamborghini. VSCode boasts impressive numbers, but
| it does so by consolidating in a target demography that was
| never a stronghold for Emacs to begin with - partly due to
| some level of indifference on its part. On the other hand,
| there are things Emacs is uniquely suited for, and for that
| reason it will continue to attract a particular type. I think
| in terms of absolute numbers Emacs userbase is still
| increasing, and I think falling numbers in terms of total
| percentage doesn't mean much for its survival.
| philliphaydon wrote:
| I like brackets but always ends up in VSCode due to extensions.
| tristan957 wrote:
| Brackets in nearing end of life or is already at that point.
| Adobe announced it a while ago.
| philliphaydon wrote:
| https://news.ycombinator.com/item?id=26341931
|
| Just found this. It's a shame. I donno why but I just liked
| brackets interface.
| Santosh83 wrote:
| In this case a community of devs seem to have picked up
| the code base, forked it, and is actively developing. So
| its not exactly dead.
| SenHeng wrote:
| Another Brackets user! There must be dozens of us!
|
| I used Brackets too back then and tried Atom a few times but
| it was always too slow and laggy. I was so glad when VSCode
| came out and that it was actually good. I was in the midst of
| switching to VIM but it was just too much of a bother.
| corrral wrote:
| It's a _very dumb_ reason to stick with an editor, but I have
| trouble going back to Sublime after VSCode despite preferring
| most things about Sublime, because I _always_ forget how to
| manage packages using Sublime 's command prompt and have to
| screw around with it for a while each time, while VSCode has
| a GUI for that so the memorization required is zero, _and_
| can easily browse available packages without bouncing out to
| a browser, _and_ it often prompts me to install relevant
| plugins so it 's just a matter of clicking "OK".
|
| Every time I try to go back to Sublime, this annoys me right
| off the bat and I'm back in VSCode by the end of the day.
| ghshephard wrote:
| Ctl-Shift-P is used in VSCode as well as Sublime. And then,
| "Install Package"
|
| Or through the Gui - "Preferences --> Package Control"
| corrral wrote:
| Sure, I find that every time I google for how to do it
| :-)
|
| In VSCode, I can browse info about packages without
| having to remember a thing aside from "one of the six big
| icons on the left is 'Extensions'". One mouse click,
| start typing, click anything that looks like it might be
| good, get a ton of info and an "install" button. There
| are filters! So I can simply sort by "most popular" if I
| want, or by name, or a bunch of other things, all without
| having to remember anything for this somewhat-infrequent
| operation, because it's in the GUI.
|
| It's mainly the integrated package exploration that's
| missing. And the auto-suggestion for plugins--in fact, I
| rarely have to do any of the above, and just click "OK"
| to whatever VSCode suggests, and everything's fine.
|
| Sublime has (I just checked) a "package discovery"
| command, which... opens a web browser, to the exact same
| page you'd have ended on if you'd started by just
| googling it (which is what I do). So you have to find
| what you want on there, then go back to Sublime and find
| it again.
|
| The result is that in the best case it takes me 1% as
| long to install what I need on VSCode (just click OK),
| and worst case it takes me perhaps 50% as long, compared
| with Sublime. I'm also way less likely to go poke around
| and see if there's anything that might be useful, in
| Sublime.
|
| [EDIT] "Why aren't you way more familiar with the command
| palette?" ephemeral shells as anything more than dead-
| simple launchers make me really uncomfortable. I _hate_
| using them. Apple spotlight? I use it extensively--
| _only_ for launching programs, period, nothing else. I 'd
| much rather have a persistent shell environment I could
| attach from any terminal and leave open.
| ghshephard wrote:
| That's super fair. I'll admit I'm entirely in the same
| boat - if nothing happens on a new tool when I type Ctrl-
| Shift-P, I usually just shrug and go back to using all
| the other tools I have that do that.
|
| I do love the fact that, with Sublime, that 75%+ of the
| time when I want to do something, say, pretty-print a
| JSON text document, it's just: Ctl-
| Shift-P, "json" (Don't see anything obvious) [hit
| backspace to clear json] "Install Package", "json"
| See the "Pretty Print" option, install it in 2 seconds,
| and on my way.
| d_watt wrote:
| My even dumber reason 5 years go was sublime's extension
| system at the time didn't allow styling of the file
| explorer, so git status wasn't available.
|
| The entire editor being easily tweakble is the killer
| feature of web-tech based editors.
|
| Sublime may have opened up more customizability since
| then...
|
| It's amazing how much a minor annoyance can drive someone
| to a completely different solution.
| [deleted]
| fungiblecog wrote:
| Another editor bites the dust - another reason to stick with
| Emacs
| andrew_ wrote:
| Nooooooo. I so much prefer Atom over VSCode. I've read the spin,
| but this smells like Microsoft finally doing what we all
| predicted - killing off the competing product.
| wiseowise wrote:
| > killing off the competing product.
|
| There's nothing competing about Atom. Its fate was sealed when
| VSCode started gaining traction, and that happened before
| GitHub acquisition.
| [deleted]
| bilekas wrote:
| I loved Atom when it fisrt came out, was a little heavy on my
| machine at the time, but it was worth it. Had much easy plugin
| system than sublime and editplus that I was using. It was a go to
| for my windows machines where i didn't want to play with my VIM
| config etc.
|
| But when VSCode came along it was over for my time with Atom.
| Wish the best for the new spiritual successor though zed.dev.
| vjandrea wrote:
| Just a noob here, but I love the way Atom displays and handles
| merge conflicts; still my editor of choice when I rebase / merge.
| oxff wrote:
| VSCode ate everyone's lunch. It is SO GOOD
| brundolf wrote:
| I held out for a year or so after VSCode was released. It felt
| scummy how MS had swooped in and tried to hijack this new
| category of editor that GitHub had invented (this was before
| they'd been acquired, I believe)
|
| But once I tried VSCode... man, there was no going back. It was
| infinitely more performant and cohesive. Atom (with IDE-like
| features installed) felt so sluggish by comparison. I think the
| main improvement was how opinionated VSCode and its extension
| APIs were; Atom extensions could have _dependencies on each
| other_. I remember you had to install an extension for generic
| IDE hover-overs and such, before installing the actual language
| plugin, and then there were _competing standards_ for which
| generic hover-over framework each language wanted to use. It didn
| 't just complicate the user-experience, I'm convinced this was
| the reason the editor would get so slow; the APIs were too low-
| level and all the plugins were fighting with each other instead
| of going through standard channels.
|
| But, Atom will always have a special place in my heart. It blazed
| new trails in editor customizability (even if the degree ended up
| being its downfall, quite a bit of that legacy can still be found
| in VSCode). It invented the entire concept of web apps as desktop
| apps, which despite what some here would tell you, I think is a
| very good and important thing. And it always had such a fun,
| community feel to it that's been mostly lost with VSCode.
|
| It was time, but I will miss it. I'll close off with the very
| cute and fun Atom 1.0 announcement video:
| https://youtu.be/Y7aEiVwBAdk
| nerdponx wrote:
| > I held out for a year or so after VSCode was released. It
| felt scummy how MS had swooped in and tried to hijack this new
| category of editor that GitHub had invented (this was before
| they'd been acquired, I believe)
|
| Depending on what you consider the "category" to be, Sublime
| Text (2) was well-established for years before Atom came out,
| with BBEdit and TextMate before it.
|
| Not to mention Kate, Geany, and the various other "lightweight
| extensible code editors" that have been out there for years and
| years.
| moffkalast wrote:
| > Atom extensions could have dependencies on each other
|
| This. This always has been and always will be a critical
| ecosystem mistake.
|
| The principle of one msi/exe installing everything you need on
| Windows, one click downloading an entire app from a store on
| Android or iOS is seamless and almost always error free. Or in
| your example with VSCode having self contained encapsulated
| plugins that install with one click.
|
| Meanwhile I'm having issues installing things and resolving
| dependencies with pip in python, apt in linux, npm, etc.
| basically all the time. It's a shit system that only pretends
| to be elegant and it's time we fucking admit it to ourselves.
| Designed by elitist morons for elitist morons and everyone else
| is paying the price.
| brundolf wrote:
| That seems extreme.
|
| Any ecosystem has to strike a balance between which things
| should be opinionated/officially-sanctioned/standardized, and
| which things should be left open in "userspace". I think Atom
| made the wrong choice by outsourcing some very standard
| features to the community, like hover-overs and underlines.
| VSCode seems to have hit a sweet-spot, offering standard
| solutions for common functionality but leaving plenty of
| doors still open for people to build on.
| moffkalast wrote:
| Well perhaps. The main distinction that needs to be made is
| whether something is supposed to be a library or a final
| product. It seems to be more and more usual these days to
| blur the line between the two and it's making life worse
| for everyone involved. Libraries should not be shipped
| separately, no exceptions.
|
| Even cases like installing the .NET framework or the JVM or
| some C++ redistributable are parts of that idea that leaked
| into the otherwise flat packed environment of Windows for
| example, and all I've ever seen it is cause issues due to
| version mismatches or them missing. Just completely self
| destructive behaviour in order to save a few megabytes...
| and not even that when in practice you end up with 14
| installations of the same thing with different versions for
| every app ffs.
|
| Android is arguably handling this way better, as such
| stupidity simply isn't even allowed there (to my
| knowledge), as are web browsers. Imagine having to install
| a chrome extension to use a site properly, people would
| think you're insane!
| mook wrote:
| > It invented the entire concept of web apps as desktop apps
|
| Mozilla actually had that in early 2000 or so; their whole UI
| (before Firefox existed, even) was a webby. Except it was their
| own weird sort of webby and not normal HTML, most of the time.
|
| Using normal HTML would be around IE4 with their .hta files, I
| think. Didn't seem to have too much uptake though.
| brundolf wrote:
| Fair! Maybe I should've said "got web apps as desktop apps to
| finally take off"
| SahAssar wrote:
| > It felt scummy how MS had swooped in and tried to hijack this
| new category of editor that GitHub had invented
|
| Wasn't brackets and atom released pretty much at the same time,
| both built on CEF?
| brundolf wrote:
| Interesting! I hadn't heard of brackets before.
| fungiblecog wrote:
| If i had a dollar every time a developer said "we're going to get
| it right this time"...
| Narann wrote:
| I use Atom for static Markdown blogging only. The reason is I
| customized Atom for this specific task and nothing more. Atom is
| mostly an advanced text editor than an IDE. I have Hunspell in
| both English and french, it detect word similarity and provide
| auto completion for this, it has some typewriter extension, etc.
|
| I'm reluctant to use VSCode because of M$ pushing for its
| tooling, but it looks like I will have no choice on the long run.
|
| Is there anyone in the same boat? Which highly configurable text
| editor can be use for this?
| trinsic2 wrote:
| I'm in the same boat and look for a configurable text editor. I
| have Sublime, but haven't used it much, until now.
| nathansobo wrote:
| Founder of Atom here. We're building the spiritual successor to
| Atom over at https://zed.dev.
|
| We learned a lot with Atom and had a great time, but it always
| fell short of our vision. With Zed we're going to get it right.
| Written in Rust, custom native UI framework, engineered to be
| collaborative. Just starting our private alpha this week, so the
| timing of this announcement feels quite fitting.
|
| Here's a talk I gave last month: https://youtu.be/wXT73bBr83s
| Communitivity wrote:
| Sounds interesting. I've love to take part in the alpha and
| provide feedback. I've done software engineering professionally
| for 25 years in Javascript, C++, Rust, Java, Erlang, Elixir,
| Clojure and Python (mostly Java and C++). I've used Emacs, VS
| Code, Visual Studio, and other IDEs.
| Petersipoi wrote:
| https://zed.dev/waitlist
| gosukiwi wrote:
| Atom was the first editor I wrote plugins to and contributed to
| core. I prefer it over VSCode, as it does less, and it's easy
| to customize for web devs. Sad to see it go, but it's for the
| best :(
| alephnan wrote:
| All these new generation text editors are cool and all, but I
| feel they are mostly rehashing the UI of VSCode. VSCode is fast
| enough, and the perceived speed of text editors / typing only
| needs to be so fast.
|
| Looking forward to innovations in UI. Cause otherwise, VIM is
| comparable if not better in performance than modern text
| editors.
| PascLeRasc wrote:
| I think Atom was perfect, for what it's worth. I've always
| found it to be faster than VS Code.
| aniforprez wrote:
| IMO the killer thing that VSCode has over all the other editors
| is the wealth of extensions and a certain degree of simplicity.
| What are your plans for Zed in terms of extensibility and are
| you aligning more towards making something beefy and full-
| featured like the IntelliJ offerings or something more
| "lightweight" like VSCode or Sublime?
| quaunaut wrote:
| Atom practically invented the kind of extensions that VSCode
| had, and even several years into VSCode's life Atom far
| outstripped it in Extensions.
|
| Perf became the biggest problem however, which VSCode took
| over.
| shakow wrote:
| > Atom practically invented the kind of extensions that
| VSCode had
|
| Let me introduce you to Emacs, vim, Sublime, TextMate, ...
| frostwarrior wrote:
| > Emacs, vim
|
| Unlike VSCode, Emacs and Vim have a learning curve. And
| turning them into full blown IDEs makes their usage even
| more complex.
|
| > Sublime
|
| Sadly, Sublime is sort of dead.
|
| > TextMate
|
| TextMate: Text editor for macOS
| shakow wrote:
| > Unlike VSCode, Emacs and Vim have a learning curve.
|
| That's not the point, we were talking about plugins.
| dghlsakjg wrote:
| I think that the learning curve might be in reference to
| installing plugins.
|
| Installing an extension on vim (never done emacs) is
| something that does not just happen easily. There is no
| intuitive search for extensions built in, you likely have
| to install software that manages your plugins.
|
| VSCode on the other hand rarely requires more than a
| single click through a built in interface.
|
| The plugin ecosystem exists for command line editors, but
| it definitely has a learning curve
| medo-bear wrote:
| > Unlike VSCode, Emacs and Vim have a learning curve
|
| have you seen the extent of available emacs packages?
| maybe it is a learning curve for a person who just
| learned how to power on a computer but i find emacs soo
| much more approachable
| enahs-sf wrote:
| At risk of dating myself, I am still rocking with sublime
| text and vim.
| boredtofears wrote:
| Sublime is very much not dead. It's still much faster
| than vscode or any other heavyweight IDE.
| nh2 wrote:
| > Sadly, Sublime is sort of dead.
|
| Sublime has ongoing development on
| https://www.sublimetext.com/dev and the last major
| release (4) was just about a year ago.
| _puk wrote:
| I was under the impression that the "forced" upgrade to
| Sublime 4 caught quite a few out, and may have been a
| nail in the coffin.
|
| I'm still rocking SLT 3, and it's my go-to for large file
| handling or just as a simple scratchpad, but development
| (of SLT) feels like it moves at a snails pace.
| w0m wrote:
| > but development (of SLT) feels like it moves at a
| snails pace.
|
| This is how it's always been I think; their model.
| smolder wrote:
| I'm in the same boat. I bought ST3 and have avoided going
| to 4, as now it's just my scratch pad and .txt viewer,
| not really used for development.
| can16358p wrote:
| While I don't know about the plugin ecosystem of
| Vim/Emacs, I definitely agree with the learning curve
| part.
|
| In Emacs/Vim I can't even escape the program if I don't
| know a keyboard shortcut.
|
| In Vscode even if I forgot Cmd+W/Q I can simply click the
| close button. Not to mention that all the shortcuts are
| just globally used shortcuts in all the other software.
|
| While I respect praising by the community of Vim/Emacs, I
| really don't think it's beginner-friendly.
|
| So anyone starting a software career virtually picks
| Vscode, gets used to it, and almost has no reason to
| switch to something else for now unless they need
| something extremely specific.
| prmoustache wrote:
| I don't know.
|
| The rare time I use vscode instead of neovim I always end
| up with a lot of random characters into the code and have
| to close it without saving for fear of having broken
| something. You call that user friendly?
| BeetleB wrote:
| > In Emacs/Vim I can't even escape the program if I don't
| know a keyboard shortcut.
|
| Or, you know, you could just click on the File menu and
| click on Quit.
| ParetoOptimal wrote:
| > In Emacs/Vim I can't even escape the program if I don't
| know a keyboard shortcut.
|
| With emacs this is a feature, not a bug ;)
| Q6T46nT668w6i3m wrote:
| Sublime, TextMate, ...
| sealthedeal wrote:
| I love Sublime, still my fave
| yccs27 wrote:
| The instant-opening experience is just soo good, and
| Electron bloat nowhere in sight...
|
| I actually use VS Code as well, but more like an IDE with
| tons of extensions, and Sublime is my 'basic' text
| editor.
| can16358p wrote:
| Same thoughts.
|
| While Vscode is my IDE now, I definitely love the
| instant-opening of Sublime.
|
| Ironically, it's even launching faster than TextEdit.
| distances wrote:
| I tried to use VS Code but just couldn't stand it. I
| don't want to say it's sluggish but it definitely isn't
| snappy, not even with a M1 laptop. It's fine, but it
| isn't good.
|
| I ended up purchasing the upgrade to Sublime 4,
| definitely worth the price.
| bayindirh wrote:
| BBEdit.
| chipotle_coyote wrote:
| I love BBEdit, but its package ecosystem isn't well-
| developed compared to most other editors, and it doesn't
| have any kind of package manager -- it's more like Vim's
| native packages, e.g., "download the package and put it
| in this folder, and check occasionally for upgrades when
| you remember and re-install when appropriate."
| chipotle_coyote wrote:
| That's not my recollection, at least. I was more of an Atom
| fan than a Code fan in the middle of the last decade,
| mostly due to aesthetics, as shallow as that probably
| sounds -- but it felt like Code surpassed Atom in terms of
| community activity head-spinningly fast, like in its second
| year.
|
| I also think the sibling comment is right; TextMate never
| had the huge collection of plugins later editors did, but
| you can very much see the seeds of Sublime Text's package
| system in it, and Sublime is a very obvious influence on
| Atom/Code. (Although they were smart to have package
| management fully integrated; Sublime's package management
| system is a bit clunky by comparison.)
| dham wrote:
| Same, but if you're staring at an editor all day it has
| to look good. Atom did and still looks way better than
| VScode. VScode looks like a Microsoft product.
|
| You can also customize Atom easier than VsCode. Why even
| build on web technologies if you don't let your users
| change things. For instance you have to have an extension
| to custom load CSS and it's kind of a hassle. Heck even
| Sublime has an easier interface to change the text editor
| in real time. You don't really need to do much as it
| already looks good though.
| rjh29 wrote:
| Funny how people are so different. I have never once
| thought that I needed my text editor to look good. Stare
| at anything long enough and your brain isn't even going
| to process it anymore!
|
| fwiw I use Linux and suspect that's a big part of why
| Macs never appealed to me.
| chipotle_coyote wrote:
| While I am a Mac user, I've used Vim a lot, so I don't
| want to make it sound _too_ much like I demand text
| editors be visually stunning works of art. :) Code
| initially looked just kind of clunky and toylike to me,
| in a way that Atom -- and Mac native editors like
| TextMate and BBEdit -- didn 't. It's a little hard to
| explain. Code still isn't my favorite editor, but it's
| probably my favorite cross-platform editor.
| vanilla_nut wrote:
| For me, it's the noise and clutter -- every time I spin
| it up, it feels like VS Code is demanding my attention in
| multiple popups, and there's a new tab or button I've
| never seen before with some mystical purpose, and the
| bottom bar is some jarring color that makes me feel like
| something is broken.
|
| IntelliJ IDEs feel similar -- sometimes I'll open them up
| and after upgrading several plugins and dismissing a
| bunch of popups and "what's new" dialogs, I don't even
| remember what I was trying to do in the first place.
| mrweasel wrote:
| A month ago I switched back to Vim, from TextMate, but
| still on a Mac, and honestly: Vim is kinda pretty. I
| spend most of my day in fullscreen Vim, and with a good
| theme, Airline and a pleasing font it's just as pretty as
| VSCode if not more.
| joaonmatos wrote:
| Maybe I just have horrendous taste, but I just get GitHub
| Theme Light and am done with it. Do you tend to be
| nitpicky around aesthetics?
| alehlopeh wrote:
| I really don't think "selecting a color theme" qualifies
| as being "nitpicky about aesthetics." But maybe I'm just
| nitpicky about aesthetics.
| paldepind2 wrote:
| There is a fundamental difference between the kind of
| extensions that Atom has and the type Code has. It's
| something that people often miss when they compare the two.
|
| Atom was made to be infinitely customizable by using web
| technology. You can dynamically change everything you want
| with custom HTML, CSS, and JavaScript. Nothing is off
| limits. Want to shrink the size of the tabs? Just throw in
| some CSS, everything is changeable.
|
| Code on the other hand runs plug-ins in a separate isolated
| thread where they are left to communicate with the editor
| through an extension API. Every customization "hook" that a
| plugin has access to needs to be explicitly added in that
| extension API. The things that the devs didn't think (or
| want) to add are simply impossible. Want to shrink the size
| of the tabs? Tough luck (except for unsupported hacks).
|
| Code is awesome, but I think Atom should get more credit
| for what it tried to do. It is arguably the most
| customizable text editor ever.
| nsonha wrote:
| wonder how much coffeecscript played a role in it. I happen
| to be writting coffescript at the time and noticed how it
| tended to hide its unnecessary wrapping when you use its
| syntax sugar. Still kinda wish we have a typed version of
| it.
| l33t2328 wrote:
| The bloat VSCode has over Atom kills it for me.
| nsonha wrote:
| anyone can say vscode is bloated except atom. I gave it
| credit for being highly modular though. I remember being to
| disable the statusbar component (not just the UI)
| completely.
| joaonmatos wrote:
| Atom was unbelievably slower than VSCode for any comparable
| set of capabilities. What do you mean bloated?
| nathansobo wrote:
| We plan to make Zed extensible via WebAssembly, but we're
| taking a different approach than we did with Atom.
|
| Our goal is to make Zed fast, stable, and collaborative
| first, extensible second. We'll be taking a more conservative
| approach with our APIs to ensure we can preserve our core
| values even as users add extensions.
|
| Our goal is for Zed to have the lightweight and snappy vibe
| of Sublime with the power of a more full-featured IDE. These
| objectives are obviously in tension, but I think we can build
| something that balances them well. A collaborative IDE that
| feels fast and powerful.
| syrusakbary wrote:
| This is great. Syrus here, from Wasmer.
|
| I think WAPM and Wasmer could help a lot on the
| extensibility using Wasm plugins. I'd love to chat further,
| please feel free to reach me at syrus[at]wasmer[dot]io!
| the_duke wrote:
| Hey there. I've been thinking about implementing an editor
| agnostic WASM based plugin framework and started
| prototyping with some promising results, although there are
| also a lot of of WASM related constraints to consider.
|
| I think cross-platform plugins would be hugely beneficial
| for the whole ecosystem, and also generally for new editors
| since they can potentially benefit from a larger plugin
| developer community.
|
| Is that something you can see your team collaborating on?
| nurettin wrote:
| If you make Python a first class citizen and give it
| special support, you won't be disappointed.
|
| Man that felt a bit like extortion, but I mean well.
| wpietri wrote:
| Ooh, this is interesting. It sounds like you learned a
| lesson here. Could you say more about what prompted the
| change? I once talked with a Firefox engineer who felt like
| an initial urge for openness left them with a lot of API
| surface area that locked them into a lot of design choices.
| Was it something like that for you as well?
| boringuser1 wrote:
| DarylZero wrote:
| >I once talked with a Firefox engineer who felt like an
| initial urge for openness left them with a lot of API
| surface area that locked them into a lot of design
| choices.
|
| LOL, as if Firefox provided a stable API to extensions
| mumblemumble wrote:
| I think that's the inherent catch-22 of having a big API.
| You end up in a situation where you can't change things
| for fear of breaking the API, but you end up also not
| being able to hold the API stable for fear of not being
| able to change things. So you end up stagnating _and_
| breaking things all at the same time.
| nathansobo wrote:
| Very much so. As the first Electron app we were so
| excited about people being able to do anything they
| imagined. It was cool but ended up really constraining
| us. This time we really want to drive our API based on
| the most important things people actually need to extend.
| We need to navigate the trade-offs more intelligently.
| SaulJLH wrote:
| This "private alpha", any hints on how we might jump
| aboard!? ;)
|
| _EDIT_ Nvm, I see this is our best option for now:
| https://zed.dev/waitlist
| iamnbutler wrote:
| it's less about being exclusive and more about getting
| feedback on the specific features we are focusing on and
| building at the moment.
|
| For now, people pairing/collaboratively writing Rust is
| our focus, and we are pulling people in that fit that
| criteria!
| gosukiwi wrote:
| This is interesting. I wonder how Emacs solves that,
| given that it's one of, if not THE most, extensible
| editor out there. I'd think that is a good thing, but
| never considered the drawbacks, besides performance and
| plugin interop that is.
| bombcar wrote:
| Emacs either doesn't have APIs or everything is an API,
| depending on how you look at it - since it's source is
| available _at runtime_ plugins and modules can be first-
| class citizens performance-wise.
| tikhonj wrote:
| Design-wise, Emacs is less an editor with an API and more
| a set of core editing concepts (buffers, strings with
| properties... etc) embedded into a flexible language. The
| core concepts have a native implementation that's hard to
| change, but they're simple and flexible enough that you
| can put them together to do all kinds of text-editory (or
| even not-so-text-editory) things.
|
| Everything on top of the core is written in an open
| style, with Lispy features that make it easy to hook into
| or modify anything. Adding a small feature to Emacs
| doesn't feel like calling APIs from an existing
| application, it feels either like writing my own code
| with text editor stuff available as a library or,
| alternatively, like tapping into and fiddling directly
| with existing code in the system.
|
| This way of seeing Emacs explains both why it's so
| flexible and why certain things (better performance on
| long lines, concurrency) are so difficult: you can
| express _a lot_ using the core concepts and you can
| easily change other code that 's expressed with these
| concepts, but making fundamental changes to the core
| itself is far more difficult. Partly it's more difficult
| because it's an old C codebase pretty separate from the
| Lisp world but, more importantly, it's difficult because
| substantial changes to the building blocks will change or
| break existing code in ways that are hard to control or
| predict. It's the very flexibility on top of the core
| that makes the core itself hard to change, since the
| higher-level Lisp code is using the core concepts in all
| kinds of ways.
| scombridae wrote:
| _Well, it 's a doulbe-edged sword_.
|
| Causally linking glaring deficiencies (long lines,
| concurrency) to overriding virtues (extensibility) is a
| weak but common snow job aimed at emacs's critics who
| know nothing of emacs's internals. For this emacs critic
| who knows quite a bit about emacs's internals, I call you
| out.
|
| There's only one reason for emacs's many wtf frailties.
| No one's paying to fix them.
| bee_rider wrote:
| With Vim at least, and I think Emacs as well (although I
| don't use it), it seems like they have greater focus on
| providing the embedded scripting language, than deciding
| what to expose to the user via an API. In Vim's case at
| least, this seems to have resulted in multiple third
| party API-like projects (for things like installing
| plugins, linters, etc). It isn't clear to me the extent
| to which this is an artifact of the way the editor is
| structured, or to what extent it is just a result of
| having had time for these types of third party projects
| to grow.
|
| There are pros and cons of course -- these weird shims
| can be troubling from a performance point of view, but on
| the other hand a plugin environment can grow, reach
| popularity, and then fall apart, and not take Vim down
| with them.
| manaskarekar wrote:
| As someone who loved everything about Atom except the
| sluggishness and bloat, Zed sounds like exactly the thing
| that I've been wanting.
|
| VSCode/Codium is amazing but it feels the same - sluggish
| but a feature/extensions-packed behemoth.
|
| I hope Zed is able to establish a nice extension
| ecosystem as that is priceless!
|
| Thank you!
| galaxyLogic wrote:
| This is important, think about the whole Web. Too many
| ways of doing things and too much backwards compatibility
| needed for tools to develop further.
|
| I always cringed at languages like Perl and also Groovy
| where the pride of the language designers seemed to be
| that there are so many ways to do the same thing.
| sigzero wrote:
| There are so many ways to do the same thing...in any
| language. That's just reality.
| Already__Taken wrote:
| IMO the leap from sublime to vscode was because the
| extensions made it so welcoming & bultin. I think the next
| leap from that is by-default sharing of those extensions
| and config. WASM might be able to do that coupled with
| security defining execution. We need a trusted mechanism to
| share what git-hooks promised without thinking about it.
| Like you said, collaborative.
|
| If extensions lock down the files they will touch and the
| urls that can be visited I think sharing them becomes more
| palatable.
| dghlsakjg wrote:
| VScode offers workspace settings that you can check into
| git that will get picked up by anyone else using vscode
| on that repo.
| bstar77 wrote:
| NeoVim can compete on this front. See LunarVim for a heavily
| extended experience.
| rjh29 wrote:
| IMO the killer thing is performance, VSCode starts fast and
| is smooth to write with. It blew away the older set of
| Electron-based editors. They work tirelessly on performance
| every release and it shows imo. Allowing extensions without
| destroying perf isn't easy either.
| prmoustache wrote:
| Which editor did you came from to think vscode start fast?
| msword?
| gibbitz wrote:
| This is why I continued to use sublime text all the way up
| to capitulating to TypeScript. Code was slower because of
| all the intellisense. I've had Code freeze on me a few
| times. Something that I don't have happen in Sublime or
| Vim. If you have a lot of RAM and work on a current
| mainstream OS it may seem smooth, but it's still using
| 400mb of RAM. May as well use Eclipse or WebStorm FWIW.
| That said I'm using VSCode now too, but things can always
| be better :).
| galaxyLogic wrote:
| Part of it may be just Windows. I use Windows a lot to
| move files and folders around and the File Explorer is
| something I constantly need to wait on to respond. The
| Windows as GUI is not very responsive in my experience.
| manigandham wrote:
| > _" but it's still using 400mb of RAM"_
|
| Why does this matter? What is the point of saving RAM
| instead of using it?
| Karunamon wrote:
| It matters because your program is probably not the only
| one running.
| distances wrote:
| I said basically the same in a sibling comment but I can't
| agree with you. VS Code doesn't start fast enough and it's
| not smooth to write with. It's not exactly bad but you
| definitely feel the slight delays and slowness _all the
| time_.
|
| I went back to Sublime exactly to get faster startup and
| smoother writing than what VS Code was offering. So I'm
| pretty excited to see how Zed turns out!
| ClawsOnPaws wrote:
| Hey,
|
| Please don't forget about accessibility. Getting this right
| from day 1 will make your life a lot easier in the long run. If
| I remember correctly, I was never able to use Atom with a
| screen reader. Hearing custom UI already makes me nervous and
| I'm pretty sure I won't be able to use Zed with a screen reader
| either.
|
| Blind developers exist. Please don't forget about us. It's one
| of the few areas where we can actually make a meaningful
| difference together with our peers on an equal playing field.
| polote wrote:
| It is normal to advocate for your needs but asking for it to
| be included from day 1 is weird. The same way you don't start
| a saas app with localization from day one.
|
| I'm not blind so for sure I won't really care about
| accessibility but honest question why not use an ide
| developed for blind people instead of using the same as non
| blind people?
| uxcolumbo wrote:
| Wow... really? Accessibility is not just for blind users.
|
| It's also for users with poor eyesight, colour blind folks
| or folks with motor impairment.
|
| It can happen to any of us and then you'd be glad that
| developers are taking accessibility standards seriously.
| __jem wrote:
| This comment is honestly shocking to me. It's not "weird"
| for people with different needs to ask to be included in
| the software we build. Accessibility is a baseline for any
| product in 2022 and _needs_ to be included from the start
| otherwise it inevitably won't work when it's strapped on
| later.
| ziml77 wrote:
| I also find it weird. I'm not disabled but I think
| designing for accessibility is important. It's hard to
| tack on later and have it work well
| LoveMortuus wrote:
| I'm guessing that by "included day 1" they meant that if
| you do it this way it's much easier then having the product
| designed and then re-engeneering it to support
| accessibility later.
| girvo wrote:
| It is not weird at all, and claiming that asking for
| accessibility to be considered is weird is frankly rude.
|
| Approaches like yours are why people who are differently
| abled feel left out and like second class citizens a lot of
| the time.
| hx2a wrote:
| Please learn more about the needs of blind people before
| writing something like this.
|
| Adding accessibility for screen readers is much more
| difficult to add later in the project lifecycle. Thinking
| about those design considerations early makes a big
| difference in how accessible it will later. If developers
| don't think about these things early, most likely the
| product will never be fully accessible, ever. Blind people
| have seen this played out before with other software
| products and know where this path leads.
|
| (I'm not blind but have worked with blind developers. I'm
| not an expert in accessibility but I know enough to know
| how important it is to listen to accessibility needs)
| serial_dev wrote:
| How do other editors/IDEs perform in terms of accessibility?
| What are your favorites?
| ClawsOnPaws wrote:
| My favorite is VS Code by far. I use it daily. They
| recently also added a bunch of sound cues to help figure
| out if code is folded or a line contains an error. It's
| pretty great. Auto completion reads well, the parameter
| hints read, even the built-in terminal works. So overall
| I'm really happy with it.
| kfrzcode wrote:
| Microsoft is particularly good with regard to a11y and
| devtooling
| exysle wrote:
| Would you mind commenting on XCode? I heard that Apple
| really cares about accessibility.
| giancarlostoro wrote:
| I've only ever heard good things about Visual Studio in
| this area, not sure if other IDEs are comparable. I do know
| Eclipse has a specialized build for this purpose as well. I
| wonder if XCode is also decent in this regard. I think
| Notepad++ might be only other one from memory that I know
| of.
| dharmab wrote:
| Visual Studio is quite good: https://youtu.be/94swlF55tVc
| mongol wrote:
| Unrelated question: how does accessibility work on
| smartphones? Do you use something like a physical keyboard to
| interact with GUI elements in apps?
| mutagen wrote:
| I came across this video from 2020 that demonstrates a
| couple of ways it works on iOS:
|
| https://twitter.com/Kristy_Viers/status/1287189581926981634
|
| You can turn on the various accessibility features and try
| them yourselves. While I was already aware of the
| 'voiceover' features, I was blown away by the braille
| keyboard and how quickly she could type with it.
|
| Blind people use TTS set at ridiculous speeds that make my
| 1.5x podcast playback seem glacial. Even back in the late
| 80s I remember a blind classmate who had a portable
| electronic typewriter thing that read her entries back to
| her at rapid speed.
| jeffy90 wrote:
| smartphones come packaged with a screen reader. The screen
| reader announces what is present on the screen
| kobalsky wrote:
| Cool project.
|
| Since it's not mentioned on the website, what will be your
| roadmap regarding security?
|
| I feel that all IDEs have security handled as an afterthought,
| VSCode made some progress but it's far from being there.
|
| I just want to be able to use a code formatting / language
| extension without having to worry about it subverting my whole
| computer in a future update.
|
| vscode is halfway there with containerized development, but
| apparently they didn't intend that to be security measure and
| they make it clear to only run trusted extensions. I'm guessing
| there are ways to access host files through the bridge.
|
| It's obvious that we still have to trust extension authors, but
| an IDE with the correct security sandboxing can limit the blast
| zone if it gets compromised (leaking a source file vs getting a
| rootkit installed and ending up releasing compromised updates
| to production)
| rafaelturk wrote:
| Amazing! Sounds like a great foundation! Curious about UI
| execution in Rust
| nathansobo wrote:
| We plan to start blogging about this pretty soon.
| ilovecaching wrote:
| Please make zed capable of running in a terminal. If I could
| have a modern editor that can run in the terminal and had a
| nice GUI, I would definitely pick it up. There's still many
| instances where I'm working on a remote dev machine, on my
| iPad, over a serial connection, inside of tmux, where a
| terminal based text editor is a necessity.
| dymk wrote:
| Does a single text editor exist that supports both a TUI and
| GUI mode?
| gkbrk wrote:
| Emacs supports both a TUI and a GUI mode.
| tasuki wrote:
| Vim/Gvim ?
| nathansobo wrote:
| We have graphics, but I could see a mode where you `scp` a
| headless moon lander version of Zed up to a remote server to
| do remote development. VS Code has a feature like this but I
| hadn't used it much before switching to Zed full-time.
| Shish2k wrote:
| > VS Code has a feature like this but I hadn't used it much
| before switching to Zed full-time.
|
| Please check it out -- being able to edit / run / debug
| code on a linux server using a mac desktop over ssh, and
| having the whole experience be as seamless as edit / run /
| debug locally, is a _huge_ win -- it 's pretty much _the_
| reason that I'm currently using VSCode 90% of the time
| despite being a huge JetBrains fan (to the point of paying
| for their full enterprise pack out of my own pocket)
|
| (JetBrains tools do kind-of support remote file editing,
| but it's flaky and slow, and remote run / debug are a
| nightmare -- compare to VSCode, where I sometimes mix up
| local and remote development because they're identical
| except for the hostname in the titlebar when running
| remotely)
| PascLeRasc wrote:
| Is what VS Code does different from using an SFTP mount
| plugin like remote-edit on Atom?
| 5e92cb50239222b wrote:
| It also works on Windows through ssh (including desktop
| win10), which makes working with Windows easier on the
| nerves.
| tormeh wrote:
| Any chance of collaboration with https://lapce.dev/ ?
| [deleted]
| eikenberry wrote:
| When will the source repository going to be made public and
| what license do you plan to use? For the editor and the UI kit.
| Looking forward to seeing how that all works.
| gigatexal wrote:
| Add a really good vim mode and I'm there.
| nathansobo wrote:
| Earlier this year Keith Simmons, the author of Neovide
| (https://github.com/neovide/neovide), joined our team. He's
| been working on Vim bindings and paying a lot of attention to
| getting it right. As you probably know there's a lot of
| surface area, so this will take time.
| gigatexal wrote:
| Fantastic. Let us pay you so this sticks around.
| thewoolleyman wrote:
| Best of luck with Zed, Nathan! I've always been impressed with
| your brilliance, vision, hope, and positivity. Hope we can
| catch up again soon, until then keep changing the world for the
| better!
| jonathankoren wrote:
| Is Zed a company? I wish you luck, but I'm pretty skeptical
| that a whole company can survive on making a text editor, or
| even editing tools in general. Wouldn't it be safer for user if
| you open sourced this?
|
| As someone that loved Atom, and have been screwed over by
| Facebook's Nuclide, and now Github's Atom, I have to think
| about my options.
|
| (No emacs isn't an option.)
| 404mm wrote:
| Hi, when can we expect to see some first preview?
| infogulch wrote:
| "collaborative" "Rust" "code editor" "CRDTs" is very
| reminiscent of Xi Editor by @raphlinus which shared all of
| these traits. Xi was abandoned with the conclusion that CRDTs
| aren't suitable as a basis for text editing interactions, or at
| least that implementation wasn't.
|
| Is Zed related to Xi in history or as inspiration? Why are you
| confident that Zed will be able to overcome the issues that
| blocked Xi's advancement?
| 420official wrote:
| What's the reasoning behind this iteration being closed-source?
| nathansobo wrote:
| This time we're on our own in the marketplace with no big
| revenue-generating company supporting us. We'd like to be as
| open as humanly possible while being able to build a
| defensible business around the editor.
| [deleted]
| greyhair wrote:
| Just make it keyboard centic. I don't want to touch the mouse.
| nathansobo wrote:
| Definitely a priority.
| geodel wrote:
| Well, unless it is paid, I don't know how would you continue to
| toil for years making great editor. And unless it is free, gain
| a good market share to continue to support.
|
| I hope you would have some solution to this conundrum.
| nathansobo wrote:
| We plan to monetize collaboration. Zed is a collaborative
| platform disguised as a world-class code editor.
| docmechanic wrote:
| I'm always excited to see new ways to monetize open source.
| Hope this is another open source success story.
| dymk wrote:
| How often do developers want to edit the same file, at the
| same time, and have those updates occur in real-time?
|
| I see this as a compelling feature for something targeting
| the use cases of, say Google Docs, where multiple people
| are contributing to an outline document or a business plan
| at the same time - but for code, I don't quite see the
| appeal.
| BaseballPhysics wrote:
| > How often do developers want to edit the same file, at
| the same time, and have those updates occur in real-time?
|
| That's a very specific example of collaboration. Remote
| work is exploding. What about, say, integrated,
| collaborative debugging or code review? Integrations with
| things like Slack?
| ctvo wrote:
| I'm sure the folks at Zed know what they're doing, but
| this is already possible in multiple editors / IDEs. I'm
| excited to see how Zed innovates in this space.
|
| Examples:
|
| - VSCode Live Share
| https://code.visualstudio.com/learn/collaboration/live-
| share
|
| - JetBrains IDEs Code With Me
| https://www.jetbrains.com/code-with-me
|
| - Standalone https://www.coscreen.co https://duckly.com
| chrisseaton wrote:
| Do you never pair?
| dymk wrote:
| I do, and one person has control over the keyboard at a
| time. Hell on earth is two people making write operations
| at the same code buffer.
| chrisseaton wrote:
| I don't see why? Doing some refactoring you've decided to
| do and you can both go through the file at the same time
| refactoring different methods or whatever. What's the
| issue?
| iamnbutler wrote:
| We do this frequently :) It's awesome to get through
| tedious tasks twice as fast
| nsonha wrote:
| I do this all the time. I use a tool that has 2 modes:
| turn-based and multicursor, the turn-based mode is
| signnificantly more annoying. Most of the time you just
| use it to highlight but it's also good to be able to help
| the other person with typos and comments, while they are
| focusing on the logic.
| a4isms wrote:
| Nathan, I remember your passion for this project from its very
| early days. It has already borne fruit that has grown into a
| garden in the form of Electron, and I'm excited to see you are
| reimagining Atom in the form of Zed.
|
| Best wishes for Zed's success!
| nathansobo wrote:
| Thanks very much for your kind words and wishes!
| a4isms wrote:
| You are very welcome. Although in my haste I mixed my
| metaphors up!
|
| Not sure if Atom was a fruit that grew into an orchard or a
| seed that grew into a garden. How about both?
| hannob wrote:
| I've spend a few minutes on your page, yet I couldn't answer
| the following questions:
|
| * Do you already have a working editor I could test or is this
| merely an announcement?
|
| * Is this an open source project or a proprietary product? Does
| it cost money? If yes how much?
| BaseballPhysics wrote:
| > custom native UI framework
|
| Cool project, but this is clearly a contradiction.
|
| wxWidgets? That offers a native UI. Wherever possible it uses
| the UI controls from the underlying OS/system to render the
| interface.
|
| Looking at the project page it describes "a GPU-powered UI
| framework that met our needs."
|
| That's not a native UI. That's a non-native UI compiled to
| native code, ala something like Flutter.
| nsonha wrote:
| I feel like people are talking about different things when
| they say "native", to me it's more about being compiled to
| native binary, or being performant, than "native UI".
|
| I've never been impressed with native UIs in any platform,
| web or mobile. The only context where I appreciate them is
| accessibility.
| nathansobo wrote:
| Sure, cross-platform UI that's on the metal is a more
| accurate description.
| loic-sharma wrote:
| Did you consider using Flutter? If yes, what made you
| choose against it?
| nathansobo wrote:
| We just wanted to be pure Rust and have complete control.
| wpietri wrote:
| It's been a few years since I used Flutter, but doesn't
| it still require you to use the related language Dart? I
| liked the idea of it, and I thought the tight integration
| between Flutter and Dart allowed them to do some cool
| things. But I wasn't a huge fan of the language itself.
| And I think it's a lot to ask prospective extension-
| writers to learn a new language.
| gman83 wrote:
| If you know Java or JavaScript, Dart is extremely easy to
| pick up.
| wtetzner wrote:
| Sure, but that doesn't help if your project is in Rust.
| OvermindDL1 wrote:
| Rust actually has a library with very good flutter
| integration, it does require using dart for the actual
| flutter part though, but it works well together.
| ctvo wrote:
| Are you talking about nativeshell[1] or something else?
| nativeshell looks to be in early stages of development
| still.
|
| 1 - https://nativeshell.dev
| edko wrote:
| Do you have any plans of open-sourcing the UI framework?
| nathansobo wrote:
| We do have plans. Stay tuned!
| OvermindDL1 wrote:
| This sounds awesome! I hope you post it here!
| munificent wrote:
| "Native UI" can be interpreted to mean "UI written in native
| (i.e compiled to machine) code" or "UI written using the OS's
| native widgets". You are presuming that the only correct
| definition is the latter, but it's pretty clear from context
| that they mean the former.
| BaseballPhysics wrote:
| > but it's pretty clear from context that they mean the
| former
|
| It absolutely was _not_ clear, which is why I checked the
| website and then pointed out the lack of clarity.
|
| At first my thought was "Wow, nice, another UI toolkit that
| uses native widgets, that's good!" But, alas, it was not to
| be.
| jeremyjh wrote:
| Yes, you can argue for another plausible interpretation of
| those two words, but in actual usage "Native UI" has always
| meant the platform's native UI framework.
| Matl wrote:
| A lot of people started to refer to Qt as native around
| Electron's time. The only place where Qt is native as
| such in on a KDE Plasma/LxQt desktop.
| bscphil wrote:
| You're correct, although Qt attempts to do fake native
| widgets on Win / Mac, and given how relatively
| lightweight it is compared to Electron, it's
| understandable how it became a obviously point of
| contrast with the latter, which doesn't even pretend to
| be native. Given a choice between the two I will
| obviously take fake native widgets over nothing.
| omaranto wrote:
| Is it caled Zed because it is inspired by the old Zed text
| editor?
| https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.43801001...
| sdfhdhjdw3 wrote:
| Humble question, I don't mean to sound confrontational, I ask
| of genuine curiosity: Why not contribute to VS Code instead?
|
| For Julia, Atom+Juno was excellent. It was the first time I
| could select+run on a proper IDE (I was coming from
| python+notebook). To me this was revolutionary. Then I
| discovered VS Code, so Atom+Juno stopped making sense. You seem
| to be a very competent developer, so why not just contribute to
| VS Code?
| nathansobo wrote:
| Our goal is to build something substantially better than VS
| Code.
| GordonS wrote:
| What would you say are planned to be the primary selling
| points over VSCode?
| exyi wrote:
| From the other parts of the thread: Performance, maybe
| better collaboration?
| galaxyLogic wrote:
| I think that's a worthy goal. I find it really bad that
| in this age of super-mega CPUs apps still feel not much
| faster than say 20 years ago. The reason I think is
| because like cities apps are built on top of other apps,
| like VSCode on top of Electron.
|
| Secondly when you re-create from scratch you can keep the
| best features and drop the ones we've learned are not so
| useful.
|
| Godspeed!
| GordonS wrote:
| Being honest, that doesn't sound too enticing.
|
| Despite VSCode being an Electron app, I've never had any
| performance issues with it - really, it's a great example
| of how Electron can be done right.
|
| On collaboration, I'm not sure what they might add that
| isn't already covered by GitHub/GitLab/AzDo etc. Again
| being honest, "collaboration" sounds like a weak Open
| Source pitch to VCs. I'd be interested in some details
| though, incase there is something truly novel here.
| gregmac wrote:
| Can you be more specific about this, and what you're
| prioritizing?
|
| Eg: Speed? Different UI layout? Fundamentally different
| design/UX philosophy?
| mmcnl wrote:
| What is your definition of better?
| qbasic_forever wrote:
| I don't think VS code would ever accept a change to native UI
| or switch off of electron, so it seems like a nonstarter for
| someone who wants to experiment with native UI text editors.
|
| VS code is written almost 100% in JS and typescript, it will
| always be a nodejs app through and through without a complete
| rewrite. And even if they wanted to rearchitect VS code all
| of the extension APIs, extensions themselves, etc. would
| demand the existing nodejs runtime.
|
| So long story short... VS code is a good editor if you want
| to contribute to a nodejs and web tech based text editor, but
| not if you want to explore other architectures or ideas.
| cztomsik wrote:
| you don't need node.js/V8 for plugins
|
| there is quickjs and some others, some of them are rust-
| based and all of them can run in wasm host
|
| EDIT: to be honest, I clearly see where you are going with
| this and I agree :)
| mynegation wrote:
| If nothing else, Atom was the birthplace of Electron.js and I
| know it is controversial, but Electron was a boon for the
| rapid development of cross-platform desktop applications. VS
| Code was built - in turn - on Electron.
|
| We need people like nathansobo to try out new ideas and
| directions. I, personally, am very much looking forward to
| their WebAssembly-based extension system and Zed being the
| flagship UI application developed in Rust.
| vlunkr wrote:
| Not the person you're responding to, but it sounds like
| they're going in a different direction with Zed in terms of
| the tech stack, where VSCode is pretty similar to Atom.
| shuntress wrote:
| This actually looks really promising despite fitting snugly
| into the "Show HN: Hey check out my cool unique new project"
| mold.
|
| I know it's not the main point of the DevXConf presentation but
| I _really_ like the look of that multi-buffer feature.
| artursapek wrote:
| >Written in Rust
|
| yes, it seems you have learned a lot lmfao
| ljm wrote:
| How many times do you have to re-invent the text editor?
| lytedev wrote:
| For the same reason people have and use many different tools
| in all sorts of professions.
| input_sh wrote:
| I just wanted to say I really liked your product and despite
| multiple attempts to switch to VS Code (in anticipation of this
| day), I kept returning to Atom. I don't know why, I could never
| get VS Code to feel right to me, while Atom always felt right
| despite many of its quirks I've gotten used to over the years.
|
| Looking forward to its spiritual successor!
| nathansobo wrote:
| Thanks very much!
| pvg wrote:
| Should development ever wind down, you already have the
| advantage of being able to announce it as "Zed's dead, baby"
| instead of clunky corporate euphemisms.
| behnamoh wrote:
| yet another buzzword we hear a lot these days: Zed is
| "lightning fast"... I hear that a lot about Rust projects,
| like Kitty or Alacritty
| nathansobo wrote:
| "Real real fast"
| pvg wrote:
| _I like smoke and lightnin '
|
| Bare metal thunder_
| ossusermivami wrote:
| kitty is python+c++ fyi! (and as blazing as the other
| lightning rust software)
| smolder wrote:
| Lightning fast must be an upgrade from the blazing[ly??]
| fast days. Tangential, but I've been wondering, what comes
| after "web scale" on that axis?
| jl6 wrote:
| In the meantime, zed.dev, baby, zed.dev.
| nsxwolf wrote:
| They should name its engine or one of its components
| "Chopper".
| nathansobo wrote:
| Fabulous point. Always good to have solid contingency plans.
| beliu wrote:
| In case folks are interested, I had a delightful interview
| about a year back with Max Brunsfeld, one of the original Atom
| devs who is now working on Zed:
| https://about.sourcegraph.com/podcast/max-brunsfeld. (YouTube
| link: https://www.youtube.com/watch?v=0Jf8AqaZ7IU)
|
| Very excited about where this new collaborative editor goes!
| folknor wrote:
| Interesting! I just wanted to let you know my perspective,
| which is probably quite unique.
|
| I started using atom pre-1.0, a long, long time ago. I
| immediately jumped to vscode when I realised it existed.
|
| The reason is a bit weird; it's the find-in-files/project
| (c-s-F/Ctrl+Shift+F) sidebar search/replace feature. Compared
| to the Atom (and from what I can see in the youtube talk, zed
| has the same "problem") which opens c-s-F results in the main
| window, vscode opens them in the sidebar and doesn't clutter
| the main view with it.
|
| The reason this is powerful to me is that I code mostly in
| domain-specific, esoteric, private languages that have no API
| documentation, no stdlib or docs, and no online resources to
| learn from. So the only way to learn is by example, or talk to
| someone who knows. Learning by example is usually much faster
| than talking.
|
| So what I do is any new project is just a subfolder in a
| workspace that contains all known code in the language and the
| way I find out how to do something is c-s-F.
|
| When the results cover the main view, or even parts of it
| (which is also possible with atom), it's just way too
| intrusive. The sidebar file list is useless to me at this point
| - where the result comes from is irrelevant. So why not use
| that space?
|
| Also of course the fact that vscodes cross-file search was
| blazingly fast was an upside as well (I believe they used
| ripgrep for that since the start?)
|
| Another thing I want to mention is (and you highlight the
| keyword search in that youtube talk around 18:54) the power of
| the command palette search method that is available in vscode:
| first-letter-matching. I don't know what the proper name of it
| is, but essentially "ps" matches "pub struct" for example.
| Obviously it matches it with a lower score than something that
| starts with "ps", but it's very powerful for matching in the
| command palette.
|
| Thanks for listening.
| mmcnl wrote:
| I think this is powerful to everyone. I use that feature too
| and didn't even realize it was unique to VS Code. VS Code is
| really good in having a lot of features but not cluttering
| the main window.
| theteapot wrote:
| > I code mostly in domain-specific, esoteric, private
| languages, no stdlib or docs, and no online resources to
| learn from.
|
| Jesus, who are you?
| behnamoh wrote:
| Writing DSLs is not uncommon among Lisp developers.
| denysvitali wrote:
| A brainfuck developer?
| tmp_anon_22 wrote:
| Retired? Or in Academia?
| blagie wrote:
| There are also a whole bunch of languages for:
|
| - Describing levels in video games, which are primarily
| data with code mixed in
|
| - Describing transformations of different sorts (e.g. the
| types of languages used in compilers for specifying a
| programming language parser, and then optimizations)
|
| - Defining hardware (analogues to Spice, Verilog, and
| VHDL). Hardware can also include mechanical objects, as
| well more broadly, wetware (e.g. custom bacteria, a la
| Ginko Bioworks)
|
| - Run on custom hardware (e.g. SIMD and MIMD platforms,
| similar to GPGPU)
|
| - Are primarily mathematical (e.g. for describing control
| systems, neural network architectures, etc.)
|
| ... and so on.
|
| Not all of this is a DOD/medical mess. A lot of DSLs are
| REALLY REALLY FUN.
| [deleted]
| cupofpython wrote:
| im guessing a very loyal employee to an enterprise company
| outside of tech - probably logistics
| [deleted]
| generalizations wrote:
| DoD?
| BryanBeshore wrote:
| The name is Den. Snow Den.
| foldor wrote:
| My guess based in my experience would a MUMPS developer for
| someone like Epic or Meditech. That code gives me
| nightmares whenever I see it.
| easrng wrote:
| Still can barely believe MUMPS is real tbh, first saw it
| on TDWTF and I thought it was a joke at first.
| ternaryoperator wrote:
| Coming from today's world, sure. But in 1966, a language
| with a built-in database was a godsend and there were no
| standard language conventions to adopt (C was still
| several years away and only COBOL and Fortran were in
| wide use).
| oneepic wrote:
| What, like $$foo(3,4,@bar,"baz")?
| LoveMortuus wrote:
| Does 'lightning-fast' mean that the application will be light
| on the system or does it mean that it's well optimised but
| still demanding enough that you require a modern computer?
|
| I'm asking because I like to use my laptop Acer Aspire One most
| because of the size and because it the incredibly good feeling
| keyboard. BUT the system is 32-bit and running Intel Atom which
| means that before VSCode moved away from 32-bit I could use it,
| but it would take some time to open and I wouldn't really call
| it writing in real time, if you know what I mean~ :D
|
| But I love the keyboard shortcuts and the multiple cursor
| functionality, which is why I stuck with it for as long as I
| could!
| smcleod wrote:
| Great to see you've dropped Electron!
| jjtheblunt wrote:
| jzzskijj wrote:
| I have to assume no-one in the team saw Pulp Fiction (1994)
| when you ended up picking up the name "Zed"...?
| AtNightWeCode wrote:
| "Mission-critical tools should be hyper-responsive." Did not
| seem to be important with the worlds slowest dev-tool ever,
| Atom. ;)
|
| "Real-time collaboration produces better software." At design
| level, ok. Programming is in most cases not a co-op operation.
| If it is, then you are probably creating solutions while
| writing code which is the best guarantee for bad solutions.
|
| "Conversations should happen close to code." Agree to some
| degree, this is a big flaw with GIT. It is also a flaw with
| many programming langs and tools. Even if I use collaboration
| features in VS and VSC many langs are simply not designed for
| presenting code to people not highly familiar with the specific
| code base. So, an editor may not solve the problem here.
|
| "Your editor should disappear." I mainly code in VS and what I
| can do in VS in 10 mins takes me a couple of hours in VSC. A
| tool should aim to be the default of a problem. The amount of
| time I have seen wasted over the years with people trying to
| master VIM or git from a prompt is just ridiculous.
| ghshephard wrote:
| I don't use Visual Studio, so I'm intrigued as to what VS can
| do in 10 minutes that takes 2+ hours in VSC?
| LocalPCGuy wrote:
| One example could be scaffolding out a CRUD app and DB
| fairly quickly.
|
| Even excluding scaffolding, VS can eliminate a lot of the
| boilerplate that takes time if you need to type it out
| yourself.
|
| Not saying you can't setup VSC to do those kinds of things
| also, but VS is a tools included solution out of the box.
| (I say this as someone who hasn't touched VS in a few years
| now, but used it daily for a few years before that, and who
| generally enjoys using good/fast text editors.)
| merlinran wrote:
| I would argue that boilerplates should be minimized in
| the first place. Regardless how fast it is to generate
| them, reading them over and over again together with the
| code human write is a huge waste of energy.
| polutropos wrote:
| Any screenshots to share?
| nathansobo wrote:
| Here's a demo from a talk a give not too long ago:
|
| https://youtu.be/wXT73bBr83s?list=PL3TSF5whlprXqwYNIM0X8mBzu.
| ..
| scotty79 wrote:
| Please, please, please, make it infinitely pluggable from the
| start. That's the strength of Atom and similar editors. That
| anybody can create a plugin either for something very niche or
| just connect some huge amazing tooling directly to the editor.
|
| If you can make editor in Rust pluggable or scriptable with JS,
| Lua, C#, Python and whatever someone knows and is comfortable
| with you got a winner.
| jeppester wrote:
| In VS Code the collaborative editing (live share) seems like a
| dirty workaround put on top of an architecture not built with
| multiple users in mind.
|
| I use live share all the time because it's the best thing we
| have for pair programming, but I often wish for a better
| solution. We often get disconnected for no reason, editors get
| out of sync, terminal sharing is near useless.
|
| If you can produce something that doesn't feel like a hack,
| then I'm all in!
|
| Features I would love to have:
|
| - Terminal sharing should work like tmux with window size
| "smallest". It's the best solution I've found for having a
| shared terminal.
|
| - Let us join a collaboration session from the terminal: `zed
| [URL]`. No annoying website that takes ages to open, or having
| to open the editor before joining the session.
|
| - Let me start a server on a port and let others join that
| server. I can forward that port if I need to.
|
| - Let me start a headless server on a shared dev env, and let
| me and others connect to collaborate
| tiffanyh wrote:
| Re: Native UI
|
| Is Zed web-based or not? Would it be able to be hosted in the
| browser like the web-based version of Github Codespace (Visual
| Studio Code Online)?
| nathansobo wrote:
| We plan to compile to WebAssembly that writes pixels to a
| WebGL canvas.
| shakow wrote:
| If you will directly write yourself everything to a GL
| canvas anyway, what do you gain by going through a whole
| WebGL dependency & context rather than just using a native
| OpenGL context?
| nathansobo wrote:
| This would only be for the web. Right now we're macOS
| only and target Metal.
| mwcampbell wrote:
| zed sounds like a great project. What are your thoughts on the
| existing Rust GUI frameworks? Naturally the core editor widget
| will need to be custom no matter what, but for the rest of the
| UI, have you considered using one of the Rust GUI frameworks
| already being developed?
| nathansobo wrote:
| When we started on Zed the Rust UI framework space was much
| younger. In absence of a mature solution that met our exact
| needs, the simplest path for us was to build it ourselves.
| We're too far into things now to change at this point.
| mwcampbell wrote:
| Fair enough. Hopefully when you're ready to work on
| accessibility in your UI framework, AccessKit [1] will be
| ready. I'm hoping to have usable Windows and Mac
| implementations by the end of this year.
|
| [1]: https://github.com/AccessKit/accesskit
| zamalek wrote:
| Accessibility is a peeve of mine (for no other reason
| than sympathy). Thanks for your work on this.
| diziet wrote:
| Will it be native Sublime Text fast? Not on electron?
|
| I tried using VScode and Atom. Both were noticeably slow
| compared to sublime text. I can do silly, bad practice things
| like open a 50 meg log file in sublime and search for simple
| regex in the editor. Electron based editors stall and
| potentially crash.
| iamnbutler wrote:
| I may be biased, but at least sublime fast, hopefully much
| faster! Moving to Zed felt like going from a 30fps to 144fps.
|
| You should be able to open stupidly big files and shouldn't
| experience much to any lag. Nathan has a demo he likes to
| give opening one one of those huge json files and searching,
| using multiple cursors, etc. It is pretty cool to watch.
| ghshephard wrote:
| 50 Megabytes? That's _tiny_ I would hope in 2022 that any
| text editor can handle a 50 megabyte file.
|
| I routinely (like every day) open 500 megabyte files in
| SublimeText, and just checked to make sure that it can handle
| 1.5 Gigabyte files without much difficulty (it can).
|
| Admittedly - once we get into the 5+ Gigabyte file size,
| startup times become annoying enough that I usually switch
| over to vim.
|
| So, thank you for bringing this up as an important
| requirement for modern text editors - they should be able to
| open up multi-gigabyte text files without even breathing
| hard.
| Aeolun wrote:
| Hmm, curious how this will compare to Jetbrains' fleet editor.
|
| Of course, they share the problem that I can't yet use either
| :)
| nathansobo wrote:
| We're pure Rust and hopefully faster. But yeah, plenty of
| competition in the space!
| fmntf wrote:
| I work on the linux kernel using CLion and the IDE is still
| fast. I would not be interested in a non-Java IDE for the
| performance.
| exyi wrote:
| Are you using 32-core / 100GB RAM monster machine? I do
| everything on my rather powerful laptop, but Jetbrains
| IDEs are just too much. I can't have more than one
| project open at time, which is limiting. I didn't try
| CLion, only IntelliJ for Scala and Rider for C#/F#, all
| on smallish projects and it will still take 3-6GB of
| memory :|
|
| I'd be interested in even lighter than VSCode IDE ;)
| nwatson wrote:
| I often have several simultaneous PyCharm projects open
| with separate completely introspected and navigable
| virtualenv's with lots of installed libraries, and also
| ongoing DataGrip, and at times CLion or IntelliJ sessions
| ... all the Jetbrains IDEs are performing quite well. At
| times running Docker as well. 32GB Macbook Pro M1.
| 4dregress wrote:
| Yeah I'm doing the same on an 2021 intel Mac, I love jet
| brains stuff!
| [deleted]
| kvark wrote:
| I feel CLion latencies even on a much smaller project.
| Sublime Text is faster, and I hope Zed is near. I guess
| people have different sensitivity for this. It's not
| about time waste, it's just affecting the flow.
| jupp0r wrote:
| I hope it will be much faster. I try JetBrains IDE every
| couple of years and the sheer latency and lack of text
| rendering quality is turning me away every time.
| slightwinder wrote:
| > Written in Rust, custom native UI framework
|
| Interesting. I think a major reason for VS Code's success is
| their usage of web-stack, which is stable, powerful and well
| documented, enabling easy access to higher customizations for
| anyone. It will be interesting to see how much a custom UI can
| emulate this without html&css.
| CJefferson wrote:
| What is the accessibility (for example for blind users) of your
| custom UI framework like?
| giancarlostoro wrote:
| I'm a huge fan of Text Editors, I've made a few basic ones
| myself. Thank you for creating Atom! For ages before Atom was a
| thing I grew fascination with using web servers for front-end
| UI and thereby using HTML / CSS for a local applications UI, I
| had seen this in SlickBeard and a few other usenet applications
| that used a web interface instead of a standard GUI interface
| to render a UI. I also remember a Google program that did this,
| though I can't recall the name. It might sound crazy to some to
| do it this way, but because the web server is localized to your
| system and your browser is usually responsive once open, every
| app I used that worked this way was always highly responsive
| and just worked.
|
| I was dreaming of taking Vibe.d and CodeMirror and making
| something you could install as a daemon on any machine and code
| from anywhere. When Atom came out I was obsessed with it for a
| while, it was a whole other approach from what I was thinking
| of!
|
| Did you ever do a write up on how you came to the thought of
| just taking a browser engine and turning it into your own
| sandbox and what that entailed in the earlier days? That seems
| like a fun story. Because of Atom we got great innovations that
| followed, for example Slack, Discord, VS Code, and the list
| goes on... and on... Heck POSTMAN! Which is probably used or
| has been used by every developer under the sun.
| ravedave5 wrote:
| Please be aware of the second system effect
| https://en.wikipedia.org/wiki/Second-system_effect
| neoneye2 wrote:
| Also implementing undo for a big project is tricky. If the
| user switches to another file, collapses/expands things, runs
| a plugin, auto-formats some code, and then undoes things.
|
| What will undo be like for a collaborative editor?
| zamalek wrote:
| > Just starting our private alpha this week
|
| I'm holding thumbs, I have been massively excited about your
| elevator pitch since your original announcement. Good luck!
| lifeplusplus wrote:
| i hate vscode is written in electron, i always noticed the
| latency, it's good enough but it's annoying. atom was same but
| worse. what I also disliked about atom and sublimetext, is how
| you needed to install 20 extensions to get basic functionality
| and they weren't always compatible, with each other. Vscode
| approach of having most of basic functionality builtin but
| behind flags which can be disabled meant most people had good
| setup from the get go. Vscode to me was like jetbrains but
| faster and lighter. Although in some cases jetbrains was more
| robust.
|
| If there is vscode that was written natively. I'd be so happy.
| Even if there is a new branch of vscode that is 6 months behind
| in features but is built in native it'd be huge for me.
| productceo wrote:
| Wow! End of an era!
| trinsic2 wrote:
| Man this is sad... As a markdown/HTMl writer, I used Atom every
| day... It had great extensions. So It looks like Sublime then..
| Any other Editors for a non-coder that has good (Community)
| extension support like Atom besides Sublime?
| jlkuester7 wrote:
| Friendly reminder that https://vscodium.com/ offers Free/Libre
| open source binaries of VS Code without all the M$ telemetry or
| integrations with proprietary services.
| ehayes wrote:
| Over the past year I've tried a few times to switch from Atom to
| VS Code, but there's always a little thing that brings me back.
| With effort most of the functionality could be reproduced in VSC,
| but the stupid MS typography can't be themed away.
| imbnwa wrote:
| Yeah, overall UX of VSC bothers me next to Atom and I can't
| explain why
| fartcannon wrote:
| So this would be slightly different than embrace, extend and
| extinguish (EEE). This is acquire, substitute and then sunset
| (ASS)
| joshstrange wrote:
| I know a lot of people love vscode but are there any people who
| have tried something like IDEA/WebStorm/PHPStorm/etc that then
| went back to vscode?
|
| I had to help a developer setup deploys to a dev server from
| vscode the other day and I wanted to pull my hair out. I'll admit
| it's at least in part due to not using vscode myself but I was a
| heavy Sublime Text user which is very similar to vscode when it
| comes to how you find/configure plugins.
|
| I understand that vscode is very powerful and infinitely
| extendable but I feel like I shouldn't have needed to try 4-5
| different vscode plugins (all configured via json) before I found
| one that worked and did what I needed.
|
| At least 2 of the top downloaded plugins when searching for
| "SFTP" were read-only/archived on GitHub, the top one had a
| "reloaded" version which was also discontinued from what I could
| tell.
|
| I'm comparing this experience to IDEA which has this built in
| (including support for deploying to multiple servers at the same
| time) and all configurable in the GUI.
|
| Maybe I'm just getting old and cranky but vscode seems to get
| unwieldy very quickly (plugin conflicts, not being able to tell
| what's doing what, writing almost all config in json). The plugin
| ecosystem seems to be much lower quality that I what I see in the
| Intellij product line. I guess I'm just not interested in
| "building my own IDE" and forever tweaking it, I'd much rather
| buy a product that does almost everything I need in a sane way.
| pornel wrote:
| I use Sublime Text, but it has its own issues with Python
| fragility and needing tweaks to plug-in's config files more
| than I'd like, so I'll probably switch to VSCode eventually.
|
| Java IDEs seem to be living in their own world, but for
| everything else VSCode works well thanks to LSP. For example
| rust-analyzer works best with VSCode, and this makes VSCode the
| best Rust IDE.
| Mo3 wrote:
| Same here, was a very happy Sublime Text user for years -
| much faster and less memory intensive than VSCode, but
| recently switched over because of all the tweaking required.
| throw_m239339 wrote:
| For Java dev, VSCode just can't compete with IDEA. For
| JS/Typescript/PHP, VScode is fine, but it doesn't beat PHPStorm
| intellisense and code quality tools.
|
| But one is free, the other is paid...
| forgetfulness wrote:
| It's trite to say "the best tool for the job", but language
| support can vary drastically from one editor platform to
| another.
|
| So I end up using IDEA if I'm working with Scala and Java at a
| job, Emacs if using Clojure, vim for those tasks that are kind
| of like using sed and awk but not quite, and for everything
| else, like Terraform, Python, shell, SQL, there's VS Code.
| reitanqild wrote:
| I use and have used both a lot.
|
| I was about to give up WebStorm the other day, but eventually
| got around it.
|
| Jetbrains products are very good, but they feel a little
| "French" just like Macs: beautiful, but be aware that on some
| models the handbrake is on the same side as the door so you
| might end up tearing up your pants or bruising your thigh until
| you learn to be careful :-/
|
| VS Code by comparison is very straightforward, but not always
| as sophisticated.
|
| Personally I'd use NetBeans for backend and VS Code for
| frontend but because of Kotlin (which is great) I'm stuck with
| IntelliJ anyways.
| bckr wrote:
| > setup deploys to a dev server from vscode
|
| What does this mean? Setting it up so you can deploy through
| GUI?
| joshstrange wrote:
| On save, deploy the file out to a dev server(s) that runs the
| full stack (1 or more server per developer that only they
| use).
| speedgoose wrote:
| It sounds like your development flow is a bit unusual
| nowadays, which could explain why no one bothers to
| maintain such vscode plugin.
| bckr wrote:
| I have to agree. I'd rather open the terminal and do a
| git push or otherwise run a command rather than having
| every save get deployed.
| brundolf wrote:
| Can't stand IDEA if there's a decent VSCode plugin for the
| language I'm working with (which there generally is). It's way
| too sluggish, I avoid it as much as possible
|
| I used it for a year or so around 2015. It was a huge
| improvement over Eclipse, which is what I'd been using since
| this was at a Java shop, but even then I knew it was sluggish.
| I just assumed back then that you couldn't have IDE features
| without sluggishness. Now I know better
|
| (To be clear I have no idea how VSCode's Java experience,
| specifically, compares with IDEA these days; I haven't written
| Java since 2015)
| hombre_fatal wrote:
| > I know a lot of people love vscode but are there any people
| who have tried something like IDEA/WebStorm/PHPStorm/etc that
| then went back to vscode?
|
| Everyone who uses VSCode has surely used an IDE before. It just
| turns out they aren't better in every way, and possibly not in
| the ways that matter.
|
| VSCode plug-ins just have more eyeballs and work done on them
| for various ecosystems, for example. Especially for less common
| languages and features.
| indymike wrote:
| > Everyone who uses VSCode has surely used an IDE before. It
| just turns out they aren't better in every way, and possibly
| not in the ways that matter.
|
| Almost every junior I hire has only used Atom, Sublime or VS
| Code, especially JavaScript developers.
|
| >VSCode plug-ins just have more eyeballs and work done on
| them for various ecosystems, for example. Especially for less
| common languages and features.
|
| The reason to switch to an IDE from something more flexible
| like VSCode or Emacs is the amount of time spent keeping the
| editor working.
| tristan957 wrote:
| VSCode has been working just fine for me for the last 5
| years. Not sure what you mean by "keeping it working." I
| program in C/C++, Rust, Python, Go, TypeScript, JavaScript,
| and Java. Never had a problem that made me bang my head
| against the desk.
| IncRnd wrote:
| > The reason to switch to an IDE from something more
| flexible like VSCode or Emacs is the amount of time spent
| keeping the editor working.
|
| An editor will generally not stop working like a car
| without oil. But, IDEs may stop working due to more complex
| configurations and disparate use cases.
| joshstrange wrote:
| > Everyone who uses VSCode has surely used an IDE before.
|
| I would expect the opposite to be true. I could be wrong but
| it seems like the free editor that's mentioned in lots of
| tutorials would be the one newer developers gravitate to over
| a paid tool like IDEA.
| likortera wrote:
| I've tried too many times already to use the Jetbrains IDEs,
| because I know they're great, specially about the IntelliSense
| stuff, autocompletion, suggestions, etc.
|
| But I just can't. My fingers are just too used to vscode, and I
| can do everything I need to. I feel like vscode is better at
| everything, and faster, except for the IntelliSense stuff. But
| lately I've tried GitHub Copilot and that just compensates it
| sooooo much, to the point I think it is even better than IDEA
| at suggesting stuff.
|
| Also, working mostly with JavaScript and Typescript makes the
| difference go away (for me at least) as it is damn good at it.
|
| Being free and open source also is a big plus for using it. And
| I love also how easy it is to configure... just a JSON with
| autocompletion for any setting you want to tweak. So much
| easier than having to mess with a ton of tabs and sections and
| search for settings, etc, etc.
|
| But, if your language is not well supported in vscode, I agree
| Jetbrain's IDES are great and probably the best option out
| there. Specially IntelliJ if you're doing Java/Kotlin etc...
| rimunroe wrote:
| Does VS Code support more refactoring and code generation
| now? I last used it heavily over a year ago, and at the time
| it seemed like anything beyond moving files and renaming
| things wasn't really doable. Meanwhile, in JetBrains's
| software I can extract and inline variables and functions,
| change signatures, split things out into other files, and
| more. I think I tried a plugin or two which were supposed to
| handle those things, but they either just didn't work at all
| or weren't reliable.
| aniforprez wrote:
| Depends on the language LSP. From my experience, it works
| VERY well for JS, reasonably well for Go and not that well
| for python. Python allows you to refactor variables if it
| knows the scope of it but won't work if you use star
| imports and moving files doesn't work at all
| brundolf wrote:
| It all depends on the language plugin. rust-analyzer can do
| a lot of this stuff, I haven't seen much of it for
| TypeScript (though you tend not to need it as much in more
| flexible languages), not sure about other languages
| joshstrange wrote:
| Muscle memory is a powerful motivator for sure. I was
| configuring vscode locally on my box so I could then send
| instructions to this other developer and my hotkeys not
| working was enraging. I use GitHub Copilot on IDEA and have
| quite enjoyed it as well.
|
| It's funny how we have such opposite feelings on config (you
| enjoying the json config and me preferring UI). I have
| nothing against vscode and I'm glad it exists, likewise I've
| very glad IDEA/Intellij exists for my own uses. Thanks for
| the feedback.
| csours wrote:
| I use IDEA and VS Code and Notepad++ and ...
|
| I'm kind of surprised you did a deploy from VS Code. I would
| have assumed there was another tool for that. I do most of my
| git and ssh/scp stuff from the command line because I'm never
| quite sure what the tool will try to do to "help me out"
| joshstrange wrote:
| For myself it's all about reducing the delay between "writing
| code" and "seeing the results". Dropping down to scp or run a
| script to deploy files seems like an unnecessary delay/break
| in my development process that I don't like adding in.
|
| If you can develop 100% locally this isn't an issue but we
| can't (or haven't taken the time to do so). Think of the dev
| server as just a VM running locally and it might make more
| sense.
| mynameisvlad wrote:
| Why not pop out an integrated terminal and execute commands
| there? It's still within the editor and you could have a
| shell script that runs to deploy.
| joshstrange wrote:
| It all comes back to that "development cycle" and wanting
| to make that as short as possible. What you suggest is
| absolutely fine, it's just my personal preference (and
| something that I've seen help other devs) to make the
| "write code"->"see results" as tight as possible.
|
| If you add any delays, any potential chance of forgetting
| a step, etc then it breaks my programming flow which can
| kill my productivity.
| mynameisvlad wrote:
| But aren't you executing a task either way? Either
| running a script, or executing a command through
| Ctrl/Cmd+Shift+P, you have to do _something_ to deploy.
|
| I mean, hell, just set up gulp/grunt/another task runner
| to watch your files and run scp if you want it
| continuously running? Why involve your IDE at all at that
| point?
| joshstrange wrote:
| Ahh, I see the disconnect.
|
| I set it up to deploy on save of the file or when the
| editor loses focus (when it auto-saves). So while you are
| correct I have to do "something" to make it deploy that
| "something" is either a hot key or me clicking out of my
| editor into the browser to refresh the page (talking
| about PHP here, all my frontend Vue work I do locally
| with a watch script to rebuild on changes).
| mynameisvlad wrote:
| Fair, that's more or less equivalent to a task runner
| watching the files. I'd recommend that approach only
| because it decouples the action from the editor. As long
| as the file changes, it executes.
| mixmastamyk wrote:
| I do the same with inotify tools and an alias or
| makefile. A simple editor like Geany can save on focus
| change.
| bbkane wrote:
| I generally make a "run.sh" script or Makefile to build
| and deploy. Then it's just a few tappity taps in the
| terminal to run it again. Still not as good as a "play"
| button, but easier to set up in many cases.
| fendy3002 wrote:
| Remote ssh to dev server and develop directly there using
| vscode man.
| qsort wrote:
| I use both pycharm professional and vscode; vscode's remote is
| much better and it makes it way easier to work on projects that
| use multiple programming languages.
|
| Also the default editor of the IDEA family is just unbearable
| (but there's the vim plugin for that, I guess), while Monaco is
| fine.
|
| The only area where vscode is downright embarassing is
| interfacing with databases. In pycharm I can have a complete
| view of the database I'm connected to, run queries, get
| warnings and errors from inline SQL, and so on. Vscode has...
| strings?
|
| If the remote capabilities get better, though, I'd admittedly
| have no reason to stay in the vscode camp.
| bastardoperator wrote:
| I purchased pycharm, couldn't stand it, logged bugs that are
| still open from over 5 years ago coupled with the fact I didn't
| see any immediate benefits coming from vim and vscode. I would
| never deploy from an ide, and I'm willing to make a small
| investment when it comes to my tools and productivity.
|
| Also, as of lately, copilot is saving me an insane amount of
| time especially when it comes to boilerplate and testing.
| lmarcos wrote:
| I cannot stand the "dancing" sidebar in VS Code. It's used for
| showing the directory tree, search results, plugins, etc. I
| like Jetbrain IDEs (at least on my machine they load and feel
| fast).
| mikewhy wrote:
| FYI you can drag anything from the sidebar to the bottom
| pane. It's not much, but can help with the overloaded
| sidebar.
| TameAntelope wrote:
| I come from an era where the more fully featured your IDE, the
| less likely you were to truly understand what was going on
| under the hood.
|
| I strongly recommend everyone spend their first ~5 years coding
| in vim or some other basic text editor (preferably through the
| terminal), before leaning on an IDE to solve their problems for
| them.
|
| That said, VSCode is now my go-to IDE, and I haven't opened
| WebStorm in probably ~6 months. It's lighter weight than the
| IDEA suite of IDEs, and gives me ~80% of the functionality, so
| it's been a pretty good tradeoff.
| kllrnohj wrote:
| There are languages, like C#, Java, and Kotlin, where the
| language design basically assumes an IDE is being used. It's
| just not practical or useful to deal with imports and their
| structure. Sure you can look them up on javadocs and
| copy/paste the import path. But at that point why not just
| use an ide? Why learn a skill you'll basically never use or
| need?
| TameAntelope wrote:
| I wrote Java for multiple years in vim with no extensions
| installed.
| 999900000999 wrote:
| Would you even do that with C# ?
|
| I actually dislike computer science classes which won't let
| me just use an IDE.
|
| No one can memorize the .net 7 API
| quickthrower2 wrote:
| .NET Core and beyond yes. For older .NET you really need
| classic VS or you will probably have a bad time.
| heartbreak wrote:
| VS Code and Vim have intelligent autocomplete for C#,
| although Vim requires significantly more configuration to
| get it working.
| bbkane wrote:
| Honestly, I don't think VSCode hides much of what's going on
| from you. Generally I use it to edit code and then run "go
| run ." on the side.
| Starlevel001 wrote:
| I use IntelliJ for the bulk of my programming (which is nearly
| all Kotlin/Java) and begrudgingly switch to VSCode for other
| languages (i.e. Rust). It's hard going from something that
| seems to magically understand my code to an editor where
| everything, even supposedly core functionality, is a second-
| class citizen.
| andjd wrote:
| I have used both, and use both working daily. If I could get
| away with doing everything in VSCode, I would. Part of this is
| how the community treats tools. VSCode is an editor, with some
| plugin support that lets it work as a bit of an IDE. But these
| are almost always optional. Code ecosystems and communities
| built around an IDE tend to only support working in that IDE,
| so there's typically only one way to do things, good or bad.
| rychco wrote:
| I personally use CLion for all my C/C++ work, even preferring
| it over Visual Studio proper. It handles the environments,
| builds, build systems, etc for me a so I can focus on
| programming. VSCode is what I use for everything else (mostly
| Python, Golang, Web stuff) when I don't need the IDE overhead.
| tomca32 wrote:
| I switch back and forth between IntelliJ products and VSCode.
|
| As a pure editor I prefer VSCode. It's fast and has a great
| plugin ecosystem. Another great feature is that it's config is
| just a JSON file that I can put into git and push it to my
| dotfiles repo making it easy to share config on all of my
| machines.
|
| However, there's just some functionality in IntelliJ that I
| miss in VSCode like running tests. Of course there are plugins
| but they are all clunky and don't give you the great UX that
| IntelliJ does. I want the IDE to figure out where all the tests
| are and give me an easy way to run a single
| test/file/suite/feature. IMHO this is the killer IntelliJ
| feature for me.
| brundolf wrote:
| Depending on the language (I've seen it in Rust and Deno),
| VSCode has inline buttons that appear over individual tests
| to run them
| dingleberry420 wrote:
| I'm cautiously optimistic for
| https://www.jetbrains.com/fleet/
| joshstrange wrote:
| I just got access to this the other day and I'm excited to
| try it out!
| nop_slide wrote:
| My initial experience loading a python project was
| disappointing. I don't know if I didn't configure it
| right but auto complete and syntax highlighting didn't
| seem to work properly.
| aniforprez wrote:
| Isn't it just a frontend with the actual language servers
| and the whole IDE back end running somewhere else? At
| least that's what I thought it was from their
| announcement. Sort of like GitHub codespaces
| tetraca wrote:
| > I know a lot of people love vscode but are there any people
| who have tried something like IDEA/WebStorm/PHPStorm/etc that
| then went back to vscode?
|
| I know a few people like this. More or less, they all got
| burned by some technical issue that made IDEA unusable for them
| one day, so they quickly cobbled together a bunch of extensions
| in VS Code just to get their work done and stayed.
| colordrops wrote:
| Totally agree, if I'm gonna put effort into building my IDE
| it's gonna be vim or emacs. I use nvim most of the time and
| intellij on occasion for debugging.
| johnchristopher wrote:
| Oh, I do the same. Coding in vim and debugging in vscode. The
| GUI and mouse support is a better experience.
| stefanos82 wrote:
| lol, I jump between Vim and NetBeans almost on a daily basis!
| So it seems I'm not the only one who follows a similar
| pattern after all.
| vultour wrote:
| Ah, a fellow full-time vim user. There are dozens of us!
| shp0ngle wrote:
| I went from GoLand (their go thing) back to vscode.
|
| With gopls, vscode is MUCH faster than goland, especially on
| big repos, and I don't need to watch the dreaded "Indexing..."
| all the time.
|
| It misses some features, but honestly it's so much snappier, so
| that wins for me.
| saghm wrote:
| > I know a lot of people love vscode but are there any people
| who have tried something like IDEA/WebStorm/PHPStorm/etc that
| then went back to vscode?
|
| Yep, I've tried Intellij several times over the past 5-6 years,
| but I've never really had an experience I liked. It's
| interesting that you mention SFTP and remote server deploys as
| a pain point for you in VS Code, because I've actually had a
| huge amount of frustration trying to do development over SSH in
| Intellij.. As of Intellij 2021 edition, I was completely unable
| to get ssh working from my work laptop to an EC2 instance; it
| could not parse my `~/.ssh/config`, and manually putting in the
| username, hostname, path to the private key, and even port 22
| (because it literally required putting the port manually rather
| than defaulting to 22 unless stated otherwise), it would just
| say it failed to connect. The 2022 version has a "remote ssh"
| beta feature which also required manually putting in info that
| I felt like it should just be able to parse from my ssh config
| file, but it did connect and work for a week or two. One day it
| randomly started disconnecting a few seconds into loading a
| file continuously, which made it impossible to even scroll down
| into the file before it just zoomed me back up to the top. I
| gave up on it and just decided to stick with VS code for
| everything rather than try to get Intellij to work for the
| small amount of Java code I occasionally have to write.
|
| Setting up ssh development with VS Code, on the other hand, was
| a breeze. The first plugin that came up when I searched "ssh"
| was Microsoft's own for ssh development, and running the
| command to connect to a server after installing it popped up
| with a list of my servers parsed from my ~/.ssh/config, which I
| could just select and it would connect (or prompt for a
| password if the ssh key required one). From there, I could
| easily open any project on my remote server, and VS Code even
| was able to detect which plugins I had installed for use with
| the project needed to be installed server-side rather than
| locally (e.g. the `rust-analyzer` plugin was installed remotely
| since it needed to run the daemon on the machine where the code
| existed). When I close my VS code window, shut down my laptop,
| and then the next day boot it up and open VS code, it still has
| the same files opened to the exact same spot (compared to
| Intellij's "scroll to the top of a file on connection" I
| mentioned before). I'm sure there are ways to get Intellij to
| work like I'd want, and I'm by no means a fan of Microsoft in
| general (I avoid Windows whenever possible and overall have a
| pretty negative opinion of them), but VS Code just absolutely
| nails the UX I want in an editor without needing that much
| custom configuration compared to what I've tried in the past
| with emacs/vim.
| burlesona wrote:
| It's just the NPM problem. The barrier to entry being low means
| the ecosystem is gargantuan which means there's tons of bike
| shedding duplication and lots and lots of abandonware. So it's
| good that you have tons of options, but bad that curation is
| needed and tailoring your environment takes a lot of work.
| [deleted]
| goodoldneon wrote:
| You're deploying via VS Code? If so, that's a weird pattern.
|
| I've been using VS Code for years to write
| JavaScript/TypeScript, Python, Go, Terraform, and CSS. My
| settings file is 60 lines, 42 of which are "for file extension
| X use autoformatter Y" configs.
|
| When I first switched to VS Code I was frustrated trying to
| make it conform to random expectations I had. Eventually I
| learned that it's easier to embrace VS Code's defaults for 99%
| of things. I just want an IDE that works well (nearly) out-of-
| the-box and VS Code gives me that
| joshstrange wrote:
| > You're deploying via VS Code? If so, that's a weird
| pattern.
|
| I don't think it's a weird pattern, maybe a slightly legacy
| one but not out of the ordinary. I've seen this pattern used
| at multiple places (not implement by me). It makes sense if
| you have special use-cases where you need to use physical
| hardware and/or a local stack is too heavy or complicated to
| run.
| presentation wrote:
| Though why does it need to be in your editor vs some
| command line tools or something else?
| danuker wrote:
| So you can deploy at a moment's notice. Why run a command
| instead of hitting a key combo? Or even deploy as soon as
| tests pass?
|
| Software should allow that. Especially software for
| writing other software.
| roflyear wrote:
| Yeah almost an anti pattern.
| bastardoperator wrote:
| No almost about it, it's an anti-pattern and I personally
| would consider it a "worst practice". If you're deploying
| from an IDE it means you lack visibility, feedback, and
| automation fundamentals. What I do like is developer
| ownership and being able to see a change all the way
| through to production but having a system of record without
| manual intervention is always preferred.
| joshstrange wrote:
| It's always so interesting to see people who have no
| concept of your stack/problem-space speak so confidently
| about what you must be doing wrong.
|
| I don't know if you've just chosen to assume the worst or
| don't care enough to think about it for more than a
| second but I've been very clear in all my comments that
| these are developer-specific machines we are deploying
| to. It's literally no different from running VMs on your
| local machine. There is full visibility and feedback, we
| aren't deploying to Prod or even QA, this is development
| where each developer has 2 or more boxes owned by them
| and only them. We also are working with specific custom
| hardware that our code runs on which is one reason we
| can't easily do this locally.
|
| To jump in and call that "worst practice" is just lazy
| and condescending. On top of that, it's completely wrong.
| datalopers wrote:
| https://code.visualstudio.com/docs/remote/remote-overview
|
| far better and faster than sftp
| joshstrange wrote:
| I looked into that plugin but we don't run any special
| daemon/server for editing on our servers (nor do we want to).
| datalopers wrote:
| It's utterly life-changing instead of editing locally and
| using scp/sftp/unison to sync to the server. The "special
| daemon" is entirely transparent, the only requirement is
| ssh.
|
| We're also talking about a dev box here, are we not?
| dingleberry420 wrote:
| Maybe don't edit on a server. Have you heard of git?
| joshstrange wrote:
| There is no need to act like this.
|
| Of course I've heard of git and we use it, we just don't
| use local (on the computer we develop on) dev
| environments, we have a mix of developer-specific VMs and
| local physical hardware due to the nature of our
| business.
| heartbreak wrote:
| I'd write the SFTP stuff as a script and invoke it as
| needed via a VS Code task.
|
| I have a few workflow-type things like this that I
| normally do via the CLI, but now I've added them as tasks
| to VS Code for convenience. I can also create the task at
| the project level and check in the JSON config so that
| teammates can use those same tasks.
| seabrookmx wrote:
| +1 for remote ssh. If you can SFTP to the box you can use
| this feature.
|
| The only possible wrinkle is the developer box needs the
| build toolchain. If you're writing python, your remote
| box obviously already has it to run your app. But if
| you're writing Rust or golang, it's very possible the
| remote machine doesn't have the compilers.
| slumber86 wrote:
| Super sad, atom's column editing still rocks. are there
| alternatives for vsCode?
| josephcsible wrote:
| I hope that a new editor gets first-class Agda support so that
| Emacs won't be your only choice for it once Atom is gone.
| curiousmindz wrote:
| I think the writing was on the wall for a long time.
|
| Since it is only happening in 6 months, I wonder if the community
| will try to transition/fork it.
|
| Do you know if there is still enough interest?
| franciscop wrote:
| I don't think so, even if I use Atom as my primary editor
| there's a bunch of other great open source ones and even some
| non-OSS, and migration is trivial, so there's likely no need.
| db39 wrote:
| I was a big fan of Atom for years. And one thing I wish VS Code
| could have is the Git UI. It always just clicked better for me.
| samstave wrote:
| Nothing make me more happy than programmer nerds bitching on HN
| chad_strategic wrote:
| I will admit that I'm biased, I hate to use Microsoft products. I
| hate Bill Gates and I hate Microsoft.
|
| I will not be switching to VsCode just on principal. Yes, I'm
| still using Github, so I guess I'm a walking contradiction.
|
| I also understand the economics of this situation why keep Vscode
| and atom IDE can't co exist, i'm surprised it took so long.
|
| This is the second software application that Microsoft has
| ruined, remember the incredibly awesome wunderlist?
| PascLeRasc wrote:
| 3rd actually, Sunrise was a fantastic calendar app. Microsoft
| is a blight on the world.
| chad_strategic wrote:
| Thanks!
|
| Sometimes it feels like I live all alone with my hate for
| Microsoft/Gates, but I'm glad I'm not alone.
| hbn wrote:
| Really?
|
| It's hard to find anyone who'd say they overall like
| Microsoft as a company. VS Code is one of the very few
| things Microsoft has made that people actually like.
|
| I recall reading a comment here recently that they've
| actually create an entirely new generation of children who
| hate them by recent changes to Minecraft. Supposedly they
| forced everyone to migrate their accounts to Microsoft
| accounts, and in the process wiped a bunch of save files.
|
| Microsoft happens to every generation at some point!
| Doctor_Fegg wrote:
| "Sunsetting" an open source project seems... unfitting? Hand it
| off to the community, look for new maintainers, donate it to the
| Apache Retirement Home for Veteran Projects, sure.
|
| But saying that you've decided to "sunset" or "archive" it,
| telling users to plan for their migration, seems counter to the
| notion that open source software forms part of a commons -
| something that Github, of all companies, should understand.
| travisgriggs wrote:
| I actually prefer what they're doing. Consider most open source
| projects. Our involvement with them goes something like:
|
| 1. I need feature X
|
| 2. I find library WeLoveX
|
| 3. Is WeLoveX a good investment for my larger product?
|
| 4. Ambiguity happens here
|
| The ambiguity happens because I have one prominent indicator:
| release activity. If it's changing lots, does that mean it's
| active and a solid foundation? Or does it mean it's actually
| probably not quite ready for prime time yet and hasn't found
| stability? On the flip, if there's very little release
| activity, does that mean it's dead, the developers have moved
| on and maybe there's something better out there? Or does it
| mean it just does its job really really well and doesn't need a
| constant stream of tweaks?
|
| It's nice to have a general statement of disposition towards
| the product by the original authors.
| dustinmoris wrote:
| > something that Github, of all companies, should understand
|
| It's not GitHub anymore though. It's Microsoft and Microsoft
| must advance the Visual Studio brand.
| cedilla wrote:
| I agree in principle, but I find it hard to imagine that
| there's enough interest to find someone who is willing to
| maintain the software and the package registry.
|
| Speaking of packages - of the six featured packages I get
| offered on atom.io, only one had a release in the last two
| years, and half have been unchanged for half a decade. Atom's
| already dead.
| mauvehaus wrote:
| A lack of releases could mean dead, but it could also mean
| _finished_. As in, complete: not in need of more features,
| and having no bugs of sufficient severity to bother fixing.
|
| Finished is a state more software should aspire to reach.
| Sadly, with the advent of connectivity in everything, it's
| getting rare for even firmware to be finished.
| dingleberry420 wrote:
| Sadly this is not the case for Atom. Many packages are just
| broken, half baked or missing essential features that their
| vscode counterparts do have.
| sneak wrote:
| Microsoft has never understood open source. This is why they
| bought GitHub and npm, and paid Docker to make it work on
| Windows, and why GitHub and the most important parts of VS Code
| are proprietary software.
|
| They use open source as a marketing buzzword, not as a
| philosophy, and it shows.
|
| I think perhaps TypeScript is the only counterexample.
| oaiey wrote:
| I think they understand open source (and show it by many
| projects) but like you said, it is not their core philosophy.
|
| They are a proprietary software and cloud vendor super house.
| They are very successful like that. Open Source is 3-4 level
| down to their main strategy.
| trasz wrote:
| It's not an open source project - it never was, it's
| commercial, corporate project releasing code licensed as Open
| Source.
| Beltalowda wrote:
| "It's not open source, it's code licensed as open source".
| Hmkay... I find it impressive how concisely you're
| contradicting yourself in that sentence.
| trasz wrote:
| The project is not open source. The code it releases is
| open source. There's no contradiction - it's perfectly
| normal for a company to release their code under an open
| license; Chromium is another example of this. It's
| technically open, but for almost every practical purpose it
| could be closed and it would make no difference.
| Beltalowda wrote:
| What you're trying to say is "I don't like the way it's
| run". Okay, fine. That doesn't make it "not open source".
|
| I have projects where I don't accept patches. "It works
| for me" and I just don't feel like reviewing patches. Is
| that not "open source" in spite of being MIT licenced?
|
| "I can do with the code what I want" is the entire _and
| only_ point of Open Source and Free Software, something
| Stallman and many others have been pretty clear about
| over the years.
| winwhiz wrote:
| All of the id Software code was release to open source
| essentially sunsett'ed. That was never a problem.
| mumblemumble wrote:
| The code isn't being sunsetted, and anyone who wants to take it
| and keep working on it is free to do so.
|
| But winding down the project is still a major event, and I
| think that it is appropriate to call that sunsetting. The
| existing project organization will go away. The team will
| presumably dissolve, with any people being paid to work on it
| going on to other things. I've seen this happen enough times to
| know that it is, indeed, an end of sorts. "The community" is
| almost never large and organized enough to keep a project like
| this vital. At best, they can only slow its descent into
| obscurity.
| MatthiasPortzel wrote:
| There had been at least one attempt to fork and revive Atom
| since, as the post mentions, Atom hasn't seen feature
| additions in many years.
|
| The problem, as I understand it, is that Atom's relationship
| with electron makes it very difficult to work on the core of
| the editor. Namely, while VS Code is downstream from
| Electron, and can get feature benefits just by updating their
| Electron version, Atom is upstream from Electron, and new
| Electron features needed to be more manually integrated.
| xbar wrote:
| Precisely.
|
| This is a responsible way to handle the ceasing of
| maintenance while allowing any and all interested members of
| the Atom community to fork and maintain versions.
|
| I have a much more optimistic view of development communities
| than you do, and I expect to see Atom endure in some forms.
| frostwarrior wrote:
| I agree.
|
| Correct me if I'm wrong, but most projects started by some
| form of organization end up being dead after handing them off
| to the community. That is, unless they make their code from
| the ground up to be as most readable and modular as possible.
|
| I remember many projects made by Sun Microsystems that just
| died when Oracle took over, even if the code is still there.
| jlkuester7 wrote:
| The history of Zulip is one of my favorite counter-examples
| to this trend. They have seen great growth and success
| since spinning off from Dropbox!
|
| https://zulip.com/history/
| abraae wrote:
| Not really a counterexample as zulip started life
| *outside* dropbox.
| DonHopkins wrote:
| There are some things worse than death, like what MySQL
| experienced: being turned into a zombie designed to eat the
| brains and infect people who used to use it when it was
| truly free, all in the name of tricking people into
| switching to Oracle's expensive SQL server.
| 5e92cb50239222b wrote:
| What? MySQL continues to work just fine. 8.0 (which was
| admittedly released two years ago) was the biggest
| release in ages in terms of new features and removal of
| things that should have been removed decades ago. Then
| there's MariaDB, which is named differently purely for
| copyright reasons and could be considered the 'real'
| MySQL (since its dev team are Monty and friends). I don't
| think MySQL came out of Sun's disintegration badly at
| all.
|
| To be more precise: 8.0 finally has proper utf-8 out of
| the box, support for complex replication topologies
| (including multi-master), window functions, CTEs, etc.
| aseipp wrote:
| MySQL has been and continues to be a major success for
| Oracle, and in 8.0+ and beyond the feature set,
| correctness, and performance have improved substantially;
| MySQL continues to evolve and currently is in a good
| spot. It is even more attractive in modern times thanks
| to systems like Vitess, which add major features (online
| schema change, excellent horizontal scaling) that give
| alternatives a run for their money. What are you even
| talking about?
| DonHopkins wrote:
| Then explain MariaDB?
|
| https://www2.computerworld.com.au/article/457551/dead_dat
| aba...
|
| >Dead database walking: MySQL's creator on why the future
| belongs to MariaDB
|
| >MySQL's creator, Michael "Monty" Widenius, is scathing
| on database's future with Oracle
|
| >It's fair to say that MySQL creator Michael "Monty"
| Widenius is not a fan of Oracle. When the company
| announced in April 2009 that it was purchasing Sun,
| Widenius saw a bleak future ahead for the (still) wildly
| popular open source database, which Sun had snapped up in
| 2008.
|
| >The day the Sun purchase was announced, Widenius
| responded in the tried and true open source fashion -- he
| forked MySQL, launching MariaDB, and took a swathe of
| MySQL developers with him.
|
| >"Many of the original MySQL core developers, including
| me, didn't believe that Oracle would be a good owner of
| MySQL and we wanted to ensure that the MySQL code base
| would be free forever," Widenius explains.
|
| >Some of the new code by Oracle is surprisingly good, but
| unfortunately the quality varies and a notable part needs
| to be rewritten before we can include it in MariaDB
|
| >Widenius and a number of other MySQL developers started
| a company, Monty Program Ab "to provide a home both for
| MariaDB -- the new MySQL -- and for all MySQL core
| developers".
|
| >"Monty Program Ab is owned by the employees and uses the
| 'hacking business model' as a way to drive the company,"
| Widenius says.
|
| >Although MySQL is still widely used -- Db-engines.com
| ranks it as the third most popular RDBMS after Oracle and
| Microsoft SQL Server, compared to MariaDB coming in at
| #35 -- Widenius still believes the database has a bleak
| future under Oracle's stewardship.
|
| >Oracle's treatment of MySQL and its community since its
| purchase of Sun has proved Widenius' original fears
| correct, the developer says. Not mincing words, Widenius
| says that Oracle has made it clear "that they have no
| love for open source, working with the community, or
| MySQL in general".
|
| >Widenius cites as examples of Oracle's disregard for
| open source principles the September 2011 announcement of
| commercial extensions to MySQL, the bugs database not
| being public any more, and a lack of test cases for new
| code in MySQL 5.5 and 5.6.
|
| >Widenius is also scathing of the quality of Oracle's
| MySQL development efforts. "Some of the new code by
| Oracle is surprisingly good, but unfortunately the
| quality varies and a notable part needs to be rewritten
| before we can include it in MariaDB," he says.
|
| >He also says that security issues are not addressed
| quickly enough.
|
| >"Instead of fixing bugs, Oracle is removing features,"
| Widenius says.
|
| >"The MySQL documentation was never made open source,
| even [though] it was promised in the MySQL conference in
| April 2009," he adds.
|
| >"Flagship features promised for MySQL 6.0 have never
| been released, even if they were fully developed and
| ready to be released," he says, referring to online
| backup for all storage engines and foreign keys for all
| storage engines.
|
| >"Most of the original MySQL developers have left Oracle.
| Without people that can understand and explain the code
| it's almost impossible for Oracle to develop MySQL
| further even if they wanted to."
|
| >As further evidence of disdain for MySQL users, Widenius
| cites what he describes as "sharp" increases in licence
| and support fees, a lack of an open roadmap and no way
| for the community to participate in the database's
| development.
|
| >"Why is the price for a MySQL OEM license higher than
| for Oracle Express?" Widenius asks.
|
| [...]
| hatware wrote:
| GitHub has been sh*tting the bed left and right. I audibly
| laughed when I saw this article.
|
| I don't know if it started when MS bought them, but it's when I
| think the decline became very apparent.
| thaway2839 wrote:
| Most people using Atom or any other open source project, would
| likely have based their decision at least partly on the
| organization backing the project, especially in a professional
| setting.
|
| For the most part, when a different organization picks up the
| development of the project (if one does) it's a completely new
| project at this point (there are exceptions, such as a backing
| organization continuing to back the project, but deciding that
| it's better supported by an independent trust, and therefore
| building a transition plan for that).
|
| The best example of this is looking at any Apache supported
| project today. There are very few projects that were handed
| over to the Apache foundation that people would want to
| continue using in their post Apache handover date, even if they
| were amongst the lucky few that still have active development
| (OpenOffice, for example).
|
| Sunsetting is absolutely the right term/approach to use.
| seaman1921 wrote:
| just fork it, no one is stopping ;)
| [deleted]
| civilized wrote:
| GitHub is owned by Microsoft, the company that invented
| "Embrace, Extend, Extinguish".
|
| We should be counting down the days till they sunset VS Code to
| focus on VS Code "Pro".
| naikrovek wrote:
| Like when they sunset the closed-source .net framework and
| created the open source .net core?
|
| Or when they sunset the closed-source PowerShell and created
| the open-source PowerShell Core?
|
| Like those?
| tediousdemise wrote:
| When this inevitably happens to VSCode, I'm sure we'll all
| flock to Sublime Text in droves (or some hip new editor on
| the block).
|
| Contingency planning for this could be a small but wise time
| investment for dependent teams. VSCode could very well go the
| way of the Do... Docker.
| IncRnd wrote:
| > Contingency planning for this could be a small but wise
| time investment for dependent teams.
|
| I doubt that switching an editor requires a disaster-
| recovery plan.
| leakbang wrote:
| Modern tech companies love to look busy and find the most
| perplexing solutions for the most basic problems.
|
| I guess they have lots of "solutions" to "design and
| implement".
| pineconewarrior wrote:
| I am sticking to my Intellij products for this very reason.
| They work great and the motives of the company are
| straightforward.
| colordrops wrote:
| Same, but nvim
| edgyquant wrote:
| Why would this happen to VsCode? VSCode is a proprietary
| form of Atom is not? It's hugely successful Microsoft would
| never do such a thing.
| mumblemumble wrote:
| Sort of?
|
| They maintain a trademark on the name Visual Studio Code
| and some other bits. And it is maintained by a Microsoft
| team.
|
| But the code itself is MIT licensed. You can build it
| yourself. I have. There are one or two forks of it out
| there.
| IncRnd wrote:
| The codebases of VS Code and Atom are unrelated to each
| other.
| edgyquant wrote:
| Indeed. At least I'm not the first person to make this
| mistake
|
| https://news.ycombinator.com/item?id=9872976
|
| https://thenextweb.com/news/microsofts-cross-platform-
| visual...
|
| https://news.ycombinator.com/item?id=17221917
| SketchySeaBeast wrote:
| I don't know why Microsoft would do that - VSCode is HUGELY
| popular and at the forefront of Microsoft "I'm cool now
| guys!" 'open-source' movement.
| jrochkind1 wrote:
| While any software can be cancelled, I'd say Atom is being
| cancelled _because_ of investment in VS Code (both
| currently owned by MS), I don 't see any reason to think
| it's "inevitable" that VSCode will be cancelled, except in
| the sense that eventually everyone dies and the earth falls
| into the sun.
| llllllllllll9 wrote:
| :)
| serf wrote:
| > When this inevitably happens to VSCode, I'm sure we'll
| all flock to Sublime Text in droves (or some hip new editor
| on the block).
|
| the normalization of this behavior within the industry
| makes using emacs or vim even more satisfying.
|
| it's nice to having an unchanging cement foundation to
| stand upon once-in-awhile.
| taude wrote:
| Sounds like premature optimization.
|
| I'd actually worry if the engineers I work with couldn't
| pick up a new IDE/text editor, etc. pretty easily and
| quickly, if and when something like this happens. And I'd
| say the risk of it happening in the next three to five
| years is pretty minimal at this point.
| emerongi wrote:
| > I'd actually worry if the engineers I work with
| couldn't pick up a new IDE/text editor, etc. pretty
| easily and quickly
|
| Once you start making full use of your editor, switching
| to a new one and reaching the same level of proficiency
| takes a long time. I can edit code even in notepad, but I
| can't ever be as fluid in it as my main editor. I've
| changed my editor multiple times and it's a huge pain
| every time.
| jaywalk wrote:
| VS Code Pro already exists. It's called Visual Studio.
| mumblemumble wrote:
| Despite the name, they have basically nothing in common.
| They don't share a user interface, they don't share
| plugins, they don't share hotkeys.
|
| One of the main complaints many of the C# developers on my
| team have when they have to touch languages that aren't
| well supported by Visual Studio is that they don't know how
| to work VSCode.
| jaywalk wrote:
| I'm well aware of the differences between the two
| products, since I use both on a daily basis. My answer
| was a bit flippant, sure, but they are both IDEs
| developed by Microsoft and Visual Studio is definitely
| the "Pro" version of the two.
| pjmlp wrote:
| They do share some plugins actually, that is why VS
| nowadays also gets a node instance running on the
| background.
|
| And also why C++ workloads depend on .NET being
| available.
| babypuncher wrote:
| "VS Code Pro" came out in 1997
| cookiengineer wrote:
| Note that this will lead to unmaintained Electron Apps until
| at least 2032.
|
| We're basically fucked.
| chipotle_coyote wrote:
| I know that perception of Microsoft will never go away in the
| open source community, and maybe it shouldn't, although I'm
| not convinced Microsoft of 2022 is particularly worse (or
| particularly better) than most other companies operating
| simultaneously in open source and proprietary spaces.
|
| The context of "embrace, extend and extinguish" has kind of
| been diffused over the years, though; it never meant "buy a
| product and kill it," but rather meant adopting open
| standards and adding proprietary (not necessarily _closed,_
| which is not the same thing) extensions to them that end up
| becoming de facto standards, so your product is perceived as
| better at the task then the fully standards-compliant
| original. What happened with Visual Studio Code and Atom
| isn't an example of this at all. For a start, they're just
| two products that are competing in the same space; they've
| never had the same extension standards, so the idea of
| "embracing and extending" just isn't relevant here.
|
| Secondly, Microsoft obviously didn't buy GitHub to shut Atom
| down. I've seen the arguments that once Microsoft _did_ buy
| GitHub, Atom was doomed, but Code was already arguably more
| popular than Atom when Microsoft bought GitHub in 2018: Stack
| Overflow's developer survey showed VSCode as far more popular
| among surveyed users (34.9% to Atom's 18.9%). If those
| numbers had been reversed--if Code never made a real dent and
| Atom kept growing--then I have little doubt Atom would be the
| one continuing.
|
| Lastly, I suspect the runaway popularity of Visual Studio
| Code is pretty good insurance against a hypothetical "Visual
| Studio Code Pro" _replacing_ the existing VS Code. This would
| almost certainly cause a fork (or more than one!) to be
| created, and it's highly likely such a fork would get
| immediate backing and support from one or more technology
| companies willing to pay for continued open source
| development.
|
| However, I don't think that's likely, because I don't think
| that's how Microsoft is interested in monetizing Code. It's
| not a source of income in and of itself. It doesn't have to
| be. If it just so happens to have great GitHub integration,
| maybe your company will pay for GitHub enterprise features.
| If you're used to using it, you may be more likely to pay for
| GitHub Codespaces. If it has a great story for deploying to
| Azure, then maybe you'll be more likely to deploy to Azure.
| And so on.
| jimnotgym wrote:
| > If it has a great story for deploying to Azure, then
| maybe you'll be more likely to deploy to Azure
|
| This. Microsoft share price depends on the size of their
| recurring revenue from cloud. They can easily write off a
| few million on VScode for bringing more users to Azure
| reaperducer wrote:
| I'll go Nova before I go VS Code Pro.
| alxlaz wrote:
| VS Code "Pro" is very 1998.
|
| My money is on VS Code 365.
| onionisafruit wrote:
| It's already here. They went with the name GitHub
| Codespaces.
| oaiey wrote:
| That is a very good analogy. Considering that Office was
| also an offline product before it became a cloud-
| subscribed web/desktop hybrid.
| red_phone wrote:
| I'm not sure the term has ever been applied to Microsoft's
| own products...
| dkarl wrote:
| They embrace, extend, and extinguish products they don't
| make money on, so that people are forced to use products
| that they do make money on.
| IncRnd wrote:
| Microsoft doesn't make money from VS Code. Atom was
| retired due to a lack of activity with the project. I've
| never even seen anyone use Atom, since the time it was
| released 8 years ago.
| wiseowise wrote:
| > Microsoft doesn't make money from VS Code.
|
| They harvest an astonishing amount of data from it.
| HideousKojima wrote:
| Had two coworkers at my last job use it when they needed
| to edit some of our legacy PHP stuff (we were mostly a
| .NET shop) but even they switched to VS Code eventually
| because the writing was on the wall for support.
| dkarl wrote:
| Hence the parent comment:
|
| > We should be counting down the days till they sunset VS
| Code to focus on VS Code "Pro".
|
| I don't think it would serve their interests, so I'm not
| worried about it, but who knows? This cynicism is
| directed towards Microsoft because they've earned it.
| civilized wrote:
| Atom was developed before the acquisition. Which brings us
| to the second proud tradition of the tech titans, acquiring
| companies to end the products the acquirer doesn't like.
| nsonha wrote:
| it was dead already, or at least, shown inferior to
| vscode in feature set. If anything you can accuse MS,
| it's using its market position and the VS brand name to
| "steal" adoption, but that completed before the
| aquisition too.
| wiseowise wrote:
| > Which brings us to the second proud tradition of the
| tech titans, acquiring companies to end the products the
| acquirer doesn't like.
|
| Atom is inferior in every aspect to Visual Studio Code.
| Atom was on life support for too long.
| [deleted]
| babypuncher wrote:
| Does Microsoft not "like" Atom, or has its market share
| dwindled to the point that it is no longer worth
| maintaining?
| vchuravy wrote:
| If you look at the contribution activity it dropped off
| after acquisition of GitHub by Microsoft and it seems
| that development was redirected to VSCode.
|
| The writing was on the wall for a long while now, and was
| one of the reasons why the JuliaCommunity stopped
| advocating Juno/Atom as a platform and instead switched
| to VSCode
| jonwest wrote:
| Probably a bit of both if I was to hazard a guess. MS has
| VS Code, which is definitely the elephant in the room as
| far as go to IDEs in the environments I've been in
| lately. So right now they're spending engineering time on
| both VS Code and Atom, so they may as well focus their
| resources on the more popular one.
| Beltalowda wrote:
| Look at the Atom repo, very few commits in the last year,
| and it's not like there are loads of open pull requests
| (serious PRs _do_ get merged), and it 's been strongly
| dropping off for a long time. It's the programming
| community that abandoned Atom, not Microsoft.
| rob74 wrote:
| Well yeah, if you have two very similar products
| (editors/IDEs based on web technology), one of them much
| more successful than the other, putting a lot of effort
| into the less-used product sounds a bit hard to
| justify...
| lijogdfljk wrote:
| But Atom isn't, is it? It was started prior to Microsoft,
| to which Microsoft bought Github, and are now "sunsetting".
| While i don't think Atom was enough competition to actually
| warrant any real discussion here, the timeline seems quite
| fitting to EEE no?
| jopsen wrote:
| "sunsetting" is better than corp-speak saying "handing it off
| to community maintenance"
|
| Especially, if there isn't a dedicated community to maintain
| it.
|
| I'll take honesty over corp-speak any day.
|
| That said we probably only get honesty, because they want us
| using vscode instead.
| kodah wrote:
| Corporate speak involves blatant ambiguity and kafkaesque
| messaging. "Sunsetting" has a very direct meaning for GitHub,
| whether it gets supported by the community is something else.
| tinco wrote:
| No it's perfectly reasonable. That open source software forms
| some part of a commons is not really a thing in practice. Open
| source software is ran by maintainers, those maintainers own
| the projects, and they do with the software what they deem fit.
| And even if it were, VSCode is basically a rewrite of Atom that
| reuses a big chunk of the original codebase, they're the same
| sort of project serving the same sort of market, and the
| community is much better off with only one of them.
|
| Instead of letting it slowly bleed out and randomly catching
| stragglers with outdated marketing materials lingering on the
| web, they give it a swift death. Atom can go into the history
| books as an open source project that defined the industry for a
| decade.
| wildmanx wrote:
| > That open source software forms some part of a commons is
| not really a thing in practice. Open source software is ran
| by maintainers, those maintainers own the projects, and they
| do with the software what they deem fit.
|
| One should make a difference between (1) access to the source
| code to look, find bugs, make minor adjustments and (2)
| everybody with that access to be able to actively participate
| in the development.
|
| In the sense of (1), open source is "some part of a commons".
| That's what the license gives you.
|
| In the sense of (2), open source may or not be open to a
| community approach. It's fully legitimate for some company or
| other group of maintainers to provide (1) but deny anything
| related to (2). You are free to fork and make your own
| community, but there is nothing that guarantees you that your
| pull requests are accepted or even looked at, bug reports
| reacted to or anybody listening to wishes, concerns or other
| opinions about the project. It's _nice_ if that 's provided,
| and one could argue that some part of the spirit of open
| source is to enable a community, which in turn helps the
| original creators (and could be a major motivation to open
| source something), but nobody should be upset if maintainers
| choose otherwise.
|
| It's nice if it's clearly communicated how maintainers see
| this though.
| blackoil wrote:
| > VSCode is basically a rewrite of Atom that reuses a big
| chunk of the original codebase
|
| It isn't true anymore then saying Slack is rewrite of Atom.
| While it is using electron, editor and IDE aren't from Atom.
| WorldMaker wrote:
| Also, the core editor experience of VS Code, the Monaco
| editor, predated Atom by several years. It was used from
| the very early days of the Azure Portal and also in IE's
| Developer Tools. It didn't become "VS Code" until sometime
| after Electron stabilized out from under Atom, but parts of
| it have existed for longer than Atom.
| tinco wrote:
| Slack does not aim to build a superset of features of Atom.
| sk0g wrote:
| IntelliJ idea also includes most or all features Atom
| does, but that does not validate this statement:
|
| > VSCode is basically a rewrite of Atom that reuses a big
| chunk of the original codebase
|
| They both use Electron as their framework, but that's
| about where the code similarities end.
| mixmastamyk wrote:
| I've never seen anyone actually using atom, so would hardly
| say it defined anything much less than the whole industry.
| IncRnd wrote:
| > And even if it were, VSCode is basically a rewrite of Atom
| that reuses a big chunk of the original codebase
|
| Atom and VSCode projects have always been separate projects.
| Both using Electron does not mean they share a codebase, not
| in the normal sense of the phrase.
| fsckboy wrote:
| from the article _" This is a tough goodbye. It's worth
| reflecting that Atom has served as the foundation for the
| Electron framework, which paved the way for the creation of
| thousands of apps, including Microsoft Visual Studio Code,
| Slack, and our very own GitHub Desktop."_
| chipotle_coyote wrote:
| Yes. As the comment you're replying to said, "Both using
| Electron does not mean they share a codebase, not in the
| normal sense of the phrase." Code is no more a "rewrite
| of Atom that reuses a big chunk of the original codebase"
| than Slack is.
| fsckboy wrote:
| "both using Electron" refers to a period of time that
| occurs after "Atom has served as the foundation for the
| Electron" and my quote states that Atom -> Electron ->
| Spark
|
| I'm not an expert on this at all, I'm just quoting, but
| Spark is being used rhetorically as if it's an outlandish
| to consider it to be a descendent
| tentacleuno wrote:
| If I remember correctly, Electron was made _for_ Atom (by
| GitHub).
| thrdbndndn wrote:
| Yep https://www.electronjs.org/blog/electron
| jaywalk wrote:
| If the community actually cares enough, they can fork it and
| continue on with development.
| wrycoder wrote:
| Probably under a new name - I'd expect MS to be in control of
| the "Atom" trademark and branding, and they would stop
| further use.
| chii wrote:
| if you attempt to sell, or commercially utilize the atom
| name in a fork of the project, i can see why microsoft
| would stop you.
| jacquesm wrote:
| It's just a name, but they should be able to call
| themselves a 'fork of Atom'.
| bitwize wrote:
| I'd expect them to put the project out to Apache pasture
| (Apasture?).
| quadrifoliate wrote:
| > Apache Retirement Home for Veteran Projects
|
| Honestly, it kind of sucks that at this point you might as well
| call a project sunset if it has ASF stewardship, and that we
| seem to practically need the resources of a large company to
| keep an open source project "truly" afloat.
|
| I vastly prefer the honesty in saying "sunset"; it helps bring
| more light to this situation, and will perhaps drive new
| approaches to funding foundations like the ASF.
| bitwize wrote:
| Not everything in ASF is dead. OpenOffice probably is, but
| NetBeans is _still being actively developed_. Good thing,
| too, alongside IntelliJ it was probably the IDE most oriented
| toward getting people started writing Java code, rather than
| as a portal into the vast and confusing plugin ecosystem
| (looking at you, Eclipse).
| 5e92cb50239222b wrote:
| Back in the day it also had decent PHP support (don't know
| how true that still is).
| gunnarmorling wrote:
| I think this conflates several concerns which are unrelated.
| In particular, for a project to be under ASF stewardship does
| not mean it doesn't have large companies backing it. Look at
| projects like Kafka, Pulsar, Camel, Arrow, Spark, Flink,
| Pinot, Superset, Druid, etc. pp., they are all thriving and
| have strong funding.
| tonymet wrote:
| the code is only one of many artifacts within a project . you
| have multiple support channels for bugs and features, builds,
| distribution , monitoring / ops (crash and perf reports),
| developer apis and a dozen more - each requiring time,
| attention, people and effort .
|
| fork the code and start a new project with resources to take
| care of those and many other artifacts if you are so inclined .
| you have the license to do so
| eberkund wrote:
| I see a lot of people remarking that VS Code's killer feature is
| its extension system but I am not sure I fully agree.
|
| Sure VS Code has a lot of extensions, but many of them offer only
| basic features or are poor quality. The extensions which deliver
| the most value are actually the ones supported by large
| corporations (like the Go extension from Google or the Python
| extension from Microsoft).
|
| If another editor could port these powerful extensions I would
| care very little about the lack of icon themes and snippet
| extensions.
| mohas wrote:
| I think the most essential feature that vscode had over atom was
| good default features, once I see my coworker struggle for an
| hour to setup a dev env and I decided it is not going to be the
| tool of my profession
| meanmrmustard92 wrote:
| RIP. Hydrogen [https://atom.io/packages/hydrogen] running on Atom
| is the cleanest multi-lingual data science IDE in existence and
| has been my go-to for years. Haven't found a drop-in replacement
| elsewhere [vscode's language support is scattered: native python
| integration, different for R, Julia etc].
|
| Anyone on HN have recs [besides vim slime or send-to-terminal
| options in other editors, which work but are clunky] ?
| dangjc wrote:
| People kept asking me why I was still using Atom, and Hydrogen
| was it. It doesn't seem like there's an exact equivalent in
| VSCode. For now, I'm just relying on sending blocks of code to
| the interactive Python terminal. Or using the Jupyter
| extension. But the former might not work with other languages
| and the latter requires .ipynb files which maybe you don't want
| to check into git.
| hexo wrote:
| Glad that sunsetting of emacs is not going to happen any time
| soon :)
| gcau wrote:
| I still use Atom purely for its simple easy git UI (while coding
| in VSCode). VSCodes git UI, and all others I've seen, are a
| disaster in comparison. I want a simple, easy UI - in atom its
| exactly that. If I need more I'll just type it in the CLI. I wish
| there was something else I could use that's like this.
| hbn wrote:
| I've never used a better git UI than the one built into
| JetBrains' IDEs (though I always switch it from appearing in
| the sidebar to appearing in a popup window, like how it used
| to). They could honestly package it as a standalone app and
| it'd justify its own existence
|
| The merge conflict resolver is so intuitive and easy to use. I
| have colleagues who come to me for fixing merge conflicts even
| though I'm pretty mediocre at git in general :p My secret is I
| do it in IntelliJ
| fbcpck wrote:
| Interesting to find that I'm not the only person doing this! I
| also just hop to Atom if I need to do something more involved
| with git
|
| I typically do this when tidying up / amending >1 commit at a
| time (anything I can't do easily with git rebase interactive
| mode), or to resolve merge conflicts.
| whiskey14 wrote:
| Oh this is sad. As a teacher I loved introducing Atom as a first
| text editor as out of the box it did nothing but look nice. Then
| I could gradually add plugins everytime a student said something
| was annoying. Great for teaching principles before
| tools/shortcuts. Something which I think IDEs do far too often
| imo.
| Night_Thastus wrote:
| It's a shame. Atom was my first love, taking me away from the
| pain of using GEdit to write code for my college courses. I loved
| finding new packages and tuning and tweaking it all just right.
| I'll miss it.
| shusaku wrote:
| First love is a great description. I was 100% a vim guy for
| most of my career, but I tried out Atom and it ignited my love
| for the GUI
| [deleted]
| ghostly_s wrote:
| pjmlp wrote:
| Well, they managed to drive it much longer than I expected after
| GitHub's acquisition.
| sam0x17 wrote:
| In other news, the Atom One Dark color theme is alive and well in
| the VS Code marketplace. I've used it for 5 straight years.
| https://marketplace.visualstudio.com/items?itemName=zhuangto...
| sakaroz wrote:
| who was using it anyway ?
| gtsnexp wrote:
| I guess this idea of "Sunsetting" a project highlights one of the
| main differences between _Open source_ and _Free Software_. A
| successful _Free Software_ project rarely gets "Sunset".
| ramesh31 wrote:
| Embrace, extend, extinguish. It's in their DNA.
| franciscop wrote:
| Totally understandable, but the justification in the first
| paragraph of "Why are we doing this now?" seems a bit self-
| inflicted:
|
| * Atom has not had significant feature development for the past
| several years
|
| * (thus) Atom community involvement has declined significantly
|
| * (thus) we've decided to sunset Atom
|
| Feels a bit weird in that sequence to blame the community. Just
| say that YOU have abandoned the project since Microsoft acquired
| Github and get done with it, no need to sugarcoat it or others in
| the way.
| petre wrote:
| This. I might as well try Spacemacs now as Emacs isn't getting
| 'sunsetted' anytime soon, plus it runs in Lisp. Vim user. It's
| just that Vim on a GUI doesn't make a lot of sense to me. So I
| went from Sublime Text to Atom just because Atom was open
| source. Tried VS Code several times and ditched it, as it was
| full of MS-isms. It had a bloody Twitter react button in the
| status bar and telemetry.
| jw14 wrote:
| I checked back regularly for years to look for signs of life in
| Atom. There weren't any.
|
| Last blog? 2019.
|
| None of the releases did anything interesting. I work in Vue.js
| and needed that toolchain to work well, it never did with Atom.
|
| So they're blaming the community for something they decided
| years ago and kept deciding every week when no resources were
| allocated.
|
| Also, Zed isn't filling the void Atom left. Rust is
| interesting. Collaborative editing, not so much. Electron's
| lack of speed doesn't prevent VS code from fading into my
| workflow and being the most popular editor. I would still like
| an alternative because I don't think Microsoft should have the
| whole market.
| Arubis wrote:
| Atom was great, but I'll admit that I'd forgotten about it
| entirely.
| john-titor wrote:
| Can someone explain the hype around VSCode to me? I looked into
| it about a year ago and was immediately turned-off by the
| overwhelming amount of features that they throw at you right in
| the 'beginner's tour'.
|
| What I appreciate about Atom is that it is very simple right out
| of the box and does not get in your way. You cold always beef it
| up with packages later, but that progression is much more
| pleasant to me than the VSCode approach.
|
| The biggest selling point of Atom to me as a Python dev was the
| Hydrogen package. That tight integration of notebook features
| within the editor is something I have never seen before and a
| total game changer. Especially if you are working with data that
| you might need to visualize a lot. Correct me if I'm wrong, but
| from what I understand there is no Hydrogen equivalent in VSCode?
| Sure, there are plug-ins that let you run your code through a
| jupyter kernel and display the output in a second terminal pane,
| but that is not the same as the ability to simply highlight a bit
| of code, run that and have the results displayed immediately on
| the next line below. Having pyplot figures displayed in such a
| way is also not possible from what I saw, or did I miss
| something?
| seoaeu wrote:
| The killer feature of VS Code for me is that when you open a
| source file for python, or C++, or whatever it pops up a
| dialogue: "would you like to install the extension for this
| file type?". Click that and you've got working IDE features for
| that language with none of the hassle of tracking down which is
| the right extension, how do I keep my plugins up to date, which
| dependencies do I have to install first, etc.
| hbn wrote:
| In my experience, it works up to the point where it installs
| the extensions, and then it does a bunch of processing and
| still can't figure out how to run the project or what the
| code means anyway. Plus I now have a slew of new extensions
| installed, and I'm not sure which are new looking in my list
| of extensions.
|
| IntelliJ has a pretty damn good track record for me, when I
| import a project it indexes for a minute or so, then it
| automatically knows the entrypoint to run the project, and
| has a fantastic understanding of all my code. Cmd+click any
| symbol and it can show me definitions, usages,
| implementations, etc. I can hit shift+F6 to rename a symbol,
| and it hits every usage perfectly (as opposed to every time
| I've tried to use VS Code to rename something, and it just
| causes me more problems than if I were to do it manually). I
| haven't found any other text editor or IDE that works as
| seamlessly in this regard, and it's a dealbreaker for my
| productivity.
| TillE wrote:
| And then you spend an hour figuring out how to configure
| the extension, and it's still clunky.
|
| I like VS Code just fine as a text editor, but as an IDE
| Visual Studio is so much better, even for CMake projects.
| maxpert wrote:
| Sad day! But VSCode ate it up. Whatever one might say this had a
| huge hand in making Electron mainstream.
| jaywalk wrote:
| Atom did much more than help make Electron mainstream. Electron
| was actually born out of it:
| https://www.electronjs.org/blog/electron/
| jimnotgym wrote:
| Sounds like a good decision. I used Atom until everyone was
| talking about VScode... then I hopped over.
|
| I think Electron is an amazing legacy to leave. Like many I would
| like it to use less resources, but it is still a grest idea.
| mempko wrote:
| And here we are with vim and emacs still being updated and
| improved. Good job Bram and John.
| wly_cdgr wrote:
| Atom has been dead for years, this is just the state funeral.
|
| The situation now is:
|
| * Sublime for the Williamsburg corpo-hipsters
|
| * emacs and vim for the wizards and furries
|
| * VSCode for all the normies who just want to get on with doing
| their job and don't feel a need to express their identity or
| politics through choice of editor
|
| * WebStorm for the chads with the monster rigs to run it
| racl101 wrote:
| TIL I'm a Williamsburg corpo-hipster.
|
| This entire time I thought I used Sublime because it was a fast
| enough, full of features, battle tested editor, that also
| wasn't a bloated IDE nor an exercise in self flagellation (i.e.
| choosing to use an command line editor with a high learning
| curve like Vim or Emacs).
| femiagbabiaka wrote:
| No 4Chan tier comments here please.
| tinco wrote:
| I use VSCode because its Vim plugin is better than that of
| Sublime. If/when Sublime has caught up, I'd happily go back to
| it for that sweet performance and uncluttered UI. So am I a
| normie, a corpo-hipster or a furry wizard?
| jbiason wrote:
| The Vim plugin in VSCode is the thing that drives me out of
| VSCode, to be honest.
|
| I have to say that I built so much muscle memory in those
| years that it is kinda hard to realized I'm not using Vim,
| and there is always something not-quite-like-vim in VSCode-
| vim that usually gets in my way.
|
| (To be honest, the only editor that I found that is really
| close to Vim without being a Vim-thing was GNOME Builder.)
| throwaway413 wrote:
| Hermione Granger - muggle born with vested corporate interest
| alpaca128 wrote:
| > its Vim plugin is better than that of Sublime
|
| I'm pretty sure Sublime has a plugin that uses an actual
| NeoVim instance to process all inputs with all your
| configuration. Never tried it, I don't use Sublime. But I can
| confirm the feature works well in Firefox via FireNvim.
| tinco wrote:
| I think this is what vscode does as well. The magic is in
| how it cooperates with the GUI. All jumps and movements
| work, as well as search/replace and the hilighting and
| selections are even the native vscode hilights and
| selections so it's fluid going from mouse to vim and back.
| Last time I used Sublime (4+ years ago) there were a bunch
| of vim commands that didn't work.
| fartcannon wrote:
| VSCode is for Xbox gamers.
| tristor wrote:
| * Textmate & BBEdit for people who were using Macs for
| development before they took over the tech industry.
| MikePlacid wrote:
| I've "just" (as in: a couple of years ago) switched from
| BBEdit to Atom for my Python development, and now this.
| oblio wrote:
| All 3 of them?
| philwelch wrote:
| > emacs and vim for the wizards and furries
|
| ...respectively? TIL I'm a furry.
| bitwize wrote:
| Now all you need is a nice comfy pair of programming socks.
| oblio wrote:
| And sandals to match :-D
| reactspa wrote:
| Anyone else use Notepad++ ?
|
| Why not?
| hansoolo wrote:
| Occasionally
| skohan wrote:
| So MS owns the default place where code is hosted, and the
| default tool people use to edit code. Neat.
| jamil7 wrote:
| Cool and normal.
| oblio wrote:
| It's kind of bad, but they're probably the least bad behemoth
| owner.
|
| Apple would try to switch everything towards their walked
| garden, no questions asked. Google would shut stuff down
| every two years. Oracle... I'm not even going to bother.
|
| Amazon and Facebook could be interesting. Facebook is a bit
| shady, see the Oculus Facebook account debacle, but they're
| decent as stewards of dev tools. Amazon is also quite
| reliable for dev tools.
|
| Would anyone really big be a better steward? Did I miss
| someone?
| skohan wrote:
| I guess I would vastly prefer an organization which is
| _not_ one of the tech giants.
|
| Facebook/meta seems horrifying. Some of their tools are
| indeed great, but I can just imagine having to use a
| facebook login to push code to GitHub or to download VSCode
| plugins.
|
| Amazon is problematic for similar reasons as MS: since they
| are one of the biggest application hosts out there, bad
| incentives exist in terms of potentially allowing biases in
| their tooling to preference their own platform.
| adolfojp wrote:
| Well, Microsoft has always been about developers, developers,
| developers...
| burlesona wrote:
| "VSCode for all the normies" ... feels weird. Maybe it's true.
| But I feel like VSCode rose 1:1 with Typescript, and I kind of
| resent it because I associate it with script kiddies around me
| cargo-culting React in places it isn't needed and writing
| thousands of lines of overcomplicated javascript to "manage
| state" on pages that don't even need to have any.
|
| It's also noticeably slower than Sublime, which makes switching
| hard.
|
| But "Williamsburg corpo-hipster" feels off the mark. To me
| Sublime aligns more around the "JS minimalist" camp, which
| overlaps a lot with the "bootstrapped and profitable" crowd.
| wly_cdgr wrote:
| I am sorry if I hit a nerve, I was just riffing for kicks
| based on my own limited experience and the fact that I
| haven't had any coffee yet
| nemothekid wrote:
| >JS minimalist
|
| I mean, just that phrase sounds very "Williamsburg corpo-
| hipster" to me. Minimal, artisan javascript.
| omoikane wrote:
| I disagree with these labels, I would say the choice of editor
| is more religion than politics.
| oldgradstudent wrote:
| Religion and religious conflict is often an expression of
| politics.
|
| The conflict between Catholics and protestants in northern
| Ireland is not actually about subtle differences in religious
| doctrine.
| [deleted]
| derefr wrote:
| Isn't Sublime also for people whose haven't bought a new
| computer in 10 years and so can't run VSCode? That's why I
| started using it, at least. (Now it's just inertia.)
| luoc wrote:
| Only the lack of slurs reminded me I'm not browsing /g/ in the
| moment
| vorpalhex wrote:
| I went back to try Sublime lately and.. it's lost a lot of the
| minimalism that attracted me to it initially. That was the same
| reason why I loved Atom during it's golden years before it got
| too slow.
|
| Right now I am using a very stripped down VSCode, which is..
| fine. It works. I don't love it but it gets the job done
| usually.
|
| Any other good editors on the minimal side? I need a bit more
| than vim/emacs, but I don't want or care for autocompletion or
| anything that alters what I have written. I don't need vcs
| support. I don't need a built in terminal. Just a good, simple
| and fast code editing experience with modern ergonomics and
| syntax highlighting that works across every language.
| MobiusHorizons wrote:
| Have you tried neovim with any of the lsp integrations? I'm
| not going to pretend it's trivial to set up, but the result
| seems very powerful. If you just want to dip your toes
| without doing that he setup yourself, I believe there are
| some prepackaged options eg onivim which you can try out.
| [deleted]
| diarrhea wrote:
| Well put. There's just no reason to move off VSCode so far (for
| Python and friends). In a couple weeks' time, I'll be working
| with C# in Visual Studio. It has me excited since I've heard
| many good things about Microsoft developer tooling, of which VS
| is a huge tool in the box (C# as a language also seems
| attractive).
| hansoolo wrote:
| Can confirm. Also that git integration that everyone talks
| about in Atom is built right in.
| BaseballPhysics wrote:
| > VSCode for all the normies who just want to get on with doing
| their job and don't feel a need to express their identity or
| politics through choice of editor
|
| Seems like just another kind of identity: The self-titled
| "normie" who glances over at the "corpo-hipsters" and "wizards
| and furries" and smugly pats themselves on the back about how
| they're so much better because, unlike everyone else, _they_
| just want to "get on with doing their job"...
| bitwize wrote:
| The fact is, I _can 't_ do my job very effectively with
| Visual Studio Code. That's why I throw it down in frustration
| and storm back to Emacs every time I try it. Emacs has
| features that allow me to pretend to be an organized,
| functional person on the job -- notably, Magit, org-mode, and
| always-on Lisp that helps me automate away the tedious
| unusual bits of our process. If you were to compel me to use
| Visual Studio Code, much of my effort which is today
| productive would be lost as waste heat.
| wly_cdgr wrote:
| Heh, yes, def agree, although I think that a person who is
| genuinely oblivious or indifferent to all this will also prob
| end up using VSCode just cos it's free and has the highest
| brand awareness
| ThaDood wrote:
| This makes me feel conflicted.
| bellBivDinesh wrote:
| Atom was my first go to editor years ago when its git integration
| felt miles ahead. Then I saw gitglass(?) in VS Code and was moved
| to switch for shared workspace files at my job. I remember it as
| lightweight and fun.
| jlkuester7 wrote:
| I have never found a git integration that I liked more or found
| more simple and intuitive than Atom's. I found that even folks
| who were new to git would quickly become comfortable with
| managing git interactions via Atom.
|
| VSCode's "Source Control" on the other hand is a such a big UX
| dumpster-fire that I cannot bring myself to even try using it
| any more....
| robinsonrc wrote:
| I hope the main thing you leaned is that people want a text
| editor to start up in less than a second
| yeq wrote:
| I really liked Atom for non-code editing as it is usually much
| faster than VS Code, so this is quite unfortunate news
| vorpalhex wrote:
| If you are working in markdown, there are a good bundle of
| other options too.
| likortera wrote:
| Even after they promised they'll keep developing it despite of
| the acquisition:
|
| https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman...
|
| Not surprising. When this stuff happens is always lies because
| you plan for people to forget about stuff as times goes by, which
| usually happens.
| iterati wrote:
| They continued for 4+ years. That's not lying, that's time
| passing.
| alaricus wrote:
| Microsoft kills another great open source project. This is sad.
| Don't rely on Microsoft.
| oefrha wrote:
| Atom will live on in the form of Electron, one of the highest
| impact and most controversial technologies of the recent decade.
|
| I still remember the day VSCode was announced, and the binary on
| macOS (inside ./Contents/MacOS in the app bundle) was literally
| named Atom.
| 7speter wrote:
| I'm old enough to remember when microsoft said that atom
| developmennt would continue alongside Visual Studio Code after
| the company bought github...
| tough wrote:
| I subscribed to WL, free me from my laggy VSCode pls
| keewee7 wrote:
| Really begs the question what Visual Studio Code did right and
| what Atom did wrong.
| Santosh83 wrote:
| MS poured developers at VS Code which resulted in it blowing
| away Atom pretty soon in terms of performance. Soon devs
| started migrating to VSC, plugin ecosystem started accreting,
| and gradually people just forgot about Atom. It is not that
| Atom did anything horrendously wrong. If the same dev effort
| had been put into it that VSC got, am pretty sure it could've
| become almost as good now. Maybe even better in certain
| respects.
| jahewson wrote:
| I don't think that's true. I used VSCode when it was first
| released and the team was just a dozen people in Switzerland.
| The performance was blazing.
| jacquesc wrote:
| Speed. I used Atom for a couple years, but quickly switched to
| VSCode once it was viable as it was the first electron editor
| to actually be "fast enough" for me.
| wiseowise wrote:
| LSP, better performance, better defaults, better plugins
| ecosystem, better (subjectively) UI.
| hansonw wrote:
| (Note: I worked on https://ide.atom.io and Facebook's Nuclide
| team).
|
| On the topic of performance - one of the architecture decisions
| that VSCode nailed was the 'extension host'
| (https://code.visualstudio.com/api/advanced-
| topics/extension-...): all VSCode extensions are sandboxed in a
| child Node process, and can only communicate back with the main
| IDE process via the VSCode API. This has huge benefits for
| performance:
|
| (1) extensions can never block editor startup. this was a huge
| problem for Atom as package loads were startup blocking and it
| wasn't uncommon to have multi-second startup times with lots of
| packages installed - especially due to the fact that JS
| packages typically repeat dependencies, resulting in tons of
| bloat. Also extension authors are rarely performance-conscious
|
| (2) extension code can never block the core rendering thread,
| another huge problem in Atom - you'd often have
| stuttering/frame drops if extensions were doing blocking work
| on character or cursor changes, which was more often the case
| than not..
|
| The tradeoff of course is that VSCode extensions are very
| limited in the set of UI customizations they can make but MS
| did a very good job of designing their APIs to be sufficiently
| extensible in this aspect (i.e. having APIs for extensions to
| hook into all core IDE features). Atom's extension ecosystem
| was much more fragmented resulting in dependency/versioning
| hell.
|
| As a side note, another benefit of the extension host model is
| how it enables extensions to semi-magically work on remote
| filesystems (including inside WSL) without needing complete
| rewrites.
| bogwog wrote:
| I didn't use Atom much, but I think it's obvious that the
| primary reason it died was because Microsoft decided to make
| their own competing editor, and then bought the parent company
| of Atom. It wasn't exactly the most popular editor at the time,
| but it did still have some users.
|
| Reminds me of how Adobe killed off FreeHand (the only
| competitor to Illustrator at the time) by buying the parent
| company and then halting development.
|
| Of course, Microsoft likely gave zero shits about Atom as a
| competitive threat since it was effectively dead at the time
| anyways, but I still think it's interesting to see the
| similarities to the Adobe situation.
| mynameisvlad wrote:
| > the primary reason it died was because Microsoft decided to
| make their own competing editor
|
| > Microsoft likely gave zero shits about Atom as a
| competitive threat since it was effectively dead at the time
| anyways
|
| How can Microsoft both give zero shits because it was
| effectively dead, while also still being the primary reason
| it died? That seems to be a chicken-egg problem.
| pygy_ wrote:
| Chronology. VSCode ate Atom's lunch before MS purchased GH.
| bogwog wrote:
| I mean that Microsoft's acquisition of Github had nothing
| to do with Atom whatsoever (I assume), but the acquisition
| was the final nail in the coffin for it.
|
| Would it have survived if Microsoft didn't acquire Github?
| It's _possible_ , however unlikely. But after the
| acquisition? Not a chance.
| akagusu wrote:
| Glad to see that someone remembered FreeHand. It was much
| better than Ilustrator, this is why Adobe killed it.
| bogwog wrote:
| I don't know what's worse, that Adobe would do something so
| shamelessly anti-consumer and anti-competitive, or that the
| FTC did nothing to stop such an obviously bad acquisition.
| akagusu wrote:
| Today we can clearly see that as anti-competitive and
| anti-consumer acquisition, but at time, I guarantee you
| the FTC saw the agreement as business as usual, since it
| does not know how to regulate tech companies even today.
| avrionov wrote:
| The first thing which Visual Studio Code did right was the
| better performance. The initial reaction to Atom was that it
| was very promising, but very slow.
|
| The second big innovation was the language server protocol.This
| allowed any language to be supported by VS Code.
| radus wrote:
| Third, for me at least: Remote Extensions. That suite of
| extensions including SSH WSL, and Container support made
| things I was already doing frictionless.
| fendy3002 wrote:
| Integrated terminal from the get go, built in git
| interface, and the latest live share.
| WorldMaker wrote:
| VS Code had a really interesting "head start": the core editor
| (named Monaco) had been built for very early stages of the
| Azure Portal and then been adopted into IE 10/11's Developer
| Tools to replace an aging code viewer/editor. In order to run
| in Dev Tools it had to run through an extreme gauntlet of some
| of the web's worst "files": giant one-line minified things,
| massive multi-megabyte bundles, and so forth. So the Monaco
| code editor got a huge amount of performance testing and work
| years before Atom arrived and built Electron.
|
| It also sounds like VS Code took a much more measured approach
| to extension APIs than Atom did. In Atom nearly every part of
| the product was an extension, which is a great approach to
| dogfooding extension APIs and making sure everything including
| the kitchen sink has an extension API, but getting that
| performant is tough. Whereas VS Code was very careful in the
| early days in what extension APIs they declared and started
| from a place of performance first. In many cases if only a
| single extension doesn't perform well in VS Code you almost
| don't notice because it's mostly isolated from the rest of
| application performance. Atom had a lot more situations, from
| what I heard, where one badly performing extension brought
| everything to a crawl.
| emehex wrote:
| This is terrible. While I like VSCode, I exclusively use Atom for
| programming in Python because of Hydrogen [0], an extension which
| makes .py scripts feel and behave as though they were Jupyter
| Notebooks. I hope the nteract/Hydrogen devs are able to save
| their work and move it over to Zed/VSCode.
|
| [0] https://github.com/nteract/hydrogen
| adictator wrote:
| alchermd wrote:
| Atom was my first text editor when I was getting serious into
| learning software development. Sharing this neat video for those
| who hasn't seen it yet:
|
| https://www.youtube.com/watch?v=Y7aEiVwBAdk
| hdivider wrote:
| To the founders and contributors of Atom: thank you.
|
| Your work made more impact than you can possibly know. Atom
| became my absolute #1 editor. For code, and notes of every
| possible kind. As an entrepreneur, it carried me through so many
| adventures. The death of a cofounder, great losses and victories,
| the madness of 2020, a close friend's betrayal, a subsequent
| rebirth of sorts, and on and on. And always, this trusty piece of
| software sat there. Ready whenever calamity struck.
|
| Thank you, folks. You created a wondrous piece of art and greatly
| impacted this entrepreneur's way of thinking and organization.
| Many have gained as a result.
|
| Will follow Zed closely!
| stjohnswarts wrote:
| I expected this with the Microsoft takeover. Most "extraneous"
| non-profitable activities and projects will be killed off. Also
| MS produces VS which is a successor in a sense to Atom.
| dindresto wrote:
| Does anyone know the current status of https://zed.dev/, the
| editor by former Atom devs?
| sphars wrote:
| The founder is in this thread, stating they just started an
| alpha release: https://news.ycombinator.com/item?id=31669615
| geodel wrote:
| Editors are like browsers, huge amount of upfront work to even
| get parity with decades old editor and no commercial potential
| to sell product. Charge a little bit of money and a million of
| well paid IT workers suddenly become _so poor_ to pay for tools
| they need for work. They would further spend productive time
| haranguing maintainers on why editor need to be _open source_
| (code word for just _free as in beer_ ) or how 60-70 dollars /
| year is too much for a code editor and so on.
|
| So end result is only editors exist are _feature complete_ long
| time back / or maintained by companies who could just give it
| for free, compensating it with cloud revenues. Besides a couple
| of paid editors with insignificant market share of course.
| aniforprez wrote:
| I wish there was an editor I feel comfortable paying for
|
| Idea stuff is just way too bulky for me. I don't like using
| any of them, sacrilegious as that may be, and don't feel the
| need to use them for since I don't use java. Paying for
| Sublime is just not worth it with its far poorer plugins and
| API and their release cadence is atrocious. I checked Nova
| from Panic out and it looks promising but it's VERY far from
| being a replacement for my current setup
|
| So I see almost no reason to switch from vim and VSCode, both
| of which are free and have extensive plugin support and are
| great at what they do. If something comes along that is
| faster, has good language support and good list of
| extensions, I would have no trouble paying for it
| iamnbutler wrote:
| We just started a private alpha this week! Lots of news and
| more public facing information coming soon.
| uneekname wrote:
| RIP Atom. I wrote a lot of code in Atom back in the day.
| marcodiego wrote:
| I had high hopes for atom. At first I thought about it as a FLOSS
| competitor to sublime. Its slowness (mostly because of electron)
| was entirely tolerable for me even on 10-year old hardware. I was
| afraid at how fast VSCode ate it. It is a good thing we have
| VSCodium.
| albertzeyer wrote:
| So I wonder a bit, VSCode has clearly won over Atom.
|
| But technically, as far as I know, they are both pretty similar.
|
| So where is the difference? Are these just small details which
| VSCode got better? Or are there bigger things?
|
| Or why else did VSCode actually won?
|
| I have used both in the past. VSCode seemed a bit snappier, which
| is an important aspect for an editor. But I'm not sure if this
| was really the case actually. Or also, why there would be such a
| difference. Both used Electron, and I assumed both would use
| similar techniques for the editor.
| aniforprez wrote:
| Performance and extensions being forced to be simpler due to a
| fast more restrictive API. VSCode was miles ahead in terms of
| performance and way snappier than Atom was and the extensions
| on Atom gave frequent troubles cause they had all sorts of
| weirdness to them
| jonathaneunice wrote:
| I like Atom and use it occasionally. But I use VS Code day-in and
| day-out. The decision makes sense.
|
| If VS Code were not exceptionally good, Atom might have had more
| of an opportunity. But "yet another good option" is not enough to
| drive investment, sustain a community, and spin an ecosystem.
| edgyquant wrote:
| Maybe I'm misremembering but didn't VSCode begin as a fork/skin
| of atom?
| wiseowise wrote:
| No? It did use Electron though (Atom Shell).
| edgyquant wrote:
| Yup. My mistake https://thenextweb.com/news/microsofts-
| cross-platform-visual...
| nobodywasishere wrote:
| Atom created Electron, VS Code is built on Electron
| jacobmischka wrote:
| Atom predated VS Code and was the impetus for Electron, which
| VS Code uses. You may know this, but this comment makes it seem
| like they tried and didn't have an opportunity. They literally
| invented what the majority of new "desktop" apps uses to render
| UIs, they just couldn't compete with Microsoft (before they
| were bought out, after which of course Microsoft wasn't going
| to invest seriously in it).
|
| Edit: Fixed typo (thanks torstenvl!).
| torstenvl wrote:
| _impotence_ means powerlessness or inability; the state of
| lacking potency. It 's usually used to refer politely to
| erectile dysfunction.
|
| Perhaps you meant _impetus_?
|
| https://www.merriam-webster.com/dictionary/impetus
| jacobmischka wrote:
| Lmao, you're right indeed. My mistake!
| dchest wrote:
| While Electron had a huge impact, before Atom team developed
| atom-shell (which became Electron), there was NodeWebkit (now
| nw.js). I actually shipped a Windows app written with it and
| Angular.js, without using Windows for development or
| building.
| Animats wrote:
| Do not want a "cloud based text editor". Being reliant on an
| external service is a huge point of failure. It can go down. It
| can join the huge list of discontinued Google products. It can
| have security problems. You can be arbitrarily banned by the
| service operator. Most cloud-based services only live for a few
| years.
| Dave3of5 wrote:
| I remember this being released and this was a concern at the time
| that the project would be abandoned. If I remember this it was
| mostly a concern as Github as a company should focus on their
| main product which is not an editor and that there are many
| existing editor that do it better.
|
| I suspect that what actually killed this is the acquisition of
| Github by Microsoft and the fact that Microsoft are pushing
| VSCode very hard. Dev tooling is something Microsoft had a lot of
| experience (and failures) in and it was always an uphill battle.
| hackernewds wrote:
| What other editors are better and could be recommended? I guess
| I'm replacing Atom today
| bogwog wrote:
| Sublime Text gets my vote. Pretty hard to go back to anything
| else after using it.
|
| It's not free, but if you're really strapped for cash you can
| use it like most people use Winrar, at least until the guilt
| overcomes you.
| Dave3of5 wrote:
| Vim, emacs, sublime, vscode, notepad++ there are lots.
| edgyquant wrote:
| Eh VSCode killer atom long ago.
| mattsouth wrote:
| This makes me sad as I very much prefer the atom approach to the
| git and github panels than the vscode approach. vscode is much
| faster for typescript development though.
___________________________________________________________________
(page generated 2022-06-08 23:00 UTC)