[] Brackets

June 26, 2012 6:32 AM

Brackets - An open source code editor for the web
posted by Artw (58 comments total)

From what I'm reading it sounds neat, but I downloaded what I thought was the app, but the read me says it's not, so I went to where that said to go and got confused.

Needs something that says, download and run this!

I'm still looking for a good CSS editing app.
posted by cjorgensen at 6:47 AM on June 26, 2012 [1 favorite]

emacs does all that and more. And given that guile can run Javascript by translating it to scheme (inorite!), I bet you could even customize emacs in javascript-translated-to-elisp.
posted by DU at 6:50 AM on June 26, 2012 [4 favorites]

emacs does all that and more.

We're talking about editors, not OSes.
posted by kmz at 6:53 AM on June 26, 2012 [24 favorites]

This is still experimental and can only handle "whole" files, that is not dynamic or templated/partial files. Or so I read in comments elsewhere, haven't tried it msyelf. Waiting for an actual release.
posted by melt away at 6:53 AM on June 26, 2012

I know quite a few of the people working on Brackets, so I should probably be nice to them, but I think it's kind of an absurd idea on its face:

"Based on the principle that the best developers to build tools for web developers are in fact web developers ..."

This, to me, is like saying the best people to build cars are drivers. And if you follow that path, you end up with this.
posted by me & my monkey at 6:56 AM on June 26, 2012 [4 favorites]

If it's not modal, and doesn't support vi-mode, I'm not interested.

vi(m) is muscle memory at this point.
posted by namewithoutwords at 6:57 AM on June 26, 2012 [6 favorites]

emacs does all that and more.

This is technically a valid reply to almost any sentence a human being can construct.

"Here's someone doing the Lord of the Rings theme on a xylophone!"

"Eh, emacs does all that and more."
posted by Tomorrowful at 7:03 AM on June 26, 2012 [21 favorites]

Well, especially when you give easy examples. I mean, that's just the built-in M-x lotr-xylophone command.
posted by kmz at 7:06 AM on June 26, 2012 [14 favorites]

Hmm. Definitely checking this out, it will be hard to lure me away from my precious Sublime Text 2 but I'm liking the idea of extending this and making it truly unique so easily.
posted by jason_steakums at 7:10 AM on June 26, 2012

I know they're trying to be friendly, but it would be nice if they could explain what this is about in a direct way without all the "we call shenanigans" and "w00t!" and other cutesies.

If someone has a more concise read on this than they can provide, I'd be grateful.
posted by argybarg at 7:11 AM on June 26, 2012

emacs does all that and more

The two main features they seem to be touting as new or unique are inline CSS display (so that you can click on a tag in your HTML and it will show you any relevant CSS fragments in a pop-up window), and live browser preview (so that you can edit something and the changes show up instantly in the browser). Does emacs or any other code editor do either of those things?
posted by burnmp3s at 7:12 AM on June 26, 2012 [1 favorite]

More seriously, this does seem pretty interesting, especially the Quick Edit thing. But unless you're a designer doing templates or something this won't be useful until it integrates backend coding too.

And yes, vi control keys are a must. I have to use Zend Studio at work and the various not all that great Eclipse vi extensions at least make it tolerable as an editor.
posted by kmz at 7:16 AM on June 26, 2012

Yep. Sublime Text 2 has been luring folks away from many other editors.

I still consider it to be a bit incomplete and rough around the edges, but it's a really great cross-platform editor that basically came out of nowhere.
posted by schmod at 7:18 AM on June 26, 2012 [3 favorites]

live browser preview (so that you can edit something and the changes show up instantly in the browser). Does emacs or any other code editor do either of those things?

Emacs is famous for being the editor that Lisp hackers use and Lisp is famous for being what we would now call a "live coding" language. So...yes, in general.

If you wanted to show HTML in emacs, you could use w3m (I think there's actually more than one HTML rendering engine that's hooked into emacs). Otherwise, if you have fancy graphics or javascript or whatever, there's apparently another way. I used a 3D tool a few months ago that also touted a "live preview" feature but you could use an external editor with it. As soon as you hit save, it re-rendered. Presumably it's polling the filesystem.

