Comment by ClayFerguson | Hacker News Reader

Comment by ClayFerguson | Hacker News Reader

In my 15 years I've come to realize that HTML code-generation via JavaScript (or now TypeScript actually) is vastly superior to any type of templating (like JSP, JSF, Velocity, Mustache). Both ways (templating v.s. straight generation) have exactly one sort of 'level of indirection' so they are on the same order of complexity, but generating HTML rather than templating it is a billion times more powerful, so it is just better.

To prove my point: Here's the code for the Audio Player in meta64.

https://github.com/Clay-Ferguson/meta64/blob/master/src/main...

No one can possibly argue that an HTML template for that would be easier to read, than the TypeScript I've written. I think the way meta64 uses Polymer, TypeScript, generated-HTML, etc is the ideal architecture for the modern app.

BTW: I just picked a random example of my generated code from meta64. I do agree the CSS embedded in that would be better as a CSS class. I am not arguing for dynamically created CSS, but only dynamically created HTML (i.e. no templates). My point was that if you have clean code, you can make your HTML-code-generation look almost like the HTML itself, or be 'as readable' as it would be if it were an HTML template. Readability is the key here. That's all that counts. If you can achieve that in JS/TS then it beats a template approach easy, because of its power in terms of OOP, reuse, etc, which templates are just awkward with.

Interesting and I can see the appeal, I wondered how it would look in a riot/vue/ractive style language and ended up with this:

https://gist.github.com/anonymous/e506ac871c32b169ce5760de9d...

I think I still prefer the html style markup, but probably only because I am used to it.

Yeah - this, a thousand times, this. This is one of the biggest wins we've had recently over just about every prior web authoring approach - and my experience goes back to the PHP days.

What is 'build = (): string => {' ?

Or specifically ():, I know arrow functions.

() = empty arguments. you can only omit the braces when you have 1 argument. 0 and 2+ require the braces. #tc39

the colon refers to flow and typescripts type annotation "colon something". none-objects are lowercased

Looks like build is the function and it returns a string.

I think without the typing it would just be build = () => {

    var build = function(){...} //return a string

Rather than some other commenters, and I would have thought given arrow functions;

    var build = function(string){...}

I don't understand what you're trying to say?

It's similar to writing

    build(): string { ...

but they generate different JavaScript. The way it's written will give each instance its own reference to the function. The "build(): string" above will add the function to the prototype, which is shared by all instances.

I'm not sure whether the code takes advantage of this difference in some way or not. If not, it's just a slightly more awkward and less efficient way of defining a method.

That strange syntax with the arrow function is only needed so that the 'this' inside the function behaves the way one would expect it to in normal OOP language. It 'captures' the this for the object itself (like C++ would, etc). But that 'build()' function is what constructs a string that is the content for the dialog.

That's lovely. Beautiful, readable, elegant bit of code.

(35 years experience)

Thanks, it actually wasn't a great example to make my point because that file contains actually a few things I do try to avoid, but it does demonstrate that "generated HTML" doesn't have to be ugly and hard to read, using TypeScript or even JavaScript if you have a consistent architecture for how it's done.

Reply on news.ycombinator.com