3 ms·

Maybe I'm just an outlier, but as a front end developer, one of the _last_ things I want to do is spend time hacking my tool chain. What gets me excited is del

Maybe I'm just an outlier, but as a front end developer, one of the _last_ things I want to do is spend time hacking my tool chain. What gets me excited is delivering new features and better UX to my users. Even a minute spent worrying about my development environment is a minute taken away from what makes me happy. Truth be told, my main complaint with VSCode and atom isn't really the non-native performance of Electron, but all the effort required to tweak, configure, keep plugins updated, replace outdated plugins with the latest and greatest, etc. Seems to be a microcosm of the entire front end tool chain these days. (First it was npm, then yarn, then back to npm; jasmine, no jest, now karma; LESS, SASS, postCSS; Babel, no webpack, what about parcel; etc.) Even though my current work is all Vue and Angular, with a backend that's little more than a REST facade for MongoDB, I still find Coda to be the best development environment available, and I continue to use it all day every day. Considering how strongly Coda was originally tied to the then-dominant LAMP stack, I think that's a pretty strong testament to the product. (Or perhaps just a testament to my stubbornness.) I won't buy the next version of Coda sight unseen, but it's hard to imagine what Panic might do that would keep them separated from my money.

deleted 7y ago
[deleted]
bobbylarrybobby 7y ago
What are you talking about? What tweaking? You just install extensions and they’ll auto update. You only need to configure things when you don’t like the default behavior. I haven’t touched my VSCode configuration in ages.
hombre_fatal 7y ago
You interpreted hackability = ability for you to spend your time hacking on it. But I think they were going for hackability = other people will be more likely to develop plugins. The lower barrier to entry is basically one of the major upsides of Atom/VSCode: their plugins tend to have cutting edge support. For example, iirc Atom was the first to have a good plugin for Elm lang (elm-jitsu). Meanwhile the Elm plugin for Jetbrains' IntelliJ came later as the result of the effort of two Microsoft employees spending billable time on the somewhat academic project. A better example is that the creator of elmx ("JSX for Elm") was able to create an Atom plugin for their basically experimental library: https://github.com/pzavolinsky/elmx#atom-integration https://github.com/pzavolinsky/elmx#atom-integration I also think this differs from "hackability" when used with Vim/Emacs which does mean "you will be hacking together your .*rc file" which is definitely not how I'd characterize VSCode/Atom.
h1d 7y ago
You sound like preparing to use VS Code is like preparing to get vim right for your use. VS Code is far easier. "Newest and greatest" can be achieved so easily, not sure what you're complaining about. The real strong point is it has strong community of plugins to fill your use case which Coda is missing.
computerex 7y ago
The counter to your position: You optimize your dev environment once, and it pays dividends. Relative to the return the initial cost of optimization is negligible. Especially when with editors like vim my configuration file is stored in github, so I can literally replicate my precise editor's configuration, with all my personal tweaks and plugins, in 30 seconds, on any computer with internet on it.

deleted 7y ago

[deleted]

bobbylarrybobby 7y ago

What are you talking about? What tweaking? You just install extensions and they’ll auto update. You only need to configure things when you don’t like the default behavior. I haven’t touched my VSCode configuration in ages.

hombre_fatal 7y ago

You interpreted hackability = ability for you to spend your time hacking on it. But I think they were going for hackability = other people will be more likely to develop plugins. The lower barrier to entry is basically one of the major upsides of Atom/VSCode: their plugins tend to have cutting edge support. For example, iirc Atom was the first to have a good plugin for Elm lang (elm-jitsu). Meanwhile the Elm plugin for Jetbrains' IntelliJ came later as the result of the effort of two Microsoft employees spending billable time on the somewhat academic project. A better example is that the creator of elmx ("JSX for Elm") was able to create an Atom plugin for their basically experimental library: https://github.com/pzavolinsky/elmx#atom-integration https://github.com/pzavolinsky/elmx#atom-integration I also think this differs from "hackability" when used with Vim/Emacs which does mean "you will be hacking together your .*rc file" which is definitely not how I'd characterize VSCode/Atom.

h1d 7y ago

You sound like preparing to use VS Code is like preparing to get vim right for your use. VS Code is far easier. "Newest and greatest" can be achieved so easily, not sure what you're complaining about. The real strong point is it has strong community of plugins to fill your use case which Coda is missing.

computerex 7y ago

The counter to your position: You optimize your dev environment once, and it pays dividends. Relative to the return the initial cost of optimization is negligible. Especially when with editors like vim my configuration file is stored in github, so I can literally replicate my precise editor's configuration, with all my personal tweaks and plugins, in 30 seconds, on any computer with internet on it.