The moment I saw brackets, I fell in love with it. I really saw it as an opportunity to replace SublimeText, so I went with it. I tried the Sprint 35 version on Ubuntu 12.04 x64, and my PCs performances are well over the minimum requirements.
Unfortunately it turned out to be very slow, I opened an existing project I am working on, where my JS files were not larger than 500 lines / file. The cursor is lagging, literally, when I press the "down arrow" for instance, the cursor disappears, then I stop pressing it and it reappears somewhere below.
Scrolling had the same effect, just as well as changing the currently opened document, it all takes time, the amount of when you feel that something is not right.
At first I had a couple of extensions installed, so I threw them all out, but it didn't change a thing.
I would really like to use brackets, it's concept/idea really works for me, but until it gets faster I simply can't . Looking forward to the next sprint, I hope things will change.
The deal-breaking problem I have under Linux with editors based on node-webkit like Brackets and Light Table -- for some reason they don't use subpixel rendering, making all text extremely blurry. Maybe it's that issue https://github.com/rogerwang/node-webkit/issues/734, but I'm not sure. Anyway, I am not aware about any workaround, and just can't use them in their current state.
Brackets is not based on node-webkit. Brackets is based on CEF3 which is a API exposing library that uses Chromium. Node-webkit uses Chromium as well. So it's most likely chromium that is the issue.
That looks like a hinting problem rather than a lack of subpixel rendering.
EDIT: Or rather, it's both, but if you can't fix one you might want to try the other. Personally I've always preferred strong hinting and greyscale anti-aliasing to soft subpixel rendering.
Frontend developers? Isn't a very weird workflow, you first design your page in Photoshop or whatever, then you build out the page in css and html, then you break the page up into templates to be integrated in your app.
If you're a full stack dev, then it might happen that you do all these steps at the same time, so you never work on pure html, but if you're not I imagine this is how you work.
We use bog standard HTML with custom data- attributes (whose intention is pretty much obvious) and our binding library automagically populates it. So the learning-curve for people joining the project is basically... "do you know HTML?"
Want a span to show the live content of foo.bar.baz? <span data-source="foo.bar.baz"></span>.
great idea here. love it. is there an example out there of these 'bindings' that somebody with strong html / css but weak javascript skills would be able to grasp and implement into a site?
Our system is intentionally much simpler than this -- the idea being that if it becomes like a "language" people will do stupid things in it that need to be debugged.
We're supposedly open-sourcing our codebase (it's for a Federal government project) but the process of deciding the licensing seems to be interminable (yes, shocking I know).
I've gotta agree with you here. If you are a professional developer and are still writing non-templated html, I'd be surprised. I think it's crazy that all these tools keep coming out for handling vanilla html and css, while the development community is busy shooting miles ahead with far more powerful preprocessing. I'm working very heavily on convenience tools for advanced dev workflows, hopefully these will bring a similar level of excitement for devs who preprocess.
On big projects I work on, front-end developers start from the PSD and do the HTML first (they just do some templates, not the whole site obviously).
Then the JS is either made by them (depending if they know JS) or by a JS specialist.
Then the programmers integrate the HTML in the "code/templates" (CMS, whatever).
We develop in different web technologies and front-end developers don't learn how to code server side code (either they don't want to, don't have time, whatever).
Depending on the templating engine and programming language and final product (CMS, etc), they can or cannot edit or fix their CSS right in the final code.
Sometimes they need the programmers to tell them where the templates that they want to change are, etc. Imagine a big projects with hundreds of different templates made by a programmer, the front-end dev doesn't necessarily know where to change his stuff and if he's going to cause a problem elsewhere.
Front-end developer here. Yes, that is what I do. We have some really talented developers who design some awesome images of what the websites should like. (Hopefully as a photoshop file. Or at least, something that let me get exact measures and layers.)
If it's a small project, made to be beautiful, they will do the whole design of all the pages. If it's a huge Agile project, they would instead give me a style guide.
Then, I quickly turn everything into reusable HTML blocks and do the CSS (using LESS). If needed, I'll make custom jQuery (or pure Javascript, but that never happens, really) modules for the template. It's very quick. A full page templates takes me about 1 to 2 hours, if it's very, very complex I may take up to 4 hours.
While I'm working on those, the back-end guys are working of making the CMS work correctly. Sometimes, I give them the templates before they program the page, but most of the time I end up attacking the page after them. I then simply use the building blocks they gave me (and turn all the divs they made into the right HTML5 tags).
We use a lot of different CMS and some of the websites have custom backend (no CMS). We develop in both PHP and .Net.
I know PHP, and I'm comfortable developing Drupal websites. However, I don't get a lot of fun making the backend. The only time I would do it if we are working on a one pager or something like that, since it's faster if I do both back and front for project that are not complex.
I prefer working on the front-end. And I do mean front-end development. Not simply mindlessly slicing a PSD into an HTML page or adding content from a Word document.
I'm sure it wouldn't be a stretch to write an extension for Brackets that allows you to handle templates more effectively.
On another note, you'd be surprised how many people are still doing pure vanilla. Preprocessing isn't usually part of a beginners toolchain, you gotta learn the underlying part first before you start grafting on the preprocessors used in larger projects.
We've actually stopped using all pre-processor for everything we do for Segment.io[1] as well, and we're not beginners.
One of the biggest problems with them is that you immediately eliminate a huge portion of the people who are willing to contribute to your code if you select a pre-processor they aren't fond of. It's fine for app internals, but for sharing small[2] open-source[3] components[4] it's not a good idea—whether it's Sass or CoffeeScript or Jade or whatever.
The other problem with CSS pre-processors specifically is that they only work well with the monolithic app mindset. All of your CSS files inside the same `styles` folder, and all of them required by the "top of the monolith" `main.sass` file. Instead, using something like component[5] you get true dependency trees, so you don't have to go monolithic anymore. And trying to get Sass to work across a component-ized codebase is a real pain. Instead we use Myth[6] to "post-process" the built CSS.
Pre-processors are a leaky abstraction that comes back to bite you at random points the way all leaky abstractions do, and the ways are usually hard to foresee and thus hard to argue against when the benefits seems so clear.
The build script can handle each component separately and stitch the results together. Just because SASS/compass encourages a monolithic style doesn't mean it's necessary.
Front-end-wise, if you are jumping between projects, it's often easier to just build a static 1page of what you are trying to build instead of having it run through some kind of framework.
If you have an established project, then sure, you probably already have your views setup.
It would be really cool if Brackets could detect that you are working on a partial and inject that back into the page somehow
There's still a lot (a lot) of folks (non-startups) who don't do everything soup to nuts so they outsource things like the design and development of the front-end to outside shops. These folks tend to build out the HTML without any CMS integration then delivery the full HTML for the client to integrate into their CMS/tools/templates.
"Who actually writes non-templated HTML any more?"
Me.
My martini untemplate engine is a code generator that inputs HTML and outputs Java.
This creates a one-way flow of work. Designer creates the HTML, I create the backend. When the design changes, the backend (e.g. data binding) breaks during the generation and compile steps. Not in the browser.
Martini isn't ready to demo yet. It will be open source. But documentation and examples take more time that I have right now. Sorry.
I find it much easier to pixel-hawk and correct layout issues when I save an offensive generated page and then edit it in an HTML editing environment (Lighttable is good for this with JS/CSS weirdness as well).
I can do the same with the various web dev plugins, but I rather like being able to save the intermediate result and not have to worry about a refresh changing the underlying state of my view.
Any time I've ever written HTML (which hasn't happened often) it's always been in a text editor, raw. Then again, I'm clearly not exactly a web developer.
For one, everybody who designs the original HTML to be templated. Some start with a PSD and then do a full HTML page, others start directly by doing a full HTML page. Only AFTERWARDS its made into a template.
Second, ever since Enhydra (Java) and TAL (Zope) at least, there have been template engines that use full, plain, HTML code, marked with special attributes (repeat, inject value here etc).
I do code in an separate enviroment. Only HTML/CSS and LESS. No assets compilations, no rails requests, just heel in all his power. It's confortable and faster than anything and it's a good way to develop in an abstract way.
I downloaded the editor about two weeks ago. It's fun and easy to use. My only criticism is of the live editing feature.
That's what drew me to the editor in the first place, but it seems to be very buggy. It stops updating the preview sporadically — and predictably, each time I open the JS Console.
As a front-end dev, I can't really count on a preview that doesn't function with developer tools open.
Having said all that, I understand that Brackets is relatively new, and it takes time to iron things out. I will keep up-to-date with their progress and consider using the service in the future.
It's a bug (design decision) of Chrome. Only 1 debugger can be attached to Chrome at any given time. So if you have Brackets live preview enabled, you cannot use the developer tools within chrome.
This is an issue with other tools that try to attach to Chrome to do this type of work. Sadly, Chrome doesn't see it as a big enough issue to fix.
The problem is that one of the clients to be kept in sync is the dev tools itself. Currently the dev tools assume no one else is using the API, so there's significant work on the Chromium side to make them able sync up with changes caused by other API usage.
Glad to hear you found Brackets fun and easy to use.
As mentioned by kyrra, this is an issue with Chromium. We do have plans to change our communication with the browser to fix this (and other problems... like being Chrome-only!), but that's one of many things on the list.
I've been using Brackets to prototype things for al out a year and love it. I design in code much more often than in Photoshop or InDesign or whatever, and Brackets is super useful for that.
I tried to get Sublime Text to do the same thing, live updating, and even found a plugin that mostly does the trick. But it required a lot of setup each time I used it, and still wasn't as good as Brackets.
Brackets has issues, it's slower than a "text editor" ought to be, and the general editing tools aren't nearly as developed as Sublime, but for rapidly producing visuals and designing in real-time, it's stellar.
If any of the Brackets team is reading this .. THANK YOU ! For one of the most ergonomic editors I've ever used. I really can't explain it any other way, but everything just is where I expect it to be. And I was really surprised at the JavaScript auto-completing !
My plugin setup is only to add jsbeautify and JSONLint.
If I may ask the author(s): what was the motivation of writing this app for native platforms but making use of webkit-node or similar technologies and tools? This to me seems like it has become a popular technique for writing cross-platform applications, but it also seems like it has many drawbacks which make it an unattractive option, with the only advantage being that the authors already know CSS/JS/HTML and can leverage that knowledge to make a protoduction-quality application. Can you confirm that this is the case, or was there some other reasons and/or factors that led to such a decision? Thank you for your time, and have a relaxing evening.
I wasn't there at the beginning, but I've been working on Brackets for a year.
We want Brackets to be awesome for web developers and designers specifically. So, how cool is it to be able to extend the editor you use every day using the exact same tech you're already used to? (And, of course, you can edit Brackets extensions in Brackets...)
This is likely part of the reason there are more than 200 extensions available for Brackets today.
> Please don't do things to make titles stand out, like using uppercase or exclamation points, or adding a parenthetical remark saying how great an article is. It's implicit in submitting something that you think it's important.
> Otherwise please use the original title, unless it is misleading or linkbait.
What an incredibly strange trend that I keep seeing lately of externally using sprint numbers as version numbers. Actually labeling them as Sprint numbers prominently, I mean, instead of just v35 or v.35 or something.
Funny you should mention that, because we're actually changing from Scrum to Kanban so we do not have sprints in the same sense that we had them before.
I think this numbering was started because Brackets is "pre-1.0". We'll see how our version numbering changes after we release 1.0 :)
With so many transpiled JS languages, this seems like a tough space to be in. I wouldn't use this until it works with CoffeeScript. My friend won't until it works with ClojureScript, etc. Maybe there's a simple solution I haven't thought of? But it seems like the inline editors would be modifying the generated source instead of the actual source.
As a dirty prototyping pseudo-dev, the one thing that keeps me using Coda is its native ftp/scp capabilities. I can open files on a remote server as if they were local and command-s saves them back there.
Right now it seems that none of these other editors support that function. I know I can run ssh-fs or similar, but that requires much more setup.
I mount drives and use them with whatever IDE. The big problem for me is that if someone else changes a file, then often the text editor doesn't notice... but that's pretty much the case with text editors+ftp. But most ftp programs let you open files in whatever program and save them back.
Why don't you mount SFTP as a drive? That way you can use any app with remote files. I don't use mac but a quick search shows there are tools for that just like on Windows: https://www.google.com/search?q=mac+mounting+sftp
It technically only needs a local cache of the files you intend to edit. I work from a very large remote checkout on a development server, and only have a local cache of the directories and files that matter to me.
I've used Tailor, the Chrome port of Brackets, and it's a beautiful editor. I would love to use it full time on my Chromebook, however the Live Editing feature is broken and the Git integration is lacking. It also lacks some other standard things, like Find/Replace.
I recently found another Chrome editor, Caret, that feels a little more powerful (and more in line with how I use Sublime.) It's quite a big uglier though, unfortunately.
Just to clarify - Live Preview in Brackets is significantly fancier than plain 'live reload on save.' As you edit HTML or CSS the browser preview updates continuously: on every keystroke, even while dragging a colorpicker slider. And it does it without a full-page refresh, so if you have any state on the page it doesn't get reset.
Brackets is cool. definitely great to have it as an option. Most important for me for new additions is the multi-line / cursor editing. I use Notepad++ for that but brackets could replace notepad++ if it had it for me.
That and the other day I had this xml file I needed to look at and brackets didn't open it on Mac. Right-click open with, Brackets. It failed. Not sure why it wasn't a bad or large file at all. Text-wrangler opened it fine.
I really like Brackets. And it's got some great plugins already. I've set mine up with a visual git sidebar, markdown preview, themes and a mini-map like Sublime Text has.
Interesting! Multi-cursor is one of those things that I personally tended to use only from time-to-time when Sublime was my primary editor (I'm on the Brackets team, so you can guess what I use now).
The most typical use is for me to abuse the heck out of command-d. This will select the current word (if none selected) and then each subsequent press of this command adds the next occurrence of the selected text to the selection. I also like the ability to use option-drag down a column for block selection when I have text from some source that needs a bit of munging on each line.
The thing I don't get about Cmd+D is, what do you do when you get to an occurrence you don't want to include in your selection? There doesn't appear to be any "skip" shortcut -- is there?
I always prefer nice Replace All commands where you can see a condensed overview of all occurrences and then uncheck things you want to exclude. When Brackets added that it made me very happy :-)
This is typically down to web developers building desktop apps without the same level of experience. There is nothing baked into AIR to make it perform poorly.
They are. Brackets was presented at a local js meetup a little more than a year ago; Edge code is one of the primary reasons why adobe is running this project.
Brackets doesn't ship with code folding, but there's an extension that adds code folding. (I haven't the extension personally, so I can't comment on how well it works...)
I would expect us to ship code folding, but we just haven't gotten to it yet. Same for themes (for which there are also extensions that fill in the gaps).
It would be a great contribution to the project for people to pick up a feature like folding that ideally belongs in core and helps get it to "core quality" (unit tests, comments, etc.) It's possible that some extensions are already that good and we just don't know it.
https://news.ycombinator.com/item?id=3917637
https://news.ycombinator.com/item?id=4159552
https://news.ycombinator.com/item?id=4619499
https://news.ycombinator.com/item?id=4919677