HTML wasn’t made for apps
This is in response to Danny Tuppeny’s “You have ruined HTML” which is found here: http://blog.dantup.com/2014/08/you-have-ruined-html/
His post says we shouldn’t use template engines. From the article, my understanding is that he’s saying use vanilla HTML or do all the view logic in JS like defining HTML tags and their content. Below are all the points in his post with my responses.
“Hipster” Frameworks
First things first, most of the libraries he mentions that are “hipster” are simply not. Backbone, Angular and Knockout have been around 4 years or more. That’s longer than most tech startups last. All of those frameworks have also been around about as long as the two internal JS frameworks I used at the last two companies I worked for.
The reason why I’m harping on “hipster” is because it implies these are new, unreliable and just fads, or as he calls them later on in the post, “fly-by-night JavaScript framework”. The simple truth is, while I might not personally like all of those frameworks, if any are untrustworthy or unstable it’s the in-house built frameworks. You can’t ask Stackoverflow questions, the docs are usually not there or sparse, and just don’t have as many people working on it. Unless you’re a company the size of Facebook or Google, you don’t have a team to spare working on a JS framework full-time.
No help from your tools
Because these binding expressions aren’t real HTML constructs, you’ll get no help from your tooling with them.
The funny thing about this is that I use Vim and it’s been around forever. One of the least “hipster” editors there is. Yet, for many CSS3 properties, there’s no code completion or syntax highlighting unless I add a plugin. This is the same with ES6 features and HTML5. This doesn’t mean HTML5, ES6 or CSS3 are bad. It means my editor either needs to be updated or I need to add or write a plugin.
I would find it odd for someone to choose a programming language, library or framework based on your vanilla editor setup. If you want syntax coloring with Mustache, EJS, or hell, even JSX I bet there’s a plugin already made unless you’re using some “hipster” editor — see what I did there?
Simple tags are never simple
This one is easy: if you don’t want complicated tags use a template library that forces you to keep them simple like Mustache.
In response to “writing a JavaScript function” to give the value you want in your template if the logic is complicated, that’s the whole conclusion to his post. In italics in the conclusion he writes:
Do your programming in a programming language
If you were using vanilla HTML and JS, or all the view code in JS, you’d be doing exactly the same thing. I’m not sure what he’s trying to get at in this section. Isn’t putting that logic outside the view the right way to do templating in all programming anyway?
Nothing ever works first time
As your binding expressions get more complicated, you’ll find that they rarely work first time.
I don’t know what other people’s experiences are, but every programmer I know feels skeptical when their code works the first time — “Hmm, I better refresh again. Did it even build?” That’s just programming. You write, you save, you refresh and you groan. Does anyone’s code regularly work every time the first time? If so I’ll hire you on the spot if you can prove it.
The example he gives says “Which ones need parens()?” I have no idea because I don’t use Knockout, but if I did, I would assume I knew the syntax and if the syntax was really that hard I wouldn’t use it.
Error messages rarely exist and are frequently useless
The entire post is comparing HTML and he mentions that error messages rarely exist. HTML gives you exactly 0 feedback on errors. Nothing. Nada. The fact that something like JSX or EJS can give you any reporting at all is amazing compared to HTML. If you want better error reporting on HTML or a template language use a validator plugin. But, out of the box? Check out this beautiful HTML with it’s detailed error reporting:
Debugging is near impossible
My response to this is a mix of other responses I gave. One, debugging HTML errors is impossible too. Go ahead and try to find that missing closing tag on the div in your 100s of lines of HTML that is causing your app to render wrong.
Two, you really shouldn’t have logic in your view that requires putting a debugger there. Even if you were defining all your view in 100% JS with like “createElement” and “innerText” and similar wouldn’t you want the logic of what is set with innerText or innerHTML in their own methods away from the part that actually creates the elements and writes the content?
The real problem
stop trying to crowbar non-standard binding expressions into [HTML].
The reason all these templating engines have been invented and why frameworks like React and Famo.us even exist is because HTML wasn’t made for apps. Just by attempting to make an app with HTML you’re “crowbarring” it. The reason defining entire views in JS hasn’t caught on in React without using JSX or just plain JS is because it’s impossible to actually read and update it. Here’s some rendered JSX code that simply creates a nav list. Can you imagine writing this over JSX? Can you imagine a designer trying to update this?
And, remember, that above code is a nice way of writing HTML in JS. Just straight JS to achieve that would not be as easy to write, read, or update. It’d be about twice as long. If you know JS you would know that you’d need to create the element and then on another line add the classes then on another like append it to a parent element. ~3 lines for every one line above. That’s doing your programming in a programming language and guess what? It sucks.
Unless, of course, you used a framework. But then we’re right back where we started: using a framework to make views easier to read, easier to write and easier to debug.
