6 ms·

>> 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-templa

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

scott_karana 13y ago
Template writers? Proof of concept websites? Quick-and-dirty one-offs?
tinco 13y ago
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.
BlackDeath3 13y ago
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.
- sejje 13y ago
  That's a different thing. Templated, as in "this html isn't coming from a rails partial" etc.
  - BlackDeath3 13y ago
    I think I'm in over my head now. I've never even used Rails and know almost nothing about it.
    - doginabathtub 13y ago
      Templated, I think, as in a page is not using PHP or some other language to pull content from several files or a database.
      - BlackDeath3 13y ago
        OK, that makes sense to me. Thank you.
mikeryan 13y ago
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.
dubcanada 13y ago
Me, and all my coworkers.
reeses 13y ago
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.
jenius 13y ago
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.
- ryan-allen 13y ago
  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.
  - ianstormtaylor 13y ago
    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 https://segment.io [2]: https://github.com/segmentio/toggle https://github.com/segmentio/toggle [3]: https://github.com/segmentio/sheet https://github.com/segmentio/sheet [4]: https://github.com/component/tip https://github.com/component/tip [5]: https://github.com/component/component https://github.com/component/component [6]: http://myth.io http://myth.io
willtheperson 13y ago
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
Tloewald 13y ago
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>.
- michaelbuddy 13y ago
  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?
  - sourpoi 13y ago
    You may be interested in TAL/ZPT: http://en.wikipedia.org/wiki/Template_Attribute_Language http://en.wikipedia.org/wiki/Template_Attribute_Language
    - Tloewald 13y ago
      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.
  - Tloewald 13y ago
    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).
quadyeast 13y ago
What kind of templates do you mean? e.g. Wordpress? Underscore? Bootstrap?
- idProQuo 13y ago
  Jinja2, ERB, Haml, Jade, etc. Any system where the thing you're editing could not be immediately served as an HTML file.
meerita 13y ago
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.
specialist 13y ago
"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.
interstitial 13y ago
Why experiment when frameworks make hard-coding so sexy?
jmnicolas 13y ago
Maybe desktop developers that want to learn web development from the ground up ? (my case ;-) 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 :-)
coldtea 13y ago
>Who actually writes non-templated HTML any more? 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).
ahuth 13y ago
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.

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

scott_karana 13y ago

Template writers? Proof of concept websites? Quick-and-dirty one-offs?

tinco 13y ago

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.

BlackDeath3 13y ago

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.

sejje 13y ago
That's a different thing. Templated, as in "this html isn't coming from a rails partial" etc.
- BlackDeath3 13y ago
  I think I'm in over my head now. I've never even used Rails and know almost nothing about it.
  - doginabathtub 13y ago
    Templated, I think, as in a page is not using PHP or some other language to pull content from several files or a database.
    - BlackDeath3 13y ago
      OK, that makes sense to me. Thank you.

mikeryan 13y ago

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.

dubcanada 13y ago

Me, and all my coworkers.

reeses 13y ago

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.

jenius 13y ago

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.

ryan-allen 13y ago
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.
- ianstormtaylor 13y ago
  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 https://segment.io [2]: https://github.com/segmentio/toggle https://github.com/segmentio/toggle [3]: https://github.com/segmentio/sheet https://github.com/segmentio/sheet [4]: https://github.com/component/tip https://github.com/component/tip [5]: https://github.com/component/component https://github.com/component/component [6]: http://myth.io http://myth.io

willtheperson 13y ago

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

Tloewald 13y ago

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

michaelbuddy 13y ago
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?
- sourpoi 13y ago
  You may be interested in TAL/ZPT: http://en.wikipedia.org/wiki/Template_Attribute_Language http://en.wikipedia.org/wiki/Template_Attribute_Language
  - Tloewald 13y ago
    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.
- Tloewald 13y ago
  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).

quadyeast 13y ago

What kind of templates do you mean? e.g. Wordpress? Underscore? Bootstrap?

idProQuo 13y ago
Jinja2, ERB, Haml, Jade, etc. Any system where the thing you're editing could not be immediately served as an HTML file.

meerita 13y ago

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.

specialist 13y ago

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

interstitial 13y ago

Why experiment when frameworks make hard-coding so sexy?

jmnicolas 13y ago

Maybe desktop developers that want to learn web development from the ground up ? (my case ;-) 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 :-)

coldtea 13y ago

>Who actually writes non-templated HTML any more? 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).

ahuth 13y ago

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.