Brackets, a code editor
brackets.io
brackets.io
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.
That level of performance degradation is definitely not normal.
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.
Who actually writes non-templated HTML any more?
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.
Templated, as in "this html isn't coming from a rails partial" etc.
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.
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.
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.
[1]: https://segment.io
[2]: https://github.com/segmentio/toggle
[3]: https://github.com/segmentio/sheet
[4]: https://github.com/component/tip
[5]: https://github.com/component/component
[6]: http://myth.io
components/
widget-one/
template.html
script.js
style.css
widget-two/
template.dust
script.coffee
style.styl
.widget-two {
.widget-two-control { color: blue; }
}
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.
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.
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
Want a span to show the live content of foo.bar.baz? <span data-source="foo.bar.baz"></span>.
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.
After a really bad encounter with Javascript 7 years ago I chose to forego web development completely.
Now I have a web-app project and I discovered with horror that not only Javascript is not dead, but it's even more prevalent than before !
I'm gonna have to suck it up and start learning it, but maybe not to the point of choosing Node.js as my server side technology :-)
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, however, do rails with it. This includes everything: ruby, erb, CSS, sass, JavaScript/coffeescript, and even handlebars.
Live development is it's least useful feature (for me), and Brackets should get more credit for the rest of it.
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.
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.
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 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.
My plugin setup is only to add jsbeautify and JSONLint.
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.
If the person who posted this link believes that it is Beautiful, then it is. You may agree or disagree but humility has nothing to do with it.
> 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.
> If the original title includes the name of the site,
> please take it out, because the site name will be
> displayed after the link anyway.
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 :)
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.
However, if the (S)FTP connection is broken and reconnected you can't continue in the same editor, you need to re-open it again which frustrates me.
(ExpanDrive, WebDrive, MacFusion, Transmit, sshfs)
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.
Caret: https://chrome.google.com/webstore/detail/caret/fljalecfjcio...
Tailor: https://chrome.google.com/webstore/detail/tailor/mfakmoghean...
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.
The problem with the XML file might be encoding, because Brackets supports only UTF-8 encoded files at the moment.
There is always a first phase in a project where I only code HTML and CSS. I create the layout, the scaffoldings, the different pages, etc...
And as amazing as emacs and ST3 are, it's a pain in the ass to do that part with them.
I feel like I'm gonna use Brackets a lot.
Regarding multi-cursor in Brackets:
https://groups.google.com/forum/#!topic/brackets-dev/FLMlU3P...
Thanks much for that link. I'll check it out.
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 :-)
Are they just abandoning it or is CEF3 the new AIR?
The "how is it run?" question is answered here, where the native code lives:
https://github.com/adobe/brackets-shell/
We do as little as possible in the native code.
By contrast Brackets feels very native. For once corporate policy didn't get in the way of building something cool!
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.
Now it's outdated, so I imagine Chrome is faster.
We want Brackets to be awesome and useful by itself, and to also provide the foundation for people who use the Creative Cloud.
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.