I wouldn't be at all surprised if you could combine etags and buffer tricks to make an "inline display" thing and that someone's already done this. I don't use such a feature myself so I wouldn't know.
posted by DU at 7:22 AM on June 26, 2012

I don't have a dog in this fight, but the assertion that there's a lack of text editors aimed at programming seems oddly disconnected. Thinking only of obvious Mac candidates, there's TextMate, BBEdit and Coda.
posted by snuffleupagus at 7:28 AM on June 26, 2012 [4 favorites]

Yep. Sublime Text 2 has been luring folks away from many other editors.

I still consider it to be a bit incomplete and rough around the edges, but it's a really great cross-platform editor that basically came out of nowhere.

When I first saw Sublime Text 2, and saw the $59 asking price, I was very skeptical. And then I tried it, and man, so good. And it's fully functional without paying for it! Just nags you once in a while, and not like the awful nagware of old. And after getting some good use out of it, I'm really considering paying $59 for a fancy text editor. There are some things that I still like Notepad++ better for, but Sublime is maybe 90% of the way there.

The one thing it could really use is a good visual indicator on the tabs for saved/unsaved files. Right now it's just a big bullet point after the filename in the top bar to indicate unsaved.
posted by jason_steakums at 7:28 AM on June 26, 2012

Yep. Sublime Text 2 has been luring folks away from many other editors.

I still consider it to be a bit incomplete and rough around the edges, but it's a really great cross-platform editor that basically came out of nowhere.

Yeah, I'm right there with you. Combined with VintageEx (and the Vintage plugin) I managed to use Sublime Text 2 as my primary editor for a while. Lack of column select via C-v is a deal breaker for me, though.
posted by ndfine at 7:29 AM on June 26, 2012 [1 favorite]

It's strangely comforting to see vi/emacs jokes on mefi.
posted by tarheelcoxn at 7:46 AM on June 26, 2012 [1 favorite]

Emacs is famous for being the editor that Lisp hackers use and Lisp is famous for being what we would now call a "live coding" language. So...yes, in general.

The fact that you could extend it to do these sorts of things is not the same as them already being built-in. You could say that Eclipse or Visual Studio "does all that" if all you mean is that live code editing and inline code popups are possible to implement through plug-ins, macros or extensions that don't exist yet. Obviously emacs is more designed around being extendable and customizable than a lot of other editors or IDEs but the average web developer doesn't have the kinds of emacs hacking skills to roll their own solutions to these sorts of tasks.

I don't have a dog in this fight, but the assertion that there's a lack of text editors aimed at programming seems oddly disconnected. Thinking only of obvious Mac candidates, there's TextMate, BBEdit and Coda.

They seem to be more going for the IDE route (integrating debugging into the editor, parsing the code to put in refactoring type tools) and while there are plenty of IDEs that web developers use, they are mainly centered around backend or application development rather than frontend web development with HTML, CSS, and Javascript as the main focus.
posted by burnmp3s at 7:51 AM on June 26, 2012

Emacs? vi(m). Bloody youngsters, you need TECO

serious vi user here

:wq derail
posted by hardcode at 7:52 AM on June 26, 2012

Yawn yawn yawn boring boring YAFTE talk faster oh shiny!
posted by DarlingBri at 7:56 AM on June 26, 2012 [1 favorite]

..the average web developer doesn't have the kinds of emacs hacking skills to roll their own solutions to these sorts of tasks.

Isn't the premise of the video that you can extend your editor? And my original comment was about doing it in Javascript. As for "extending" emacs to support live-coding. It's been in there for a long, long time. SLIME has been around for 10 years and it's the new kid on the block.

But your general objection to "plugins and macros" vs having a feature built-in I just plain don't understand. For long term use, I'd much rather have an extensible program that does 75% of what I need than a program that does 100% of what I need (today only).
posted by DU at 8:06 AM on June 26, 2012

I'm not a user myself, but for those who are Sublime Text 2 fans, it's worth noting that it came out of beta today, so the full 2.0 version is now officially available.
posted by koeselitz at 8:08 AM on June 26, 2012

