2 ms·

Whilst this article is indeed an opinion piece and strongly hyperbolic (and perhaps even didactic), I'm not sure why that offends you. I don't have any statisti

by dools 15y ago

Whilst this article is indeed an opinion piece and strongly hyperbolic (and perhaps even didactic), I'm not sure why that offends you. I don't have any statistics about large or small organisations putting this into practice so I'm not sure what other facts I could have included apart from the examples I provided. The capacity of designers to understand anything isn't the subject of the post, so I'm not sure why anyone would be offended by that. The idea is that it's easier to find someone to work on HTML/JavaScript/CSS in a static HTML context than it is to find someone familiar with whatever frameworks you're using and it's templating language, then to have that installed locally (especially when you're not working with a long term in-house team of designer/developers and don't have lots of time to spend on training people). I also personally find it far easier and quicker to iterate and test new interface ideas quickly when working with static HTML so I like to be able to view my templates outside of the context of my application/framework etc. and then iterate without having to re-apply a bunch of templating code.

deleted 15y ago
[deleted]
fleitz 15y ago
It's ok to write a little polemic here or there but don't be surprised when people react negatively to it. People are offended because you are saying they are incompetent at their profession. Have the humility to understand that many of us have been doing this for years and have seen numerous attempts to revolutionize templating, and gasp have written webapps before the idea of templating really took hold. If you want to persuade people to take up your ideas regarding DOM manipulation in the controller, I'd suggest not starting by telling people they are writing spahgetti code. It's a great way to get page views, it's a poor way to persuade people. People probably would have reacted much better to your argument if you started with "Hey, I'm doing things this way and here's why it works for me" instead of "You're all idiots who write spaghetti code". Embedding XSL selectors in HTML attributes which is processed by a half-assed implementation of XSL in PHP is the kind of thing I think when thinking spaghetti code. What you don't realize is that you've invented a new templating language based on XSL but with half the features. Those of us who've been around the block a few times like to call this inner-platform effect. We've also seen this idea before when it was pitched with J2EE and used XML with an XSL templating system.
- dools 15y ago
  Hi, thanks for the tips. I'm always interested in opinions on my writing style and how to communicate better. Regarding your critique of Fragmentify, that's actually not so much what I'm advocating here as it is just the impetus for realising that there are 2 distinct components to templating which are: 1) the re-use of common assets, and 2) the application of some "logic" to display dynamic data. It doesn't matter what you use to fragment your markup (I personally think that using XPath to manipulate an XML document isn't particularly off the mark but whatever, to each their own). Dreamweaver allows you to edit common assets pretty easily and then export a ZIP with head-to-foot complete HTML documents in it. I'm sure there are a million other ways to skin that cat. What I'm saying is that the separation between "display logic" and "business logic" either doesn't exist or at the very least shouldn't be occuring between the backend and the frontend. You could, if you wanted to, put your "view rendering" code in some other place in your application, but that's tangential to my case for completely removing any and all logic from templates and working solely with (and iterating solely with) HTML/CSS/JS when building your interfaces.
  - fleitz 15y ago
    Personally I'd never use it because I intensely dislike the syntax of HTML and CSS and avoid it at all costs since discovering HAML/sass. I find a text editor (vim in my case)/photoshop + haml/sass + live reload to be my most productive workflow, one screen for the text editor, one screen for the browser, when I save the browser reloads the page. For me there are a lot of things that just work smoother by having the data populated, when I work with designers I just take whatever they give me (sometimes just a PSD) and work with it, if they need static HTML/CSS I just use wget/save as webpage to save the html and assets.
- tchvil 15y ago
  I revolutionized as well the templating 3 years ago with pure.js... This one is an intentional xslt for json. The result is a thin ~400 followers on http://github.com/pure/pure http://github.com/pure/pure, we use it for our web app, and I get regular thanks emails. Even some copycats appeared. Nothing changed. Server power is still wasted sending HTML to idle terminals using a markup/logic soup like we do since 1995. A pretty useless fight, but at least I'm happy I tried.
darklajid 15y ago
Why I (note: personal opinion) think that this article was arrogantly written and not for me: You try to make a rant (because that's what it is) more interesting by adding random fake quotes/thoughts that you attribute to the reader, i.e. me. There's exactly one person that knows my thoughts and I don't feel represented by your 'quotes' - so everything in light green on that site is bullshit according to me. Lucky for me you colored the link-bait title in the same way, so..
- dools 15y ago
  Duly noted. The "strawman" argument thing I always find makes a post (particularly an opinion piece) easier or more entertaining to read (I may have read a little too much maddox in my time, though).
  - jamesaguilar 15y ago
    All depends on your goal. Maddox runs an entertainment website. It's not meant to convince anyone of anything or otherwise be productive. His style is in service to the purpose of the site, so it stands to reason that emulating it will have a similar impact on what your readers take away from your work.
  - jjddss 15y ago
    It might have went over better had you attributed the quotes to some "third party", like "Mr. ERB Exponent, December 2011". You don't risk personally offending the reader. The tradeoff is it might make the joke a little less obvious. (I might Google for "Mr. ERB Exponent", thinking it's a web persona who was notorious for expounding on ERB.) Writing is hard. (For what it's worth, the attributions didn't bother me.)
- hetman 15y ago
  Can't believe so many people here need their fragile egos propped up. I thought the fake comments were silly and entertaining... which is a nice way to break up an opinion piece.

by dools 15y ago

deleted 15y ago

[deleted]

fleitz 15y ago

It's ok to write a little polemic here or there but don't be surprised when people react negatively to it. People are offended because you are saying they are incompetent at their profession. Have the humility to understand that many of us have been doing this for years and have seen numerous attempts to revolutionize templating, and gasp have written webapps before the idea of templating really took hold. If you want to persuade people to take up your ideas regarding DOM manipulation in the controller, I'd suggest not starting by telling people they are writing spahgetti code. It's a great way to get page views, it's a poor way to persuade people. People probably would have reacted much better to your argument if you started with "Hey, I'm doing things this way and here's why it works for me" instead of "You're all idiots who write spaghetti code". Embedding XSL selectors in HTML attributes which is processed by a half-assed implementation of XSL in PHP is the kind of thing I think when thinking spaghetti code. What you don't realize is that you've invented a new templating language based on XSL but with half the features. Those of us who've been around the block a few times like to call this inner-platform effect. We've also seen this idea before when it was pitched with J2EE and used XML with an XSL templating system.

dools 15y ago
Hi, thanks for the tips. I'm always interested in opinions on my writing style and how to communicate better. Regarding your critique of Fragmentify, that's actually not so much what I'm advocating here as it is just the impetus for realising that there are 2 distinct components to templating which are: 1) the re-use of common assets, and 2) the application of some "logic" to display dynamic data. It doesn't matter what you use to fragment your markup (I personally think that using XPath to manipulate an XML document isn't particularly off the mark but whatever, to each their own). Dreamweaver allows you to edit common assets pretty easily and then export a ZIP with head-to-foot complete HTML documents in it. I'm sure there are a million other ways to skin that cat. What I'm saying is that the separation between "display logic" and "business logic" either doesn't exist or at the very least shouldn't be occuring between the backend and the frontend. You could, if you wanted to, put your "view rendering" code in some other place in your application, but that's tangential to my case for completely removing any and all logic from templates and working solely with (and iterating solely with) HTML/CSS/JS when building your interfaces.
- fleitz 15y ago
  Personally I'd never use it because I intensely dislike the syntax of HTML and CSS and avoid it at all costs since discovering HAML/sass. I find a text editor (vim in my case)/photoshop + haml/sass + live reload to be my most productive workflow, one screen for the text editor, one screen for the browser, when I save the browser reloads the page. For me there are a lot of things that just work smoother by having the data populated, when I work with designers I just take whatever they give me (sometimes just a PSD) and work with it, if they need static HTML/CSS I just use wget/save as webpage to save the html and assets.
tchvil 15y ago
I revolutionized as well the templating 3 years ago with pure.js... This one is an intentional xslt for json. The result is a thin ~400 followers on http://github.com/pure/pure http://github.com/pure/pure, we use it for our web app, and I get regular thanks emails. Even some copycats appeared. Nothing changed. Server power is still wasted sending HTML to idle terminals using a markup/logic soup like we do since 1995. A pretty useless fight, but at least I'm happy I tried.

darklajid 15y ago

Why I (note: personal opinion) think that this article was arrogantly written and not for me: You try to make a rant (because that's what it is) more interesting by adding random fake quotes/thoughts that you attribute to the reader, i.e. me. There's exactly one person that knows my thoughts and I don't feel represented by your 'quotes' - so everything in light green on that site is bullshit according to me. Lucky for me you colored the link-bait title in the same way, so..

dools 15y ago
Duly noted. The "strawman" argument thing I always find makes a post (particularly an opinion piece) easier or more entertaining to read (I may have read a little too much maddox in my time, though).
- jamesaguilar 15y ago
  All depends on your goal. Maddox runs an entertainment website. It's not meant to convince anyone of anything or otherwise be productive. His style is in service to the purpose of the site, so it stands to reason that emulating it will have a similar impact on what your readers take away from your work.
- jjddss 15y ago
  It might have went over better had you attributed the quotes to some "third party", like "Mr. ERB Exponent, December 2011". You don't risk personally offending the reader. The tradeoff is it might make the joke a little less obvious. (I might Google for "Mr. ERB Exponent", thinking it's a web persona who was notorious for expounding on ERB.) Writing is hard. (For what it's worth, the attributions didn't bother me.)
hetman 15y ago
Can't believe so many people here need their fragile egos propped up. I thought the fake comments were silly and entertaining... which is a nice way to break up an opinion piece.