Sad to see this go. I was an early adopter of Atom, and I wrote two extensions for it, one of which while it was still in beta.
The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engineering built around TypeScript, was rapidly taking over.
Of course, the GitHub acquisition was the last straw, but to be fair Atom was already pretty dead by then.
While the Atom project ultimately failed, it did give us Electron and Tree-Sitter, two technologies that will certainly outlive it.
Atom predated the LSP and leaned heavily into customizations with all the plugins running inside the UI thread (more like a traditional web page and 3p scripts). At the time they viewed the extreme customization support as a feature, and there was a thriving ecosystem of folks making plugins.
That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up quite slow.
VSCode's architecture worked much better in real world configurations, and it turns out better performance wins in the editor space, even if it meant losing certain customizations (up to a limit). The architecture also allowed seamless remote editing, something Atom never could have done.
The interesting thing has always been that both were built on Electron. Atom's developers had built all the tools and primitives needed, they just didn't have the understanding of the long term ecosystem effects of their design.
VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn.
VSCode did almost everything right: The choice of TypeScript as the base language (with which VSCode has a symbiotic relationship), the limited, slowly expanding extension API, LSP, the monorepo, the monthly release cadence, the built-in terminal, and the list goes on and on. They turned Electron's strengths into super-strengths, and deftly engineered around Electron's weaknesses. VSCode is the greatest productivity tool in the history of software engineering, and it fully deserves the dominant status it has today.
LSP was a HUGE step forward, all editors benefit from it nowadays. Having multiple communities contributing back to the same language server makes maintaining those plugins a lot more comfortable.
People hate on electron, but it's a pretty amazing piece of tech if you ask me. I can turn a browser game into a steam game with basically no effort which is nice because browsers change over time and electron helps you get a working offline snapshot of something you created.
Electron is essentially an operating system that runs on every operating system, so you can target just a single OS and your application works everywhere.
There was node-webkit (nowadays called nw.js) that predate electron by quite some times. I remember know about it precisely because I was playing games that was developed with it.
I started a job in 2018 and someone commented “what are you still on Atom for? Everyone has moved to vs code”. So yeah it’s been kinda dead for a long time now.
I haven't worked for someone in years and that totally passed on me. I've tried code several times because of specific platforms it has plugins for but I never seen it as even comparable, at least not more than sublime.
No idea what problems people had with Atom, but I really hope some fork let it live on.
whoa, a whole 4 years ago!! ;-) i want to make a "kids today" joke/comment, but it's more of just the pace of trends/fads not the people per se. you show up at a new job and the people make comments, of course you change. i've never used Atom, so maybe it was a better thing to change, but i've been introduced to some very ingrained workflows that just no longer made sense on so many levels. you can come in guns blazing and try to change everything now, or slowly acclimate to the workflow and then start suggesting changes/updates from inside. if you're hired as a 10x dev, then maybe guns blazing works, but if you're not, i'd suggest the latter.
I tried Atom for a while in Windows, but a file watching bug made it quite inconvenient. Every time I edited and saved a file in another IDE (at the time, I was stuck using it to compile and debug an embedded system), that IDE would rename the original to a temporary file in a temporary directory before writing the new version. Atom would follow the rename rather than re-load the new file at the original path. It would make the open tab useless.
I tried making an issue for it, but someone ranted on about moving files around on a Mac and then closed the issue.
I tried trying to solve the bug myself, but I got about 4 layers deep into callbacks across at least three different repos, and gave up.
I know people shit on VSCode but in my humble opinion, VSCode single handedly destroyed Atom. Far superior tool, 100% free and adoption growth was crazy.
I also was an early tester (not adopter) of Atom and I kinda hated it right from the start, but it's been a while and I could never really put my finger on it. I think it always somehow felt sluggish (I'm talking trying out several builds over several months, not just a one-off). But I've also never warmed up to Sublime (which was fast but also felt off).
Interestingly the moment I tried out VS Code (many years later) I instantly liked it and have been using it sporadically ever since, and as people always liken the two, I am confused to this day why one felt wrong and one felt right.
I started with Sublime in college and then went to Atom when it came out because it was "Free Sublime". Granted I liked it back then but I was still a college student (had I picked it up now I would have different opinions). Almost as quickly VSCode came out and was a "Better Atom" (I thought VSCode was based on Atom for the longest time).
I wonder what will eventually replace VSCode. Lex Friedman said on his podcast that he sees VSCode as a modern Emacs which I think is a good way of thinking about VSCode.
Personally, I prefer CoffeeScript. The code gets more concise, it stimulates a coding style that's more objective and less "enterprisy" than TypeScript with all the excessive OO stuff. A simpler and more concise language attracts more contributors overtime.
However, TypeScript has clearly won and static typing can help a lot with autocomplete stuff, so there is no point fighting back.
There is a solid alternative, though. Pulsar. Atom was kind of dead, but it still had a small, dedicated fanbase including myself. Hopefully Pulsar will be able to keep the project alive as long as us Atom fans use it
VSCode is owned by Microsoft, ever since Microsoft bought GitHub in 2018 it was bound to happen. The two text-editors had the same audience therefore Atom was bound to get shut.
I'm not sure it's fair to say it failed. Not everything is forever. It served very important purposes, helped push technology forward and paved the way for editors like VSCode.
I guess I'm old school, but I'm genuinely surprised by how Microsoft drove such widespread adoption of Visual Studio which, as I remember, was an expensive, basically enterprise-only IDE for very Microsoft-specific proprietary technologies like C# and .NET.
we had the conversation at University back in 2002; it went, "Atom is a dumb name" (for a beta package for editing, building in). What is this, the year of Marvel Comics taking over the Galaxy or something?
Typescript makes VSCode very slow though. I remember the feeling when switched from Atom to VSCode it's wicked fast. And then Typescript happens, my macbook's fan keeps spinning from time to time.
VScode is also crap.
It doesn't even support multi screen multi-window, heh no thank you.
I can't comprehend, how anybody can use VScode for any real work.
It might sound controversial, but for me Atom was almost a 1 to 1 Sublime copy with worse performance and quality. It was slow and ugly. It’s only quality was that it was 0$.
It was the first editor I’ve seen to choke when opening 1M file (it even had a warning that it’s a too big file - lol). There simply was not enough RAM in the world for this memory hog.
I’m not really sad to see it go. It was another free toy of a big company that people used not to spend 60$ on real thing made by small company and waste thousands of dollars on lost productivity and time.
As an editor day to day yes you are correct. Sublime is the goat as far as performance. VSCode has become my primary editor because I work remotely via SSH but nothing can touch the lightness and latency of subl. I still run it in tandem with vscode for stuff that doesn’t require a remote conn. It’s an order of magnitude quicker than VSCode.
You need a good machine, but on an M2 SSD with a recent CPU and enough RAM, VSCode takes one second to start, much less to open a new tab. Not sure Sublime Text's speed will still be a big selling point in the future.
> t was the first editor I’ve seen to choke when opening 1M file
I recall trying Atom before VSCode had been released. I loaded up a 1MB XML file and it ground to a halt.
After some searching I found a bug tracker issue reflecting this, where one of the devs said something to the effect of "a 1MB XML file is extremely large, I don't think we'll support that".
At that point I uninstalled Atom.
On a related note, not long ago I accidentally dragged a 450MB SQL script into VSCode. I fully expected it to cave like Atom had on the 1MB XML. However to my pleasant surprise it worked just fine. Editing it was as quick as a regular file, and the memory usage was not excessive (around 2.5G total). I admit I was a bit impressed by that.
I had a gig which required opening ridiculously large XML files (metadata for music albums). Some classical music compilations (think "6 CD bargain bin" boxsets) would end up with 1-2GB XML files.
Sublime didn't even flinch when opening and navigating around the file. Truly impressive text editor and absolutely worth the license cost.
Sublime Text definitely had it's moment in the spotlight, at one point (around 2012-2014) it was basically the only editor I saw people using, besides emacs/vim which has its diehard fans (including myself).
Most of those people are using Visual Studio Code today instead, although in comparison, VS Code is very bloated and slow.
I think you should get just that with Notepad++ on Windows or TextWrangler (BBedit) on Mac. On Linux I think that all stock editors have it (GEdit, etc…). All that for free and without Electron madness. You should be much better with any of them.
If you use windows, notepad++ is what you're looking for. It was my first love in terms of code editors, and I still haven't found an editor (besides vim, and probably emacs) that handles on-the-fly macro recording and playback like NPP has for decades.
Same for me and my whole Team. I'm loving it. They're cheap, reliable, fast, flexible, beautiful - just awesome enabler that don't stand in the way. Huge Kudos to the creators! <3
The first and last time I tried Sublime Text, it turned out to be impossible to properly have a file open in two editors (or tabs or whatever Sublime's term is): any changes made in one editor were only synchronized to the other editor upon saving the file. I really tried to like Sublime, but the lack of such a basic feature was a total no-go. That was several years ago, has the situation changed?
Multiple views into a single file have been supported for a long time; I believe as far back as ST2. Currently it's easily accessible by right-clicking on a tab and selecting "Split View".
I wonder if it played a part in Microsofts purchase of Github. When you look at things like code spaces, co-pilot and how VSC can now work directly on Github/Azure repositories without moving the code to "your machine", it seems like they found a good way to make Github (and Azure DevOps) more profitable through Atoms successor.
For better, certainly. Electron has in particular been an enormous boon for Linux users, because it's so easy to make cross-platform applications now that even companies who wouldn't have bothered otherwise now have a Linux download. No way that apps like Slack would have a Linux desktop version if it wasn't for Electron.
The 1% Linux users may have benefited, but it came at the expense of the other 99% on Windows & Mac who had to give up native performance and UI on all their applications.
Just an aside that had nothing to do with Atom itself, but I didn’t get into Electron while it was still called “Atom Shell” because the name was doing it a bit of a disservice. For some reason, by brain put it into a category of software more akin to bash/zsh and never questioned it again.
Tree-sitter[0] came out of Atom performance optimization, I think, and that's a legacy that will live on a long time. Atom was in my view the closest thing to emacs out there, and it's sad to see that sort of user-empowerment not live on.
The emacs comparison definitely feels apt. Being able to simply use JavaScript and CSS to make changes to the editor made it feel so powerful. Maybe I just need to get around to learning elisp (or find an elisp-JavaScript binding…)
Lots of things came from Atom and it's development, so much I'd still consider it a success although the editor itself didn't live on. Tree-sitter, Electron, "text-editor as a browser app" all became popular ideas thanks to Atom. Is there more things coming from Atom that I'm missing?
I resisted switching to VS Code for a long time because I far preferred the UX and design of Atom, but I eventually caved not because of performance gains I wanted in VS Code (honestly I found Atom plenty fast for the work I was doing), but because many Atom extensions were left to rot and slowly broke over time as most maintainers moved to VSCode extensions.
>I far preferred the UX and design of Atom, but I eventually caved
That's my experience exactly. I still haven't been able to configure VS Code to fully match the experience I want with respect to keybindings and subtle look-and-feel and functionality details.
Aside from the infrequent case of hanging when opening very large files I had no real issues with Atom and could have happily kept using it.
For what it's worth Pulsar (https://pulsar-edit.dev/) appears to be a community-maintained fork of Atom. (For that matter one of the primary Atom creators is working on https://zed.dev/.) But personally I got tired of swimming upstream and just caved to VS Code.
(I am a little tempted to go back to emacs, which was my editor of choice before Atom, but that's ends up being an enormous time-sink for me anyway.)
I cannot stand VSCode UX/UI. Not sure how this is not an issue for everyone. Maybe I'm just too picky. For this kind of things I don't use VSCode:
- The right side bar is "dynamic". Most of the time it's the Explorer showing the directories and files, but when I try to search for something, though, it becomes the Search sidebar. Same for all the potential sidebars (Source Control, Run and Debug, etc.)
- Everything is a plugin. That means I need to carefully check who's the author of the plugin, probably check as well the source code to avoid using malware, etc.
- Everything is a plugin. That means I need to craft a set of plugins in order to work in certain projects. I prefer JetBrain's approach
- No floating windows. Maybe I'm old-fashioned, but I prefer that, for instance, Settings to be opened in its own window, instead of opening a new tab in my editor. Also all the Settings in VSCode are on the same "page" (sure, whenever you scroll, the left-side grouping of Settings is updated accordingly, but imho it's difficult for me to focus on the section I need to work on)
> - The right side bar is "dynamic". Most of the time it's the Explorer showing the directories and files, but when I try to search for something, though, it becomes the Search sidebar. Same for all the potential sidebars (Source Control, Run and Debug, etc.)
Yeah it's just a tabbed view. I like it, saves space while staying useful. Maybe because most software I use has tabs already.
- Everything is a plugin. That means I need to carefully check who's the author of the plugin, probably check as well the source code to avoid using malware, etc.
True, but most popular languages have plugins authored by Microsoft. Some are from Red Hat. You'll miss out on GitLens and LaTeX Workshop, but VSCode with only trusted plugins is more than good enough.
> - Everything is a plugin. That means I need to craft a set of plugins in order to work in certain projects. I prefer JetBrain's approach
For Python, web dev, C++, etc., there's a "plugin pack" that depends on what you need to work.
> No floating windows. Maybe I'm old-fashioned, but I prefer that, for instance, Settings to be opened in its own window, instead of opening a new tab in my editor. Also all the Settings in VSCode are on the same "page" (sure, whenever you scroll, the left-side grouping of Settings is updated accordingly, but imho it's difficult for me to focus on the section I need to work on)
Sounds like you just don't like tabs? I find that the window list gets way too crowded and messy when I'm working on multiple projects with multiple tools. Tabs (in browser, explorer and editors) are a lifesaver.
I've gotten used to Visual Studio, where I can grab a tab and pull it out of the window to make it its own window. If you try that in VSCode, it'll just drop the file on the Desktop.
To get something similar in VSCode, I have to open a new window, drag the file over, then close it in the original window.
In general the marketing and branding of Atom was awesome. The retro-futuristic design worked well with the idea of bringing a text editor into the 21st century. I love that they call their docs the 'flight manual.' It will be missed.
I think the Atom editor + Hydrogen plugin for running interactive Python sessions inline with the code is still unmatched by anything available in VS Code. This setup is what I migrated to when I ditched Matlab for the "scientific Python" stack, and I'm still here.
Multiple concurrent kernels, the ability to connect any .py file to any running kernel, sharing variables and imports across multple .py files, inline matplotlib output that persists on-screen and inline with the code even when running other code cells... the list goes on. I'm really fond of this setup. I use it daily--it's an essential component of my day job--and intend to do so for the foreseeable future. VS Code does seem to be the way of the future but there have just been too many friction points for me to leave Atom.
VSCode doesn't support an API to put outputs inline in the text editor. IIRC there have been longstanding feature requests for it but it would probably have a performance hit. The closest thing is having a separate output window on the right side
I completely agree. For the last couple years I've used VSCode for everything _except_ interactive Python development because Atom + Hydrogen is just too good.
I'm giving VS Code + its Jupyter extension a shot for now. It's significantly worse than Hydrogen, but I tried to make it a little less bad with a quick extension to auto-infer code blocks [0].
Same! I live in this ecosystem (Atom + Hydrogen python sessions) on a daily basis. But rather than for "science", i use it for devops productivity (scrape logs, query dbs, automate mitigations) and some low-key data analysis.
It's breathed life into my love for programming, given how easy it is to just start executing code (sometimes I just use it as a calculator app since it's that easy and accessible)
I tried VSCode's equivalent plugin, but the UX was nowhere near as nice.
Readit News
The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engineering built around TypeScript, was rapidly taking over.
Of course, the GitHub acquisition was the last straw, but to be fair Atom was already pretty dead by then.
While the Atom project ultimately failed, it did give us Electron and Tree-Sitter, two technologies that will certainly outlive it.
That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up quite slow.
VSCode's architecture worked much better in real world configurations, and it turns out better performance wins in the editor space, even if it meant losing certain customizations (up to a limit). The architecture also allowed seamless remote editing, something Atom never could have done.
The interesting thing has always been that both were built on Electron. Atom's developers had built all the tools and primitives needed, they just didn't have the understanding of the long term ecosystem effects of their design.
VSCode did almost everything right: The choice of TypeScript as the base language (with which VSCode has a symbiotic relationship), the limited, slowly expanding extension API, LSP, the monorepo, the monthly release cadence, the built-in terminal, and the list goes on and on. They turned Electron's strengths into super-strengths, and deftly engineered around Electron's weaknesses. VSCode is the greatest productivity tool in the history of software engineering, and it fully deserves the dominant status it has today.
Atom wasn't just "built on" Electron, they made Electron.
Electron was made from Atom, literally. Electron was originally called Atom Shell https://www.electronjs.org/blog/electron
> A central server uses an Objectstore database to tightly integrate compiler(Lucid C++ Compiler), editor(emacs), debugger(gdb), and browsers
https://www.desy.de/user/projects/C++/products/lucid.html
3p = third-party
Deleted Comment
Deleted Comment
It really does come down to how people build on top of it.
I tried opening a 2gb log file in Atom and it took like 10 minutes before crashing.
VSCode on the other hand, while a bit slow, opened it and I could search quickly and scroll it without any issue at all.
That was what caused me to switch.
There's actually quite a lot of effort required if you want Steam overlay to work and/or not crash with Electron, or to interact with Steamworks APIs.
A small usb stick copy tool? here take 300mb and more to get the 1 minute job done. A bash one liner.
No idea what problems people had with Atom, but I really hope some fork let it live on.
I tried making an issue for it, but someone ranted on about moving files around on a Mac and then closed the issue.
I tried trying to solve the bug myself, but I got about 4 layers deep into callbacks across at least three different repos, and gave up.
Interestingly the moment I tried out VS Code (many years later) I instantly liked it and have been using it sporadically ever since, and as people always liken the two, I am confused to this day why one felt wrong and one felt right.
I started with Sublime in college and then went to Atom when it came out because it was "Free Sublime". Granted I liked it back then but I was still a college student (had I picked it up now I would have different opinions). Almost as quickly VSCode came out and was a "Better Atom" (I thought VSCode was based on Atom for the longest time).
I wonder what will eventually replace VSCode. Lex Friedman said on his podcast that he sees VSCode as a modern Emacs which I think is a good way of thinking about VSCode.
However, TypeScript has clearly won and static typing can help a lot with autocomplete stuff, so there is no point fighting back.
I'd call that success.
That’s not the positive thing that you think it is.
Deleted Comment
It was the first editor I’ve seen to choke when opening 1M file (it even had a warning that it’s a too big file - lol). There simply was not enough RAM in the world for this memory hog.
I’m not really sad to see it go. It was another free toy of a big company that people used not to spend 60$ on real thing made by small company and waste thousands of dollars on lost productivity and time.
There's this editor called vim. You should have a look.
I recall trying Atom before VSCode had been released. I loaded up a 1MB XML file and it ground to a halt.
After some searching I found a bug tracker issue reflecting this, where one of the devs said something to the effect of "a 1MB XML file is extremely large, I don't think we'll support that".
At that point I uninstalled Atom.
On a related note, not long ago I accidentally dragged a 450MB SQL script into VSCode. I fully expected it to cave like Atom had on the 1MB XML. However to my pleasant surprise it worked just fine. Editing it was as quick as a regular file, and the memory usage was not excessive (around 2.5G total). I admit I was a bit impressed by that.
Sublime didn't even flinch when opening and navigating around the file. Truly impressive text editor and absolutely worth the license cost.
Most of those people are using Visual Studio Code today instead, although in comparison, VS Code is very bloated and slow.
For fun and giggles, here is a comparison of the Google popularity between Sublime Text, Visual Studio Code, TextMate, Vim and Emacs: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...
My daily driver editors for the last 20 years, in rough order, were:
* BBEdit
* TextMate
* Sublime
* emacs
I still fire up Sublime, but the longer I use org the better I am at general editing in emacs. It's a gateway drug. ;)
I don't need code complete, or a terminal, or extensions, or anything else VScode offers. I suppose now is a good time to write my own notepad :/
https://www.scintilla.org/SciTE.html
Is it just for people who want to avoid the CLI?
Atom provided the seed, excitement and vision for what is possible on this platform, and should be proud of that fact.
Atom provided the seed, excitement and vision for bloated Electron apps, and shouldn't be very proud of that fact.
I'm horribly embarrassed that I only just "got" that joke now
Did anyone else experience the something similar?
[0]https://tree-sitter.github.io/tree-sitter/
Farewell friend, you will be missed.
That's my experience exactly. I still haven't been able to configure VS Code to fully match the experience I want with respect to keybindings and subtle look-and-feel and functionality details.
Aside from the infrequent case of hanging when opening very large files I had no real issues with Atom and could have happily kept using it.
For what it's worth Pulsar (https://pulsar-edit.dev/) appears to be a community-maintained fork of Atom. (For that matter one of the primary Atom creators is working on https://zed.dev/.) But personally I got tired of swimming upstream and just caved to VS Code.
(I am a little tempted to go back to emacs, which was my editor of choice before Atom, but that's ends up being an enormous time-sink for me anyway.)
- The right side bar is "dynamic". Most of the time it's the Explorer showing the directories and files, but when I try to search for something, though, it becomes the Search sidebar. Same for all the potential sidebars (Source Control, Run and Debug, etc.)
- Everything is a plugin. That means I need to carefully check who's the author of the plugin, probably check as well the source code to avoid using malware, etc.
- Everything is a plugin. That means I need to craft a set of plugins in order to work in certain projects. I prefer JetBrain's approach
- No floating windows. Maybe I'm old-fashioned, but I prefer that, for instance, Settings to be opened in its own window, instead of opening a new tab in my editor. Also all the Settings in VSCode are on the same "page" (sure, whenever you scroll, the left-side grouping of Settings is updated accordingly, but imho it's difficult for me to focus on the section I need to work on)
Yeah it's just a tabbed view. I like it, saves space while staying useful. Maybe because most software I use has tabs already.
- Everything is a plugin. That means I need to carefully check who's the author of the plugin, probably check as well the source code to avoid using malware, etc.
True, but most popular languages have plugins authored by Microsoft. Some are from Red Hat. You'll miss out on GitLens and LaTeX Workshop, but VSCode with only trusted plugins is more than good enough.
> - Everything is a plugin. That means I need to craft a set of plugins in order to work in certain projects. I prefer JetBrain's approach
For Python, web dev, C++, etc., there's a "plugin pack" that depends on what you need to work.
> No floating windows. Maybe I'm old-fashioned, but I prefer that, for instance, Settings to be opened in its own window, instead of opening a new tab in my editor. Also all the Settings in VSCode are on the same "page" (sure, whenever you scroll, the left-side grouping of Settings is updated accordingly, but imho it's difficult for me to focus on the section I need to work on)
Sounds like you just don't like tabs? I find that the window list gets way too crowded and messy when I'm working on multiple projects with multiple tools. Tabs (in browser, explorer and editors) are a lifesaver.
I've gotten used to Visual Studio, where I can grab a tab and pull it out of the window to make it its own window. If you try that in VSCode, it'll just drop the file on the Desktop.
To get something similar in VSCode, I have to open a new window, drag the file over, then close it in the original window.
RIP
Multiple concurrent kernels, the ability to connect any .py file to any running kernel, sharing variables and imports across multple .py files, inline matplotlib output that persists on-screen and inline with the code even when running other code cells... the list goes on. I'm really fond of this setup. I use it daily--it's an essential component of my day job--and intend to do so for the foreseeable future. VS Code does seem to be the way of the future but there have just been too many friction points for me to leave Atom.
I don’t think it ticks every box for you, but have you tried Jupyter Notebooks in VSCode[0]?
[0] https://code.visualstudio.com/docs/datascience/jupyter-noteb...
I'm giving VS Code + its Jupyter extension a shot for now. It's significantly worse than Hydrogen, but I tried to make it a little less bad with a quick extension to auto-infer code blocks [0].
[0]: https://github.com/kylebarron/vscode-jupyter-python
It's breathed life into my love for programming, given how easy it is to just start executing code (sometimes I just use it as a calculator app since it's that easy and accessible)
I tried VSCode's equivalent plugin, but the UX was nowhere near as nice.