JavaScript is kind of a lisp-y functional language at its core anyway, right? Kind of like Scheme with curly braces. It seems like JavaScript : Brackets :: elisp : Emacs.

I'm almost tempted to submit a ticket complaining that Brackets doesn't have a working Tetris implementation.
posted by vogon_poet at 8:09 AM on June 26, 2012

And if you follow that path, you end up with this.

That's not what happens when you hire drivers to design cars. That's what happens when you a hire cartoon characters.
posted by Malor at 8:28 AM on June 26, 2012

Isn't the premise of the video that you can extend your editor?

Mere extensibility isn't enough. An editor needs to come with a certain amount of built-in functionality or else no one will bother with it. After all, one could simply hand someone a LISP interpreter and say "see, it's a text editor, you just have to extend it to your liking."

In this case, Brackets touts certain features like live-preview as a selling point over other editors.

As for "extending" emacs to support live-coding. It's been in there for a long, long time.

Yes, but not integrating it with a graphical web browser, per your comment. And it would have to be graphical; the kind of front-end web development this is aimed at is not text-oriented.
posted by jedicus at 8:36 AM on June 26, 2012

emacs does all that and more.

The extensibility/scriptability capability of Emacs is great, but to focus on that is to miss the point. Brackets is hosted inside the same tech that it's targeted towards developing. And that means overlapping magnification as you get better with either.
posted by weston at 8:37 AM on June 26, 2012

Isn't the premise of the video that you can extend your editor?

The premise of the video is that their editor will do the live editing and CSS pop up stuff, but that it's a work in progress and in order to get those features in they need developers to contribute to their open source project to make it happen. I don't think the point of the video is that eventual end users will roll their own versions of those sorts of features. The project seems to be more about making an easy to use editor like a lot of the popular text editors used today with some extra features while using HTML/CSS/Javascript to implement the editor itself.

But your general objection to "plugins and macros" vs having a feature built-in I just plain don't understand. For long term use, I'd much rather have an extensible program that does 75% of what I need than a program that does 100% of what I need (today only).

I'm not objecting to the idea of implementing useful features into existing IDEs or editors. I asked if emacs or other editors already had the features shown in the video, and I clarified that what I was asking was whether they already existed rather than asking if it was possible to implement them. If I was objecting to anything it was your "does all that and more" claim but from your more detailed comments you seem to be referring to the idea that it has the framework in place to do these sorts of things rather than that it literally has these features today so I'm not really disagreeing with you there.
posted by burnmp3s at 8:39 AM on June 26, 2012

Lisp is good for processing lithtth.
posted by Multicellular Exothermic at 8:53 AM on June 26, 2012 [1 favorite]

What vi needs is a clutch pedal.
posted by eriko at 8:59 AM on June 26, 2012 [11 favorites]

Google chrome immediately restyles a page if the css is locally stored and the file changes, no matter what editor you use.

mozrepl has similar functionality for gecko engine browsers, and comes with an emacs minor mode.
posted by idiopath at 9:03 AM on June 26, 2012 [1 favorite]

nb: mozrepl integrates with any "normal" UNIX tool, so it is also quite compatible with vi(m), and most likely ed as well.
posted by idiopath at 9:06 AM on June 26, 2012

What I'd really like to see is better autocomplete for javascript. It's obviously going to be more difficult then with statically typed languages like java. But if you're using JSDoc tags you are essentially using static typing. In fact eclipse can sometimes do some autocomplete if you use JSDoc tags but it doesn't work very well at all. (I think it's like: if you do var x = new Y() then it will tell you the functions in Y, but if x is the value returned by a function or a parameter it won't, but it's been a while since I looked at it -- it's basically pretty useless) Also, eclipse's javascript processor totally blows anyway, it will give you errors on totally valid code.

What I've found really does help with Javascript is google's Closure compiler, which works with JSDoc tags and actually does static type checking on your JS code. Debugging JS can be a pain and Closure will basically prevent tons and tons of bugs from ever happening in the first place.

Google chrome immediately restyles a page if the css is locally stored and the file changes, no matter what editor you use.

The Chrome developer panel is also really nice. You can view the DOM tree (the live one, including everything generated at runtime) and it will show you where on the page the element you're looking at is. And you can edit CSS properties in real time as well. So you can tweak a page really easily.

