js Templating Engines

Before we even discuss templating engines, I believe it's worth pointing out the advantages of client-side markup generation:

Because your markup generator is cacheable and your templates too,

• you save A LOT of bandwidth
• the ONLY thing a returning user will transfer is the new data, i.e. the strict minimum you can transfer to create the page - considering you transport the data in an efficient format like gzipped json
• you save A LOT of processing power on the server-side (string manipulation is always expensive), spending a bit more on the client-side (not an issue, even 800mhz ARM is much too fast for such tasks)

To take advantage of that kind of stuff, just create js that will echo your html markup, with the parameters it got from json (you can put your json in a non-cacheable include js file, or get it via ajax), and make sure everything but the data is cached.

The only way to improve on that is to make the templating engine faster, and the unique data smaller (think about how much you can cache really -- like normalized data ;) ).

Lastly, I don't use any kind of templating engine, but all my client side except html,head,body,script is js-generated, and it's extremely fast, even on my phone.

On the other hand, I write web applications, not websites, so that might be why I don't care about that kind of crap  - web apps are best built with modules like in flex, which by definition handle the view and thus templating internally.

The Best Programming Language

There IS a best programming language

And we can find it by logic alone - what's the most useful code base in the world ?

Unix kernel

What's the best FPS game ever ?

Quake

The holy kernel is written in C.

The holy quake is written in C.

And the winner is C

Why is it so ?

The machine speaks ASM.

To have something humanly readable, we need the thinnest translation layer possible, a layer that would mimic ASM while abstracting the processor-specific instructions.

We have been using two such translations for three decades, and this is not going to change tomorrow.

The first is FORTRAN, which remains the fastest compute language available, barring ASM, and beating C by a tiny margin.

The second is C, slightly slower, but expressive enough to write EVERYTHING in it, including all the other languages - and it lets you include ASM, beating fortran hands down when it matters :).

When does a language become inferior to C ?

The second you remove the possibility to manually direct the ASM output.

There are many languages where it is IMPOSSIBLE to output the required optimized ASM for the task you're trying to accomplish.

There is NO valid excuse for removing that ability, since abstractions are built on top of each other and you can provide the most powerful abstraction along with no abstraction if you so desire.

Like there is NO valid excuse for removing the possibility to manage memory manually. Garbage Collection is a nifty tool, but unless you can turn it off and do the whole thing without, it's not a worthy addition.

As a summary, for a language to be better than C it must :

• provide the means to be as fast as C/ASM
• provide access to every feature C/ASM offer, including manual memory management
• provide higher-level abstractions as well

What about the others ?

I'll take Java and Python, because C# is a bad copy of java anyway and perl is mostly interesting for the regex goodness.

All those languages bring interesting "approaches" (or religions), syntaxes and operators.

But they're NOT in the same layer.

They're above C, they're not ASM translators, they're concept translators.

They essentially could just be C extensions (like Cpp) or C pre-compilers.

So yes, while some languages may bring some concepts or approaches to the front and enable more programmers to use them with ease, they're usually the equivalent of badly implemented C extensions, like the ultra slow ruby for example.

Mobile Development : HTML5 vs Native

http://blog.suthakamal.com/2012/08/go-native-html5-is-going-to-lag-for.html

That guy seems to think native is better because the web is slow, and while he clearly has a point for games (even chrome is not there yet), he's dead wrong on applications, and here's why.

1. most applications do not use 3D
2. the only "slow" thing in the [html5/css3/js] combo is js-loop-type visual effects (like fadeIn and that type of crap)
3. v8 is more than decently fast for js processing, firefox is meh-but-ok
4. most android phones today are powerful quad cores
5. those 100% CPU web apps have very low quality code, and that has nothing to do with the technology

Every application that is not a game can be implemented just fine in html5, and will be plenty fast in most browsers.

Now for the points that "native" does not address:

More than being limited to one OS, native is limited to a few versions of  an OS.

An HTML5/CSS3/JS solution (coded to standards) works -

on a phone

on a computer

on a smart TV

on a tablet

on google glasses

So sure, while some actually design games, and some others can totally afford developing a dozen versions of each application, with a dozen platform specialists to leverage all the platform-specific goodies, the simplest approach remains our good (but evil) friend, chrome.