Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brackets, a code editor

brackets.io

Post reply on HN
Print view View original

71–80 of 128 posts

Re: Brackets, a code editor

#71

Post by aninhumer »

trycatch wrote: post #17

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.

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.

Re: Brackets, a code editor

#72

Post by dougbarrett »

forivall wrote: post #51
Dystopian wrote: post #33

Earlier quoted context omitted.

There's Adobe Edge Code CC - I thought that these were pretty much off the same code base?

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.

So I don't understand, Brackets is their open source branch but Edge Code will be their officially supported release?

Re: Brackets, a code editor

#73

Post by klinquist »

jonalmeida wrote: post #65
klinquist wrote: post #58

Earlier quoted context omitted.

I've tried it. Requires a local copy of the files - I found it messy.

If by local you mean temp working file, that's a given isn't it? 'Save' still saves it remotely. 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.

If I recall it required a full local cache of the remote folder.

Re: Brackets, a code editor

#74

Post by ianstormtaylor »

ryan-allen wrote: post #67
jenius wrote: post #56

Earlier quoted context omitted.

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…

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.

[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

Re: Brackets, a code editor

#75

Post by dangoor »

hawkharris wrote: post #7

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…

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.

Re: Brackets, a code editor

#76

Post by dangoor »

sdegutis wrote: post #45

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 le…

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.

Re: Brackets, a code editor

#77

Post by dangoor »

fournm wrote: post #28

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 :)

Re: Brackets, a code editor

#78

Post by dangoor »

Eleutheria wrote: post #62
willtheperson wrote: post #60

Anyone else surprised they aren't using Adobe AIR for this project? Are they just abandoning it or is CEF3 the new AIR?

This I'd like to know. Honest question, does it use flash in any form? What language is it coded in? I see JS everywhere but how is it run?

No Flash. It's HTML, JavaScript and LESS for the stylesheets, plus Chromium and native code for things like file access and the native menus.

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.

Re: Brackets, a code editor

#79

Post by dangoor »

kingnight wrote: post #47

Brackets is wonderful, but it's Brackets JS Completion vs Sublime Text multi-cursor behavior for me and the latter is too useful to give up.

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).

Regarding multi-cursor in Brackets:

https://groups.google.com/forum/#!topic/brackets-dev/FLMlU3P...

Post reply on HN