the average web developer doesn't have the kinds of emacs hacking skills to roll their own solutions to these sorts of tasks.

Or more importantly, maybe they don't have the time. I mean, if you have a project you want to get done maybe this live coding for HTML thing will accelerate that by a slight amount, but how much time would it take to code up a plug in for emacs to do so?

Also, having live preview of a LISP program is not the same thing as having live preview of an html page. I mean, come on. You can't substitute really a lisp program for a web app, so you can't really substitute live preview of a lisp program with live preview of a web app.

Anyway, that said I don't really know if having live preview or whatever is really important for web apps. How hard is it to save and reload? It wouldn't be worth it to trade integration with source control and having your web code synched up with all the rest of your project.

As for "extending" emacs to support live-coding. It's been in there for a long, long time. SLIME has been around for 10 years and it's the new kid on the block.

Again, being able to live code lisp is not the same thing as being able to live code javascript. How many web coders even know lisp? You can't script web pages in it. It's like if someone came up with a tool to fix a car, and you say "Well, you can just use X, it can totally fix bikes!" (There are some methods to embed lisp in HTML using interpreters or conversions and stuff, but the live coding in emacs won't help you view the output in a browser, as far as I know)
posted by delmoi at 10:17 AM on June 26, 2012 [2 favorites]

For what it's worth, just dittoing the love for Sublime Text 2. It doesn't do everything I'd like it to, but it does most.
posted by juv3nal at 10:20 AM on June 26, 2012

I'm using it right now. It's okay, but it's no Allaire Homesite.
posted by Artw at 10:22 AM on June 26, 2012 [2 favorites]

the live coding in emacs won't help you view the output in a browser, as far as I know

Not out of the box, and I don't want to imply that "arbitrarily extensible with a commensurately arbitrary amount of effort" coincides with "already has any feature you can name", but it'd actually be really easy to write a hook that invoked chromium or firefox with a URL every time you saved a CSS file -- they already play well with the idea of external processes opening pages in existing running instances of the browser. The only interesting part would be the design choices in associating the given CSS file with what URLs should be opened.

I'm basically with Yegge here that that's Emacs' biggest weakness today -- relatively poor web-technology awareness.
posted by Zed at 11:05 AM on June 26, 2012

Just started dipping my toes into node.js, and from what I can tell Brackets (+ a shortcut key to restart your node server) should be awesome for that. Javascript all the way down!
posted by jason_steakums at 11:27 AM on June 26, 2012 [1 favorite]

Actually, if some enterprising soul wraps up node.js + CouchDB + a js-based image editor + a package manager for frameworks inside Brackets, I'd end up *living* in that thing.
posted by jason_steakums at 11:37 AM on June 26, 2012 [1 favorite]

There was also some sort of light table preview release yesterday.
posted by Ad hominem at 11:59 AM on June 26, 2012 [2 favorites]

Lately, I've been playing with PhantomJS, which gets closer to making JavaScript into a command-line scripting language. Very neat.
posted by Blazecock Pileon at 12:03 PM on June 26, 2012 [1 favorite]

VS 4 lyfe!

It is chugging away indexing something or parsing something or hooking up intellisense as I type this, taking up 80% of my resources.

Oh VS, what would I do without you.
posted by Ad hominem at 12:31 PM on June 26, 2012 [1 favorite]

I am kind of missing VS a little now I'm doing other stuff - partially because I've now got task management, source control, bugs and actual development split up between different programs and keeping track of them is a pain, so the all-in-one approach of VS looks pretty good from here. It's a beast, but it's a beast that works.
posted by Artw at 12:44 PM on June 26, 2012

We don't actually use the tasks or bugs. It would be nice if we did. I love VS but it pretty much does what it wants. Try to build a large XAP? Guess what , out of memory! Try to view shelved changesets? Sorry man, not right now I'm indexing something.

I don't even use refactoring or code snippets. I click on Encapsulate and look at preview and it looks wrong and end up typing it myself. I gotta trust VS more I guess.
posted by Ad hominem at 1:04 PM on June 26, 2012

I just realized I've been using emacs for almost 20 years, my god.

I think burnmp3s has a great point, focusing on whether the features actually exist. I've never seen an emacs mode that would let you see what CSS applies to HTML elements as you edit them (that would be awesome!).

The concept of live coding is so basic that lots of apps support it in one way or another (emacs, Python, bash, Chrome, etc.) and the differentiation may come only in the details: E.g. how many keys do I need to press to make this code I just typed live? Is the live output display inside my editor somewhere, or is my editor inside the display?

I would love to see some smart integration between editors and the WebKit Inspector.
posted by jjwiseman at 1:49 PM on June 26, 2012

There was also some sort of light table preview release yesterday.

is that still just LISP?
posted by juv3nal at 2:15 PM on June 26, 2012

This would not be news had it not carried the Adobe name.

Just a small observation: developers of note do not write css and html any more, they're writing code in a myriad of dsl's (haml, sass, jade, stylus, scaml, etc.) that when compiled output the desired browser markup. Many even use Coffeescript over Javascript although the popularity of Node.js calls that into question. That people are still building websites using encapsulated html and css with some js modules thrown in for fun isn't a surprise as luddites remain strong but most development (worth paying for) these days is done using integrated server-client approaches and not your grandpappy's ftp to the server methodology, let alone live-coding from the browser. And most if not all will have a resource for refreshing not just the browser upon file editing but the server itself and alerting you to bugs in your code.

So a lightweight tool made for decade-old production techniques isn't really a contender for adoption.

emacs does all that and more.

Please.
posted by jsavimbi at 2:21 PM on June 26, 2012 [3 favorites]

is that still just LISP?

It's just Clojure.
posted by kenko at 3:27 PM on June 26, 2012

It's just Clojure.

I was actually looking into Clojure a while back and there are interesting web technologies for it. But they seemed to be geared towards the server side HTML generation (where you generate a clojure list representing your dom and then that gets converted to HTML). It was pretty interesting, but seemed very 'experimental'. There's also a version of clojure that runs in javascript, so you can actually write code in Clojure and have it run in the browser.

But, how easily can you use those technologies together? I don't know since I didn't really want to spend who knows how long trying to figure it out, since generating HTML in server side and modifying it with javascript is something I can already do.

The real question with adopting anything new is: Is the amount of time I'm going to spend learning how to use this going to be less then the amount of time it would actually save?

Live preview might be nice, but the amount of time I spend hitting ctrl+s, and then hitting the refresh button in the browser isn't very much to begin with.
posted by delmoi at 3:37 PM on June 26, 2012

Light Table promised to support Python if they raised 300k. They hit 300k so they are supporting Python.
posted by Ad hominem at 3:54 PM on June 26, 2012

Light Table promised to support Python if they raised 300k. They hit 300k so they are supporting Python.

Yeah, and they're going to support JavaScript as well. But so far it looks like they've just got Clojure stuff done.

But they seemed to be geared towards the server side HTML generation (where you generate a clojure list representing your dom and then that gets converted to HTML)

I think that's just a byproduct of the fact that almost every new hotness is web-oriented (afaict). But in principle you could use clojure for anything where startup time (since it's running on the jvm…) isn't a huge issue—it does have access to all those java libraries, after all.
posted by kenko at 9:46 PM on June 26, 2012

