Data served in a tree structure and then rendered with client side templating with the ability to create custom elements... those crazy W3C eggheads in their ivory tower, why did they think anyone would want that?
Not trying to pick on this particular project because it seems cool enough, but,
I don't get all this html templating. With ajax and websockets on the way, why are we still generating html in the application? This all seems like a solution to a problem we should be leaving behind.
exactly! why should we have that visualization be backed by a html table within the page? Especially when you probably have that data backed by an API anyway that could probably server up json, xml or whatever else.
It took me a while to get used to creating an HTML file and making part of it executable. How utterly obvious and convenient. Templating systems and MVC frameworks now seem like bureaucracy that solve a purely theoretical problem.
A simple site surely would have been one that performs only the task required without anything else.
Which begs the question why have Javascript or even CSS at all for what you're doing?
And if you're using firebase, why not just host on github pages with raw HTML and an embedded body css? Even writing HTML and FTPing to a shared host (jus like the olden times) is simpler and closer to the aims of the site.
Not utterly sure what the point of all this is apart from explicitly not using a framework that the author doesn't understand the workings of. You could say the same of firebase and node.
I think the point is that you write your content in Markdown, the structure of your site in JSON, and this generates and serve HTML with a decent CSS. Interesting for programmers who want to quickly publish content without bothering with presentation. It's like Jekyll or Nanoc for busy (or lazy) people.
HTML5 is on the way to become this. You have permissions, local storage, indexedDB, and a ton of APIs. Anything else you need you can just submit it to the HTML5 working group (e.g. shared data)
There is no good reason that this kind of content would need any client-side logic. Not being able to view this with tools like w3m is an unnecessary drawback.
I don't see the appeal. Converting HTML and CSS into JSON seems like a lateral move at best (disregarding the tools we have for authoring and accessibility), not forward.
XHTML. Seriously. If what you want looks like an extensible document type with custom embedded data that you want to reliably parse out, that's what it's there for.
All good points - I'm not sure about the practicality of it, just intrigued by the ability to store and retrieve data from HTML elements.
I can't imagine at the moment any project where it would be used, but who knows, maybe someone would, or maybe not. Mainly just seeing what it possible to create and then seeing if there are any ideas to help take it away.
Shit idea is a little harsh for sure, but the problem is when your page relies on dynamic data and you can't prerender it. It's just too expensive to boot up a DOM on the server.
Or you could just make the HTML and what not simpler and then who cares? The useless data is fine if you don't already have the problem of sending tons of extra crap that nobody needs. Single page stuff can still use templating on the server side.
The lesson I took from the MS Office XML fiasco is that a poorly abstracted single-client data model remains impenetrable no matter how you serialize it. It's not impossible to commit to a documented and stable wire format behind a web app, but almost nobody has the diligence to actually do it when it's so much easier to make random changes and then tweak your own client code to handle whatever you did (instantly making your client the only one that still works). Before javascript happened, HTML wasn't that easy to scrape, but it at least had the virtue of forcing everyone to generate output that made some kind of sense without first being munged by one idiosyncratic piece of code.
/s
reply