4 ms·
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
by ClayFerguson 10y ago
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/resources/public/ts/dlg/AudioPlayerDlg.ts 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.
- Jetrel 10y agoYeah - 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.
- hitchhiker999 10y agoThat's lovely. Beautiful, readable, elegant bit of code. (35 years experience)
- ClayFerguson 10y agoThanks, 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.
- Already__Taken 10y agoWhat is 'build = (): string => {' ? Or specifically ():, I know arrow functions.
- igl 10y ago() = 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
- deleted 10y ago[deleted]
- scottmf 10y agoLooks like build is the function and it returns a string. I think without the typing it would just be build = () => {
- Already__Taken 10y agovar build = function(){...} //return a string Rather than some other commenters, and I would have thought given arrow functions; var build = function(string){...}
- scottmf 10y agoI don't understand what you're trying to say?
- mcbits 10y agoIt'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.
- 10y ago
- s369610 10y agoInteresting 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/e506ac871c32b169ce5760de9daa1b98#file-audioplayer-riot-html https://gist.github.com/anonymous/e506ac871c32b169ce5760de9d... I think I still prefer the html style markup, but probably only because I am used to it.