Tempo: a tiny JSON rendering engine(twigkit.github.com)
twigkit.github.com
Tempo: a tiny JSON rendering engine
http://twigkit.github.com/tempo/
25 comments
is the unobtrusive javascript paradigm dying or already dead?
From the link: Degrades gracefully if JavaScript is not enabled
Graceful degradation is less common for JavaScript now than it used to be though. So if you want a smooth web experience, these days you just can't go without JavaScript. I personally don't think that's a horrible thing, but I guess most people who've disabled JavaScript (or use Lynx or something) would disagree.
Graceful degradation is less common for JavaScript now than it used to be though. So if you want a smooth web experience, these days you just can't go without JavaScript. I personally don't think that's a horrible thing, but I guess most people who've disabled JavaScript (or use Lynx or something) would disagree.
The only thing I was still using Lynx for is for downloading graphics drivers on Linux. Alas, since NVIDIA did their last site update, that doesn't seem to work anymore :(
I think that if your site has a clear-cut function, you should at least try to provide that functionality even for bare-html browsers. Doesn't matter if it looks ugly, the focus is this case is on functionality not looks.
I think that if your site has a clear-cut function, you should at least try to provide that functionality even for bare-html browsers. Doesn't matter if it looks ugly, the focus is this case is on functionality not looks.
I think that's just a result of lazy programmers. Most of the sites I put together work with or without js. It's not that hard to do with a good templating engine that splits up each "ajax" part of html into a piece that can be rendered with a refetch of the entire page, or a refetch of just that part.
i.e.: http://twigkit.github.com/tempo/examples/twitter
with no-script turned on
http://yfrog.com/h2g6vcqj
well, i'm not quite sure how "Degrades gracefully" is defined, but i would not call the no js-version "gracefully"
[deleted]
Javascript is pretty much necessary to browse the web these days, unless you stick to things like wikipedia, and only write text.
I haven't had big troubles for browsing the web, though interacting with it (e.g. posting stuff in comment areas) is more problematic. Looking at the sites I regularly visit, all can be browsed fine without js: Wikipedia, HN, Reddit, Twitter, any Wordpress blog, Slashdot, Google News and just about everything it links to, university professor/project websites, etc.
In fact, I can't think of a site I regularly visit that doesn't work without js, except for things clearly in the category of "web apps", like canvaspaint.org, where the idea of "browsing" them doesn't even necessarily make sense. Even gmail works without js!
In fact, I can't think of a site I regularly visit that doesn't work without js, except for things clearly in the category of "web apps", like canvaspaint.org, where the idea of "browsing" them doesn't even necessarily make sense. Even gmail works without js!
I feel necessary to point out that the sites you regularly visit seem to fall in two broad categories. Wikipedia, Slashdot and so on are enormous sites with vast user bases and advanced JS, where any JavaScript functionality has to be backed up with plain old HTML or the site becomes unusable for a significant number of people. University websites are in my experience much smaller sites with a very strong emphasis on factual content and almost no JavaScript at all in the first place.
The problematic sites are going to be the middle ground - large-ish sites with reasonably competent web developers who have higher priorities than supporting the 1% of users who have JavaScript disabled.
The problematic sites are going to be the middle ground - large-ish sites with reasonably competent web developers who have higher priorities than supporting the 1% of users who have JavaScript disabled.
Just out of curiosity, why do you browse without javascript?
I don't regularly anymore, but until a few months ago my main portable coffee-shop machine was an old 12" Powerbook G4, which was a lot snappier with js turned off, especially on a few sites whose dynamic versions were slow as molasses, like Slashdot. Probably close to a worst case for js, because not only was the machine slow and low on RAM, but browsers use old fall-back js engines on PPC.
I also use 'links' from a terminal on occasion. It's gotten increasingly hard to use, but mostly due to layout issues rather than js, afaict.
I also use 'links' from a terminal on occasion. It's gotten increasingly hard to use, but mostly due to layout issues rather than js, afaict.
As a user of the "prototype.js" library this is a little similar to the default template syntax, yet with one extra character.
Thomas Fuchs has a very similar version: http://mir.aculo.us/2011/03/09/little-helpers-a-tweet-sized-...
And finally, I ported the template functionality from the "prototype.js" to php. https://github.com/freshteapot/php-template
Prototypejs - api of "Template" http://api.prototypejs.org/language/Template/
Thomas Fuchs has a very similar version: http://mir.aculo.us/2011/03/09/little-helpers-a-tweet-sized-...
And finally, I ported the template functionality from the "prototype.js" to php. https://github.com/freshteapot/php-template
Prototypejs - api of "Template" http://api.prototypejs.org/language/Template/
I generally pass the templates needed for a page into a Javascript variable from the back end. Looks nice for template nesting though, as opposed to storing a nested template in a separate Javascript variable.
As someone that isn't really a developer but understands enough to break things or cobble them together, this seems quite accessible to me.
For example, I could conceivably see taking an existing web services API and spitting JSON results into a themeforest template.
I'm sure there's a million ways of doing it, but this at a glance seems like a quick way of making that happen.
For example, I could conceivably see taking an existing web services API and spitting JSON results into a themeforest template.
I'm sure there's a million ways of doing it, but this at a glance seems like a quick way of making that happen.
sorry to be a hater, but while I find the idea of mixing js and html not great, the alternative being offered up here is to introduce a new language and mix that in with html instead of js. isn't that counterintuitive? wouldn't it be better to just use actual js in your templates instead of this arbitrary {{}}-based stuff?
It's a very familiar style of markup that I find immediately intuitive. The benefit being that it separates the markup from the code populating it.
{{tag}} is not "valid" markup (it will pass a validator but has negative semantic value), which is even worse than mixing a little well crafted logic into your display code.
Using {{tag}} notation seems to work well enough on Wikipedia -- could you elaborate on the difference between Tempo's use and Wikipedia's?
I don't seem much difference, but I also prefer when making websites to keep down the number of languages I have to know. Already html + css + js + a server side language is enough, introducing another seems excessive when your templating language could just be js or perhaps the same server side language you already use.
we do the same for our server side templating when making sites, using php for controller & model code, but also arbitrary php as the template language in the view too. it seems to work well, and avoids the need to learn something new.
we do the same for our server side templating when making sites, using php for controller & model code, but also arbitrary php as the template language in the view too. it seems to work well, and avoids the need to learn something new.
Looks interesting, especially to those coming from Smarty as it appears quite similar in terms of templating.
To compare the two, the upside is you get to feed the site JSON, which is easier to generate. The downside is the extra content load time of the script vs doing the template integration server side and caching the result.
To compare the two, the upside is you get to feed the site JSON, which is easier to generate. The downside is the extra content load time of the script vs doing the template integration server side and caching the result.
Interesting. At first sight, I couldn't really understand the difference with the existing icanhazjs(.com) library? Can you elaborate on this?
How well does the {{}} syntax coexist with server-side template languages like Django's one which uses the exact same marker for placeholders?
You can use tags in your django templates do avoid that issue. For instance, I am using icanhaz which use mustache's templates ({{}}) and I inspired myself of a snippet called Verbatim. So, basically, in your template you do:
<body>
{% js_template test %}
Here you can freely use {{}} because the surrounding tags make django ignore them.
{% endjs_template %}
You could add yours.
[1]http://jsperf.com/dom-vs-innerhtml-based-templating/112