Live data from Hacker News

Brackets, a code editor

brackets.io

121–128 of 128 posts

Re: Brackets, a code editor

#121

>> Live HTML Development >> As you code, HTML changes are instantly pushed to browser without having to save or reload the page. Who actually writes non-templated HTML any more?

Brackets is actually a very good code editor. I never use live preview.

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.

Re: Brackets, a code editor

#122
post #119

Earlier quoted context omitted.

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. Thanks much for that link. I'll chec…

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

The "skip" shortcut is Cmd+K, Cmd+D. You can also undo selection with Cmd+U to step backwards.

Re: Brackets, a code editor

#124

Earlier quoted context omitted.

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

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?

You may be interested in TAL/ZPT: http://en.wikipedia.org/wiki/Template_Attribute_Language

Re: Brackets, a code editor

#125

Earlier quoted context omitted.

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

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?

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

Re: Brackets, a code editor

#126

Earlier quoted context omitted.

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?

You may be interested in TAL/ZPT: http://en.wikipedia.org/wiki/Template_Attribute_Language

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.

Re: Brackets, a code editor

#127

Earlier quoted context omitted.

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.

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.

Re: Brackets, a code editor

#128
post #91

Earlier quoted context omitted.

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—w…

Preprocessors aren't incompatible with components. I usually structure my frontend code like components/ widget-one/ template.html script.js style.css widget-two/ template.dust script.coffee style.styl And then the style file for a component is completely scoped to that component's main class: .widget-two { .widget-two-control { color: blue; } } The build script can handle each component separately and stitch the res…

Yeah, the problem comes in when you want to share pre-processor variables between your components.
Post reply on HN