developers of note do not write css and html any more, they're writing code in a myriad of dsl's (haml, sass, jade, stylus, scaml, etc.) that when compiled output the desired browser markup. Many even use Coffeescript over Javascript

Bless anybody who's found increased productivity or joy from using any of those things (as I have, to some extent). But like a lot of claims of what "developers of note" do and don't do, this one is poorly founded. The convenience offered by these languages is largely in the realm of shorthand for the same semantics, and it runs from subjective to marginal for many cases. They also have their own overhead, and there are other ways of dealing with the problems they solve. They can be helpful tools for some apps and teams, but there's plenty of mileage to be gotten out of other tools or even plain HTML/CSS/JS.

If that weren't enough, though, in the context of discussing the relevancy of Bracket, it's an especially weak point. Implementations of all of these languages are well within the capability of JavaScript (where they don't *already* have JavaScript implementations, as CoffeeScript and LESS do), and are therefore pretty easy integration targets for a project like this.

although the popularity of Node.js calls that into question.

Not much more than the JS runtime in the browser calls into question the popularity of CoffeeScript; node is a target just like browsers are.
posted by weston at 11:16 PM on June 26, 2012 [2 favorites]

emacs does all that and more

Undoubtedly, but that would require using emacs, and noone rational would want to do that.
posted by kjs3 at 7:00 AM on June 27, 2012

You still need to know CSS to make SASS work. I wouldn't touch any "developer of note" who could only use those tools but stayed away from the underlying technologies with a very long poll.
posted by Artw at 9:28 AM on June 27, 2012

I feel like people talking about these alternative tools are missing (what I see as) the main goal of this project -- to close the circle between the code and the execution environment.

Most of the tools people have mentioned are basically about extending the coding environment toward the execution environment. For example, code analysis is largely about predicting what will be executed when a given line of code runs. Or tools like Coda will try to mock up CSS rules on a sample element.

The problem with these is that they aren't the execution environment. To know what CSS rules apply to an element, you need to look at the whole document. Or Brackets says it can find Javascript functions, but it doesn't seem work for the functions defined in a closure (which is really all of them).

Meanwhile, the tools within the execution environment itself -- the JS debugger, interactive stylesheet tools, etc. -- are evolving to allow deeper and deeper interactions in the live instance. You can change CSS rules, rewrite HTML, and redefine Javascript on the fly. But you still have to translate that back to the actual source.

For example, one nice convenience I use a lot is if you modify a CSS rule from within Chrome, it changes Chrome's version of the CSS source file, so you can just copy and paste the file back to the source code. But if you add a new rule, it doesn't show up anywhere (that I can see), so you can't just write your CSS in the live environment and seamlessly push it back to source files.

What would be really useful is to have the coding environment and the execution environment be one and the same. (Like every desktop IDE since forever.) You're tweaking live code, so you don't have to reload, but you're also tweaking source code, so you don't have to find and copy changes back over. That is what the end goal here seems to be.

Which is a laudable goal, but I'll believe it when I see it. Even in the simplest case -- tweaking some CSS rules -- when I'm tweaking a live instance in the browser I'll tweak whatever rule is most convenient, but to make changes in the source I'll look at the structure and semantics of my ruleset, and often my changes will be spread across several rules. (That's the point of cascading and inheritance.) And as some people have mentioned, this is ignoring entirely the strong likelihood that the content itself is being generated server-side.
posted by bjrubble at 11:17 AM on June 27, 2012

Implementations of all of these languages are well within the capability of JavaScript (where they don't *already* have JavaScript implementations, as CoffeeScript and LESS do), and are therefore pretty easy integration targets for a project like this.

Yeah, I noticed when looking at Bracket's own debugging window -- after my disappointment in realizing that this wasn't Bracket introspecting on the live browser instance -- that it uses LESS internally. It seems like integration here would be a snap.
posted by bjrubble at 11:22 AM on June 27, 2012

I would like to thank this thread for hipping me to Sublime Text, and reciprocate by pointing out the interesting semantic text-editor oddity that is Ulysses (and Daedulus, for iOS.) I can't say how suitable Ulysses and Daedulus are for heavy workflow, but I find them kind of fascinating to play with.
posted by snuffleupagus at 11:46 AM on June 27, 2012

(This is intended for creative writing, but using structured text such that it has coding aspects.)
posted by snuffleupagus at 11:51 AM on June 27, 2012

So, get this, I actually code web apps in clojure for a living (I am passing time between a support ticket for a specific web app and a feature request for our backend library at the moment).

I use emacs, which thanks to slime/swank integrates very nicely with clojure (automatic display of arg names in the echo area, quick lookups of definitions and callers, debugger integration, etc.). That there is a javascript implementation of clojure is interesting to me, and I wonder why I never heard about it before. My guess is that the lisp lovers around here are all on the back end, and the front end guys are just happy with plain javascript and sass (and seem to be mostly vim or textmate users, where using lisp is not nearly as easy).
posted by idiopath at 11:53 AM on June 27, 2012