5 ms·

HTML is a language for describing documents, right? The way I see it, there is an issue with HTML today. These days, many web developers are now exploring alter

HTML is a language for describing documents, right? The way I see it, there is an issue with HTML today. These days, many web developers are now exploring alternatives to a documents-based paradigm, and gearing their apps toward being "long-lived", while retaining the URLs and graphical support that modern browsers give us. Ember is a great example of this, there's very little markup you actually have to write when using Ember views and components. I don't really build "web sites" anymore, I build "web applications" which are typically one page but include all of the application's contents within that page. They do act the same, but are coded in wildly different ways. Don't get me wrong, I like HTML and I'm not trying to disrespect what was arguably the first foray I had with "programming". But if we are intending to make the web into something more along the lines of a massively distributed application runtime, rather than a repository of documents that anyone can access, where does a document markup description language fit into all that? When developing some (kinds of) applications, I feel that HTML only serves as an obstacle, rather than a means of helping me make the app. I feel like I do most of my "real work" in CSS and JavaScript.

kunai 13y ago
Why can't it be both? Applications are still, in essence, a type of interactive view hierarchy of document. The web can serve up both types of data: document-based (e.g. Wikipedia) and application-based (e.g. Gmail). Being able to have a core toolchain of three inter-related languages that can communicate with each other that you can use as required should be the final goal. For instance, if you're writing a web application, you could only use CSS/JS, and if you needed to write a very simple blog, you could use all three, or just HTML and CSS. Having more options never hurt anyone. Better JIT of JavaScript code would break pure JS open, allowing full apps to be written without language fragmentation. Those who will still require stylesheets can use them as they wish. It's a win-win situation on both ends.
- zalew 13y ago
  > he web can serve up both types of data: document-based (e.g. Wikipedia) and application-based (e.g. Gmail). an email message is a document too.
  - evincarofautumn 13y ago
    > an email message is a document too. An email client is not.
mistermumble 13y ago
I agree with your comment that HTML by itself is insufficient for a rich user experience. But my post talked about both HTML and CSS. These two, plus the minimum amount of Javascript code necessary to deliver a rich experience. Nowadays, there's a lot that can be done with modern CSS that in the past required Javascript code -- from dynamic menus to 3d effects to responsive web design. This is a good thing. Code is a breeding ground for bugs (especially dynamic code with callbacks, evals, unusual inheritance model, unconventional scoping rules, etc) in a way that declarative rules are not.
pjtops 13y ago
I think the web will always be more about delivering content, rather than manipulating data. Apps are all about data, documents are all about content. HTML and CSS are not fading away, they are actually getting bigger, and breaking into the desktop. I love javascript, but its more likely of being replaced by another scripting languange to work with HTML and CSS, than actually being a replacement for HTML & CSS.
zanny 13y ago
The reason this is happening at all in the first place is because html / css / js is the only platform agnostic toolkit. Everything else lacks support somewhere, and the big businesses behind technologies will actively avoid supporting someone elses otherwise cross platform framework. Same thing with dynamic languages. You cannot write a Java, Python, or Ruby app and expect it to run on any device. Just doesn't work when you need to also distribute the runtime framework on a per platform basis. Similarly, you have semi-portable C# and C++ through Mono and Qt that reach pretty much every major platform (the primary limiter is ios being so locked down) but they both need to do ugly repackaging of their entire toolkit runtime and framework that has to somehow jump through hoops to get installed locally whenever you try to install such a program. But you can expect html, css, and js on everything. And that is why everyone tries to stick completely tangential computing techologies (html is not a widget toolkit) and hope for the best. Because it is the only write once, run everywhere where the run everywhere actually happens, even if your site ends up being double in size for mobile and desktop versions or reactive with tons of overhead in element scaling, plus all the conditionals for old versions of IE, having to import require.js or something to check for feature compatability, etc. But you can work with that. You can write megabytes of JS to try to weasel around the mess. There is literally nothing you can do to get a python app running on average joes iphone. I really hope qml can take off in a big way, and become a standard of some sort. It is in my experience the portable ui toolkit for actual applications that is portable and looks native since 5.2, and it even lets you script it in js so you never have to compile anything with a qmlscene binary. And it is designed ground up to have any resource local or networked.

kunai 13y ago

Why can't it be both? Applications are still, in essence, a type of interactive view hierarchy of document. The web can serve up both types of data: document-based (e.g. Wikipedia) and application-based (e.g. Gmail). Being able to have a core toolchain of three inter-related languages that can communicate with each other that you can use as required should be the final goal. For instance, if you're writing a web application, you could only use CSS/JS, and if you needed to write a very simple blog, you could use all three, or just HTML and CSS. Having more options never hurt anyone. Better JIT of JavaScript code would break pure JS open, allowing full apps to be written without language fragmentation. Those who will still require stylesheets can use them as they wish. It's a win-win situation on both ends.

zalew 13y ago
> he web can serve up both types of data: document-based (e.g. Wikipedia) and application-based (e.g. Gmail). an email message is a document too.
- evincarofautumn 13y ago
  > an email message is a document too. An email client is not.

mistermumble 13y ago

I agree with your comment that HTML by itself is insufficient for a rich user experience. But my post talked about both HTML and CSS. These two, plus the minimum amount of Javascript code necessary to deliver a rich experience. Nowadays, there's a lot that can be done with modern CSS that in the past required Javascript code -- from dynamic menus to 3d effects to responsive web design. This is a good thing. Code is a breeding ground for bugs (especially dynamic code with callbacks, evals, unusual inheritance model, unconventional scoping rules, etc) in a way that declarative rules are not.

pjtops 13y ago

I think the web will always be more about delivering content, rather than manipulating data. Apps are all about data, documents are all about content. HTML and CSS are not fading away, they are actually getting bigger, and breaking into the desktop. I love javascript, but its more likely of being replaced by another scripting languange to work with HTML and CSS, than actually being a replacement for HTML & CSS.

zanny 13y ago

The reason this is happening at all in the first place is because html / css / js is the only platform agnostic toolkit. Everything else lacks support somewhere, and the big businesses behind technologies will actively avoid supporting someone elses otherwise cross platform framework. Same thing with dynamic languages. You cannot write a Java, Python, or Ruby app and expect it to run on any device. Just doesn't work when you need to also distribute the runtime framework on a per platform basis. Similarly, you have semi-portable C# and C++ through Mono and Qt that reach pretty much every major platform (the primary limiter is ios being so locked down) but they both need to do ugly repackaging of their entire toolkit runtime and framework that has to somehow jump through hoops to get installed locally whenever you try to install such a program. But you can expect html, css, and js on everything. And that is why everyone tries to stick completely tangential computing techologies (html is not a widget toolkit) and hope for the best. Because it is the only write once, run everywhere where the run everywhere actually happens, even if your site ends up being double in size for mobile and desktop versions or reactive with tons of overhead in element scaling, plus all the conditionals for old versions of IE, having to import require.js or something to check for feature compatability, etc. But you can work with that. You can write megabytes of JS to try to weasel around the mess. There is literally nothing you can do to get a python app running on average joes iphone. I really hope qml can take off in a big way, and become a standard of some sort. It is in my experience the portable ui toolkit for actual applications that is portable and looks native since 5.2, and it even lets you script it in js so you never have to compile anything with a qmlscene binary. And it is designed ground up to have any resource local or networked.