Look out Sublime and Textmate ... here comes Brackets (stunning)(blog.brackets.io)
blog.brackets.io
Look out Sublime and Textmate ... here comes Brackets (stunning)
http://blog.brackets.io/2012/12/10/getting-started-with-brackets-video
29 comments
Good grief. Emacs and VIM use has actually been going down since the 90s as a percentage of the developer community, and no one is predicting that they will regain market share.
And back to the original article, live programming and rich editing experiences is the future; emacs and VIM will go the way of the typewriter and x-terminal.
And back to the original article, live programming and rich editing experiences is the future; emacs and VIM will go the way of the typewriter and x-terminal.
Emacs and VIM use has actually been going down since
the 90s as a percentage of the developer community
live programming and rich editing experiences is the future
"The quality of the developer community seems to have gone down since the 90s."
Really? Can you back this up? As it seems to me the community is more engaged, productive and delivering high quality code. Yes, there's a lot more bad code as well, but that seems to be proportional to the increase in developers.
Really? Can you back this up? As it seems to me the community is more engaged, productive and delivering high quality code. Yes, there's a lot more bad code as well, but that seems to be proportional to the increase in developers.
>The quality of the developer community seems to have gone down since the 90s. Maybe the OP should have stated "Eventually every great developer's editor search ends with vim, emacs or a management position." At least, this has been my experience.
To quote Jack Churchill (during WII) "any officer who goes into action without his sword is improperly armed."
> I was previously assured that VPLs were the future.
They are. Its just that we are getting the VPL features that we want (live programming and rich editing experiences) in editors for our textual languages instead.
To quote Jack Churchill (during WII) "any officer who goes into action without his sword is improperly armed."
> I was previously assured that VPLs were the future.
They are. Its just that we are getting the VPL features that we want (live programming and rich editing experiences) in editors for our textual languages instead.
And in my day penny sweats only cost a penny!
Right. Who uses terminals these days?! Except just about every developer I know.
I use terminals, but not dumb terminals. I use terminal emulators on a modern OS on which I am able to install any editor I want. I have emacs/vim installed, but I use them maybe once every few months. There are better editors for what I do.
Disclaimer: Every is defined as not including a lot of developers on Microsoft platforms, web developers, Java Enterprise developers etc ...
Parent did qualify that with "every developer I know." We tend to live in bubbles and don't see the big picture. Like "everyone I know programs in C++" is definitely true in some circles.
How many of us use x-terminals these days? I was referring to the hardware, not the emulation program. Perhaps parent lives in a world where they have a bunch of surplus DEC or HP X terminals and haven't moved on to PCs yet. Or perhaps parent just misunderstood my comment.
How many of us use x-terminals these days? I was referring to the hardware, not the emulation program. Perhaps parent lives in a world where they have a bunch of surplus DEC or HP X terminals and haven't moved on to PCs yet. Or perhaps parent just misunderstood my comment.
Maybe I did. Sorry about that. I meant terminal emulators available in most modern GUIs.
The Devs I know are predominantly on Windows, but they still use terminals. Some use CMD terminals on Windows, some use Putty on some remote Linux box. Some use Cygwin. And then there are a few Linux/OSX people who mostly use the graphical terminals native to their platform.
embedded...
[deleted]
>> Emacs and VIM use has actually been going down since the 90s as a percentage of the developer community
My Google-Fu is coming up short, i can't corroborate this. Can you provide any links to data confirming this claim up?
I took a stab at getting some stats by searching stack overflow / server fault / super user for vim questions, emacs questions, textmate and sublime, vim comes out top by a long way, emacs next, the other 2 are a rounding error.
My Google-Fu is coming up short, i can't corroborate this. Can you provide any links to data confirming this claim up?
I took a stab at getting some stats by searching stack overflow / server fault / super user for vim questions, emacs questions, textmate and sublime, vim comes out top by a long way, emacs next, the other 2 are a rounding error.
No surprise that there are lots of questions about VIM, it has a really sharp learning curve. You didn't include Visual Studio, Eclipse, IntelliJ, etc...which is a significant omission.
This is all informal and anecdotal, but I'll try to explain my reasoning/experience. In the mid/early 90s, you weren't really a great programmer unless you used a real text editor, so we would all eventually evolve into using Emacs (or VIM for the more daring). But then in 1997, Visual Studio got support for code completion (in VB), and Java and even C++ eventually followed. These language editors improved productivity for programming in those languages so much that it was hard to be competitive staying on Emacs. So perhaps most (~90%) of the Java/C#/C++ code written today is done with a well supported language aware editor (Eclipse, Visual Studio, JetBrains, ...).
Of course, if you are programming in a dynamic language, or a language with lousy tool support (C), then the language-aware editor doesn't really give you much (no static type system --> no static type feedback). There is a greater chance you are programming in Emacs (or VIM), but then you might not want to bother with the learning curve, or you might want something with a more modern non-ASCII UI, so maybe you are programming in Sublime or TextMate. There is nothing really wrong with this, you can be a great developer and prefer to avoid UX-archaic tooling, especially if you happen to also be a strong designer. There are strong trends away from text-based tools to visual tools, and I have no reason to believe that this isn't at play here.
The emacs community is vocal, and is particularly magnified in my field (systems/PL/PhD-level computer science) and demagnified at my place of employment (Microsoft, though keep in mind MSR has lots of Emacs/VIM users). But look at what the students prefer: they have no patience to learn these weapons from a more civilized time. They'll take whatever is the path of least resistance, and honestly who blames them!? Its not like they are losing much.
This is all informal and anecdotal, but I'll try to explain my reasoning/experience. In the mid/early 90s, you weren't really a great programmer unless you used a real text editor, so we would all eventually evolve into using Emacs (or VIM for the more daring). But then in 1997, Visual Studio got support for code completion (in VB), and Java and even C++ eventually followed. These language editors improved productivity for programming in those languages so much that it was hard to be competitive staying on Emacs. So perhaps most (~90%) of the Java/C#/C++ code written today is done with a well supported language aware editor (Eclipse, Visual Studio, JetBrains, ...).
Of course, if you are programming in a dynamic language, or a language with lousy tool support (C), then the language-aware editor doesn't really give you much (no static type system --> no static type feedback). There is a greater chance you are programming in Emacs (or VIM), but then you might not want to bother with the learning curve, or you might want something with a more modern non-ASCII UI, so maybe you are programming in Sublime or TextMate. There is nothing really wrong with this, you can be a great developer and prefer to avoid UX-archaic tooling, especially if you happen to also be a strong designer. There are strong trends away from text-based tools to visual tools, and I have no reason to believe that this isn't at play here.
The emacs community is vocal, and is particularly magnified in my field (systems/PL/PhD-level computer science) and demagnified at my place of employment (Microsoft, though keep in mind MSR has lots of Emacs/VIM users). But look at what the students prefer: they have no patience to learn these weapons from a more civilized time. They'll take whatever is the path of least resistance, and honestly who blames them!? Its not like they are losing much.
>> UX-archaic
Why then, in circa 40 years, have we still not managed to find a better alternative?
I can't help drawing parallels with windows / unix in the 90s and more so 00s. Yes, a point and click GUI is much easier to wing it with than a CLI, but, it doesn't deliver nearly as much power to the user as a proper CLI with a small number of reusable tools that can be composed to solve many problems.
To give a concrete example, if the GUI designer of your chosen deployment tool didn't imagine anyone would want to filter nodes to target a deployment by a substring of the node name, then you are out of luck - resorting to hacking your hosts file on windows to null route all the hosts you don't want to hit, followed by deploying to all nodes from the brain dead GUI.
With a proper CLI, only your imagination reduces your ability to solve whatever business problem (and they are infinite).
The net result of this shallow learning curve? We got a lot of people who refused to learn how to manage a network, winging it and being employed in positions of significance - average corp. with hopelessly leaky data safeguards and so on.
So back to the ux archaic editor, nothing has surpassed it despite 40 years of continual focus. While I wouldn't dismiss attempts to improve it out of hand (I'm a paid up customer of ST2), I also wouldn't count on an revolution relegating vim to the history books anytime soon.
As for VS, Idea etc. they are merely a chapter 11 filing away from being forgotten. Eclipse could live on. Who knows.
Why then, in circa 40 years, have we still not managed to find a better alternative?
I can't help drawing parallels with windows / unix in the 90s and more so 00s. Yes, a point and click GUI is much easier to wing it with than a CLI, but, it doesn't deliver nearly as much power to the user as a proper CLI with a small number of reusable tools that can be composed to solve many problems.
To give a concrete example, if the GUI designer of your chosen deployment tool didn't imagine anyone would want to filter nodes to target a deployment by a substring of the node name, then you are out of luck - resorting to hacking your hosts file on windows to null route all the hosts you don't want to hit, followed by deploying to all nodes from the brain dead GUI.
With a proper CLI, only your imagination reduces your ability to solve whatever business problem (and they are infinite).
The net result of this shallow learning curve? We got a lot of people who refused to learn how to manage a network, winging it and being employed in positions of significance - average corp. with hopelessly leaky data safeguards and so on.
So back to the ux archaic editor, nothing has surpassed it despite 40 years of continual focus. While I wouldn't dismiss attempts to improve it out of hand (I'm a paid up customer of ST2), I also wouldn't count on an revolution relegating vim to the history books anytime soon.
As for VS, Idea etc. they are merely a chapter 11 filing away from being forgotten. Eclipse could live on. Who knows.
Emacs is only about 30 years old (VIM is only 20 yro), I guess you are talking about text-based interfaces in general?
I'm not going to completely disagree with you here. There are lots of time I've found a shell to be useful, but I've also changed my workflow to minimize the amount of time I spend there. Learning curve for shell is steep, not shallow, but I've gone through much of that 20 years ago. If there is an old tool I can use to do something, I'm all for it, but if its a new tool, I'll go for the visual one with the lower learning curve, because I'm quite busy. Still, nothing beats shell for composability and flexibility, I definitely lose something with my approach. I find lots of promise in projects like Mozilla's Ubiquity, but I have a feeling the next step are actually Siri-like dialogue systems (whether typed or spoken).
But we are talking about editors that are used to edit code. I'll argue that language aware editors (in Eclipse, Idea, VS) have already greatly surpassed VIM/Emacs in terms of productivity, but then you could argue back that VIM/Emacs could re-support these features (and people have crammed them in at some points, though these have failed to stick). So let's just assume equal footing for now, and evaluate the experience. Given that we have a good understanding of the development process now, I'll argue that an IDE with high-discoverability of its capabilities is easier to use than Emacs/VIM which require substantial training to master. Now what Emacs/VIM give you is lots of power, but I don't think most of us need that. Heck, I've even moved away from Emacs for Latex programming, where the "build project/view PDF" menu option in TeXniCenter is good enough for me.
I'm not going to completely disagree with you here. There are lots of time I've found a shell to be useful, but I've also changed my workflow to minimize the amount of time I spend there. Learning curve for shell is steep, not shallow, but I've gone through much of that 20 years ago. If there is an old tool I can use to do something, I'm all for it, but if its a new tool, I'll go for the visual one with the lower learning curve, because I'm quite busy. Still, nothing beats shell for composability and flexibility, I definitely lose something with my approach. I find lots of promise in projects like Mozilla's Ubiquity, but I have a feeling the next step are actually Siri-like dialogue systems (whether typed or spoken).
But we are talking about editors that are used to edit code. I'll argue that language aware editors (in Eclipse, Idea, VS) have already greatly surpassed VIM/Emacs in terms of productivity, but then you could argue back that VIM/Emacs could re-support these features (and people have crammed them in at some points, though these have failed to stick). So let's just assume equal footing for now, and evaluate the experience. Given that we have a good understanding of the development process now, I'll argue that an IDE with high-discoverability of its capabilities is easier to use than Emacs/VIM which require substantial training to master. Now what Emacs/VIM give you is lots of power, but I don't think most of us need that. Heck, I've even moved away from Emacs for Latex programming, where the "build project/view PDF" menu option in TeXniCenter is good enough for me.
I use Sublime on Linux/OS X/Windows. Please tell me more about how my editor of choice isn't available everywhere? If you're a sysop, or a devop and you spend a non-trivial amount of time remoted to strange and random servers then learning vim or emacs is a good choice. Unless its a Windows server.
As a Linux user, as soon as you have SSH access to that strange server you can easily use gvfs to use sublime-text remotely, it's working great and is sooo simple to use..
It's probably not worth for a quick "let's change a setting in /etc/xyz" edit but it's worth it for everything else!
p.s.: i'm quit esure mac os x can do the same and in windows there is some third party app for remote ssh access/mounting.
It's probably not worth for a quick "let's change a setting in /etc/xyz" edit but it's worth it for everything else!
p.s.: i'm quit esure mac os x can do the same and in windows there is some third party app for remote ssh access/mounting.
I'm increasingly using Linux on ARM devices. Sublime Text 2's non-support for ARM has really been limiting its usefulness for me lately.
Could always ping the developers a feature request, they seem to like hearing from the community and reacting to people's needs.
There have been quite a number of requests for ARM support from the community already and the developers have, as far as I've seen, silently ignored them, which makes the situation even more annoying.
Emacs is perfectly capable of running on an ASCII terminal. I suspect Sublime is not.
I (and all the contributors to Brackets) respectfully disagree that a text editor released before the internet was available is the best we can do for web professionals.
We are really honored to be compared to Sublime and Textmate at this early stage. Those are fantastic text editors.
The purpose of the Brackets project isn't to replace those editors, but to inspire new ideas for web development tooling. It's simply a sandbox where the web development community can experiment with new ideas. Because it's written in JavaScript, HTML and CSS, everyone can get involved.
-Adam Lehman Brackets Product Manager
We are really honored to be compared to Sublime and Textmate at this early stage. Those are fantastic text editors.
The purpose of the Brackets project isn't to replace those editors, but to inspire new ideas for web development tooling. It's simply a sandbox where the web development community can experiment with new ideas. Because it's written in JavaScript, HTML and CSS, everyone can get involved.
-Adam Lehman Brackets Product Manager
> Eventually everyone's editor search ends with vim, emacs or a management position.
I respect the wit (a lot), but I'm not sure this the opinion you profess is really true of everyone in general.
I can type plenty fast and my muscle memory is kinda crazy insane... Notepad++ gets me everywhere I ever need to go.
I spend most of my time trying to write the least amount of code possible rather than worrying too much about what editor I use for writing my code.
Not trying to argue. Whatever floats your boat etc.
I respect the wit (a lot), but I'm not sure this the opinion you profess is really true of everyone in general.
I can type plenty fast and my muscle memory is kinda crazy insane... Notepad++ gets me everywhere I ever need to go.
I spend most of my time trying to write the least amount of code possible rather than worrying too much about what editor I use for writing my code.
Not trying to argue. Whatever floats your boat etc.
I have a feeling that we might add Sublime to that list at some point. It is cross-platform and easily extensible. I hope it can survive long enough to accumulate enough plugins and developers and be open-sourced at some point.
But that I'm an Emacs guy.
But that I'm an Emacs guy.
I hope it can survive long enough to accumulate enough plugins
AFAIK, text mate bundles can be dropped into ST2.
Nice, thanks for the info. That was a great move by the ST2 developers.
I think themes and snippets are compatible, but not full plugins.
Not sure that Sublime Text 2 fits with those other products you mentioned.
I recognize that anecdotes != winning PowerBall tickets, but I have never in my life met a user of Chocolat, Light IDE, or Cloud9.
But pretty much every Mac or Windows developer I know has ST2 at least installed (Linux, not so much (at least not yet), although it is available).
I recognize that anecdotes != winning PowerBall tickets, but I have never in my life met a user of Chocolat, Light IDE, or Cloud9.
But pretty much every Mac or Windows developer I know has ST2 at least installed (Linux, not so much (at least not yet), although it is available).
I use vi, emacs, iawriter, and sublime text fairly simultaneously. I love the iCloud support in iawriter (for short notes, etc.). I love sublime text for beauty. I use vi for config files or when things are going badly on a system. I use emacs by default.
I use Emacs, Vim and ST2 all the same, and most of the time, ST2 lets me do the same editing task with simpler keystrokes.
So my fingers don't look as busy as when using Vim, but I'm actually doing the same thing and postponing RSI.
So my fingers don't look as busy as when using Vim, but I'm actually doing the same thing and postponing RSI.
Yeah, Vim and Emacs are actively developed (I checked the repositories the other day, commits every day on both) and the communities are huge.
The editors are different, yes, but both brilliant.
The editors are different, yes, but both brilliant.
If vim actually supported other keyboard formats properly (rather than making the user redefine them from scratch) I would switch in a heartbeat. But until then, vim is useless to me.
The "sticking around" argument is weak. It applies equally well to Windows, Office, the System 360 line of computers and plain old telephone service.
ST2 seems to be sticking around so far, it's not the author's fault that it's new.
How hard would it be for someone to build and IDE (with nice code browser, refactoring and all the smart stuff... like JetBrains products) on top of or incorporating an editor like Sublime or Textmate?
I'd pay an arm and leg for IDEA or PyCharm with Sublime as the text editor (or something else with multiple cursors and all the "shiny" editor stuff), and the ability to launch either the full IDE or just the editor and be able to share editor settings, depending on what I'm doing (eg. the IDE for browsing a huge codebase or just the editor for working on a small project)...
I can even think of a business idea: 1. make awesome open source editor (Sublime text with optional Vim keybindings is awesome enough for me) 2. build smart IDE on top of it (what I expect from an IDE are things that require "understanding the code", ie. lots of language specific features, refactoring and tools integration, nice looking tree code browser etc.) 3. profit!!! (imagine that you'll also profit from the evolution of the open-source editor and from the "complex" IDE features you develop, at the same time! and the "IDE haters" that will just use the editor would use or recommend the IDE whenever they would need to navigate an ugly codebase or recommend something to someone else)
I'd pay an arm and leg for IDEA or PyCharm with Sublime as the text editor (or something else with multiple cursors and all the "shiny" editor stuff), and the ability to launch either the full IDE or just the editor and be able to share editor settings, depending on what I'm doing (eg. the IDE for browsing a huge codebase or just the editor for working on a small project)...
I can even think of a business idea: 1. make awesome open source editor (Sublime text with optional Vim keybindings is awesome enough for me) 2. build smart IDE on top of it (what I expect from an IDE are things that require "understanding the code", ie. lots of language specific features, refactoring and tools integration, nice looking tree code browser etc.) 3. profit!!! (imagine that you'll also profit from the evolution of the open-source editor and from the "complex" IDE features you develop, at the same time! and the "IDE haters" that will just use the editor would use or recommend the IDE whenever they would need to navigate an ugly codebase or recommend something to someone else)
They're definitely working on it. I know the JetBrains folks are working very hard to integrate the editing systems of something like emacs / sublime into their IDE.
I'll ping @intelliyole on twitter to respond.
https://twitter.com/mahmoudimus/status/279494119431217153
Update:
For now, what I do is use an external command that pipes out the buffer to Emacs and I use Emacs to slice and dice - then I just C-c # out of Emacs and switch back to PyCharm and keep on coding.
I'll ping @intelliyole on twitter to respond.
https://twitter.com/mahmoudimus/status/279494119431217153
Update:
For now, what I do is use an external command that pipes out the buffer to Emacs and I use Emacs to slice and dice - then I just C-c # out of Emacs and switch back to PyCharm and keep on coding.
First of all, it's far, far easier to write a plugin adding the "shiny" editor stuff to an IntelliJ Platform-based IDE. As far as the editor features are concerned, the only stuff Sublime does that would be non-trivial to implement in IntelliJ-based IDEs is multiple cursors - but it's still far less work than building an engine for all the smart stuff.
Second, all the smart stuff has performance costs. As soon as you're building a complete model of the codebase and updating it in real time, you're losing all the low CPU/memory usage benefits of a plain text editor.
Really, the only aspect in which we fell the pain of not being native is font rendering on Linux (which has a crappy implementation in AWT and there's little we can do about it). Other than that, it's not a problem at all to integrate as many editor features as you like into a JetBrains IDE.
Second, all the smart stuff has performance costs. As soon as you're building a complete model of the codebase and updating it in real time, you're losing all the low CPU/memory usage benefits of a plain text editor.
Really, the only aspect in which we fell the pain of not being native is font rendering on Linux (which has a crappy implementation in AWT and there's little we can do about it). Other than that, it's not a problem at all to integrate as many editor features as you like into a JetBrains IDE.
Oh man I agree whole-heartedly. Let programs do what they're already good at. PyCharm is good at managing things and being a general IDE, and Sublime is fricken awesome at editing text.
Both try to dabble in eachother's realm, but the places where they shine should be inter-operable, not combative.
Both try to dabble in eachother's realm, but the places where they shine should be inter-operable, not combative.
> (or something else with multiple cursors
IDEA supports multiple cursors, actually, ;).
As for IDE support, I find Sublime text extended with a few key plugins to be just as good as a proper IDE when it comes to (in my case) front-end development; JS checking with JSHint, syntax highlighting for html/js/less, quick HTML using ZenCoding, andsoforth.
IDEA supports multiple cursors, actually, ;).
As for IDE support, I find Sublime text extended with a few key plugins to be just as good as a proper IDE when it comes to (in my case) front-end development; JS checking with JSHint, syntax highlighting for html/js/less, quick HTML using ZenCoding, andsoforth.
...what?!
Care to enlighten me about how to enable or use this? (yes, it finally got column mode editing, but it is far from true multi-cursors, ctr+click in 3 different random places, even two of them on the same line and then move around, expand/contract selection to scope and do zen-coding tricks to them at the same time - yes, it's functionally equivalent to a refactor or a search and replace, but these alternatives break the "don't make me think!" philosophy of true multi-cursor editing that I consider the biggest advantage)
Care to enlighten me about how to enable or use this? (yes, it finally got column mode editing, but it is far from true multi-cursors, ctr+click in 3 different random places, even two of them on the same line and then move around, expand/contract selection to scope and do zen-coding tricks to them at the same time - yes, it's functionally equivalent to a refactor or a search and replace, but these alternatives break the "don't make me think!" philosophy of true multi-cursor editing that I consider the biggest advantage)
There's a Steve Yegge rant on that topic. It would be much easier to add first class support to a language if its implementation exported the internal data it creates from running/compiling the programs.
Without it, we are left with hacks, or lots of work for every new language, like Eclipse, which Yegge says has 3 Java compilers inside.
Without it, we are left with hacks, or lots of work for every new language, like Eclipse, which Yegge says has 3 Java compilers inside.
There are some fairly awesome Vim plugins out there for various IDEs. In fact, I would consider their availability a great feature of Vim!
I just skimmed the long video..
The good: auto-refreshing preview of HTML page upon save
The bad: no auto-end-brackets or end quotes as one types (ironic, considering the editor is named Brackets)
I am sure that the talented Adobe engineers will make this editor a major contender for Sublime and Textmate in the future, but at this point, I think the stunning attribute in the post title is a bit link-baitish. I'm looking forward to watching the editor develop into a mature product!
The good: auto-refreshing preview of HTML page upon save
The bad: no auto-end-brackets or end quotes as one types (ironic, considering the editor is named Brackets)
I am sure that the talented Adobe engineers will make this editor a major contender for Sublime and Textmate in the future, but at this point, I think the stunning attribute in the post title is a bit link-baitish. I'm looking forward to watching the editor develop into a mature product!
The link bait was mentioning HN's 2 favorite editors. Especially since we've discussed brackets several times before: http://www.hnsearch.com/search#request/submissions&q=bra...
I always thought that HN's two favourite editors were VI and EMACS...
Vim and Emacs are very probably HN's two favorite editors, not sure why he said that.
I thought it was a joke.
Yes, you are correct! Egg on my face for not noticing the earlier mentions. Unfortunately for the army or Bracket promoters, substance really matters within the technical community. One can't market their way into product adoption with an inferior technical product in this community.
Well, it certainly looks nice, but seems limited to mostly front-end web development work. I don't think Sublime and Textmate have anything to worry about for the foreseeable future.
I saw this one a while back (a couple of weeks, I think). While it looked nice, I didn't "get it" - why would I use an editor that is severely limited (only HTML/CSS/JS) when there are other editors out there that supports pretty much everything?
Sure, you can "improve" (read: mess up) the editor by changing it's source code - but I still don't see the point. I'm using Sublime Text 2, with it's package manager. Everything I need is a few key presses away, and there's usually no need to restart the editor after installing something.
Also, I'd never use an editor that didn't support remote sync on save, version control, etc. (Managing component source code outside of the webroot makes it so much easier to handle in git.)
Sure, you can "improve" (read: mess up) the editor by changing it's source code - but I still don't see the point. I'm using Sublime Text 2, with it's package manager. Everything I need is a few key presses away, and there's usually no need to restart the editor after installing something.
Also, I'd never use an editor that didn't support remote sync on save, version control, etc. (Managing component source code outside of the webroot makes it so much easier to handle in git.)
It's quite misleading. Sublime and Textmate support lots of languages whereas as far as I can see Brackets is only for HTML/CSS/JS.
Also its not cross-platform. And those plugins in compressed js gave me shivers.
Is "stunning" the new "beautiful," "great," or "awesome"? I can't even bring myself to click on such a baity title.
Product demo videos don't usually hold my attention ... but I was riveted for the full 20 mins (full credit to both the product and Jeffry Way). Downloading the repo now.
This looks interesting but what is more interesting to me is the brackets-shell, which looks to be a chromium shell for running an HTML/JS app as a native application. It looks to be very minimal and would just be fantastic for creating desktop apps. Every one of the existing solutions I've checked out so far all kinda suck in some way.
I hadn't realized that was working yet. I saw the repo for the shell itself is here https://github.com/adobe/brackets-shell - it seems almost like a lightweight version of AIR. Does anybody have any more information on this..?
I hadn't realized that was working yet. I saw the repo for the shell itself is here https://github.com/adobe/brackets-shell - it seems almost like a lightweight version of AIR. Does anybody have any more information on this..?
This is in no way a threat to native editors.
What is the auto-refresh going to show me when working on a Python or Ruby... or actually any non HTML file?
I noticed that the Emmet extension added keyboard shortcuts like "Command+Up". But that's a standard OSX text entry navigation shortcut! Why would you do that?
Can i just get this theme for sublime text while I wait for this project to mature?
Looks neat features. But I write neither HTML nor CSS on a regular basis. Does it offer anything for non-web programmers?
Here's the important link for anybody else who downloaded this and then thought "Damn, I fell for yet another link bait post for some halfassed unfinished edito--HEY, what a great font!!".
https://github.com/adobe/Source-Code-Pro/downloads
https://github.com/adobe/Source-Code-Pro/downloads
Have you forgot [sacrasm] tag?
No.
Do you mean that you weren't impressed with the font?
Or that there was something of value that I missed in this self-descriptive blog announcement of yet another pre-alpha release of an experimental text editor?
EDIT: Modern after-the-fact typo correction, be damned! Self-descriptive not 'self-deceptive'...
Do you mean that you weren't impressed with the font?
Or that there was something of value that I missed in this self-descriptive blog announcement of yet another pre-alpha release of an experimental text editor?
EDIT: Modern after-the-fact typo correction, be damned! Self-descriptive not 'self-deceptive'...
This has been around for a while now, I used it a few months ago, and while interesting it didn't do anything I don't already do with Sublime and other tools. Someday it may do those things more easily, but for now, I don't see any significant reason to switch.
Is it me, or are they trying to hide the Brackets / Adobe relation ?
We aren't trying to hide Adobe involvement with Brackets, but it's very important to recognize that this isn't "Adobe Brackets", it's just "Brackets". This is a community driven project. Adobe is just the benefactor.
I think that putting Adobe's logo / name next to everything would overshadow all the work and contributions from the community.
-Adam Lehman Brackets Product Manager (at Adobe)
I think that putting Adobe's logo / name next to everything would overshadow all the work and contributions from the community.
-Adam Lehman Brackets Product Manager (at Adobe)
I don't think so. There's some Adobe heavyweights involved with the project.
The flipside is Twitter Bootstrap, which was never an "official" Twitter project.
https://medium.com/what-i-learned-building/b95033c270af
The flipside is Twitter Bootstrap, which was never an "official" Twitter project.
https://medium.com/what-i-learned-building/b95033c270af
It says right on the home page that it's maintained by Adobe & the github repos are all maintained by Adobe as well. Just curious, do you think Adobe has a bad reputation for making software that would make them want to dis-associate with the company?
Personally, I think Adobe has a bad reputation for making software. Flash, Dreamweaver and Acrobat comes to mind.
Flash - Difficult to work with (I know most beginners struggle with it). Dreamweaver - Bloated software that generates weird HTML code. Acrobat - Slow and bloated software. Can't a PDF reader be simpler ?
But as adrocknaphobia pointed out 'this isn't "Adobe Brackets", it's just "Brackets"'. Turns out there's no hiding after-all.
Flash - Difficult to work with (I know most beginners struggle with it). Dreamweaver - Bloated software that generates weird HTML code. Acrobat - Slow and bloated software. Can't a PDF reader be simpler ?
But as adrocknaphobia pointed out 'this isn't "Adobe Brackets", it's just "Brackets"'. Turns out there's no hiding after-all.
It's stated clearly on the front page, line two of the first paragraph. How is that hiding?
I doubt I'll be leaving vim for this anytime soon. More interesting would be if they could extract a framework for doing cross plattform desktop apps with html/css/js from this.
Sublime does everything I need, it has Vintage mode if I ever decide to screw my brain up further and is cross platform. What else do I need?
Sublime + LiveReload does basically the same thing.
I feel so conflicted whenever I see any new editor, ide or environment setup, since I instinctively want to check it out and get excited, but I know that I will likely never leave vim. Light Table in particular has a bunch of ideas (I mean the theoretical best case scenario stuff, I haven't given the alpha a good look) that I wish I could see myself using.
I know I am a minority, and I am not very likely to switch to a new editor anyway, but I'd like to point out that not everybody watches videos. And if it absolutely has to be a video, why not make it work without flash? I'd have to switch browsers to watch the video, and since I don't even like watching videos, I just won't check out this amazing new editor.
Since the blog is loading slowly, direct link to the video:
http://youtu.be/HZkrlX7jJcg
http://youtu.be/HZkrlX7jJcg
I stopped at "you can edit the editor's source code in HTML/JS/CSS" For me personally, I want the best native editor I can find that makes doing my job easier/simpler - I don't want an editor that I can tinker around with its source code and accidentally shoot myself in the foot.
If you're afraid of shooting yourself in the foot, don't edit the source code.
Linux support should be a first class citizen IMO.
I'm not too impressed by the editor. It's like a less mature and worse version of cloud9. The only neat thing was the inline tag-based css editing window but I wouldn't switch editors just for that.
I'm not too impressed by the editor. It's like a less mature and worse version of cloud9. The only neat thing was the inline tag-based css editing window but I wouldn't switch editors just for that.
SENSATIONALIST TITLE! This seems great for web dev, but Sublime is just killer for Python, I don't see this making any editor 'look out' if you spend most of your time in a backend language.
Hopefully Sublime Text's developers aren't following the Textmate precedent:
1. Make awesome software
2. Profit!
3. Party while software languishes (pure assumption)
4. FailIf it doesn't run in a terminal I probably can't use it.
Vim. That is all.
Vim. That is all.
I was (stunned).
If a new decent editor shows up, it wont be shiny, it wont grab headlines on HN with a fancily designed website, it will simply grow popular slowly, be added to package managers across platforms after withstanding the test of time. The test of more than one person or just a few developing it and then moving on to something else.
With vim and emacs you're guaranteed to not be wasting your time learning their arcane ways. Long after humans have left the Earth someone will be reprogramming a couple of launch tubes on their trans-stellar space vehicle with vim. They wont be using this fluff from Adobe.