I think there are blind spots in this argument. The web will never be a stable environment. The technologies that have afforded its existence are notably fluid, and often leaky. These are characteristics that do not fit standard computer science.
To engineers who are accustomed to rigid runtimes, compilers, and so forth, this opinion that HTML is object code will resonate. However, it makes the assumption that by abstracting away the underlying HTML, you stand a better chance of delivering your program to the intended audience. I don't believe this is the case.
If you embrace the fact that HTML/JS/CSS will at best represent an approximation of the interface you intend to create, and leverage this accordingly, you will write code that will more easily adapt to best fit the environment in which it is run.
The power of web technologies is their resiliency. Programs written in compiled or runtime-based languages either run or they fail. Web code is much more dynamic. We should appreciate this characteristic, even when faced the frustrations of immature, misimplemented, and unsupported standards.
> if you embrace the fact that HTML/JS/CSS will at best represent an approximation of the interface you intend to create
-- start rant --
Why embrace it ? I see this as a major shortcoming.
It's like it is 1986 again, everybody and their brother coding new and exciting user interfaces on their EGA screens.
Every website works differently. It's a UI nightmare. Throw in the 'approximation' factor and it is understandable why efficiency/productivity goes down the drain.
Because there is no standard menu structure, because there are no standard form validation methods you need to re-implement these basic features, and it seems that there are endless ways to do so.
The software wheel has not been re-invented as many times in the past as it has been on the web.
What should really be embraced is the resilience of the USER, not of the web technologies. End users are the people that have to put up with the messy environment that the architects of the web produce, and they do so admirably.
Take HN as an example. It's hard to even improve the slightest bit over the austere user interface that it offers. A few minor nitpicks, that's about it. And yet, I'm sure if I asked some art director to do a 'makeover' that he'd manage to run it right in to the ground. It would take 10 seconds per page to load and you wouldn't be able to make heads or tales of it. It would look positively fabulous though...
Huh? Why would that be a valid point? It's no harder to swap out different kinds of render methods than it is to swap style sheets.
BTW:
> Programs written in compiled or runtime-based languages either run or they fail.
This is simply not true. No matter what you're writing code in, you can write it in a way that exhibits graceful degradation. It's just that some languages make it easier than others.
> It's no harder to swap out different kinds of render methods than it is to swap style sheets
The point is that with css the client can change the rendering in ways not foreseen by the developers. If I happen to have a rare form of color-blindness that means I cannot perceive the color purple, I can create a Firefox extension that changes purple to blue, and immediately all websites in the world becomes accessible to me.
If we consider HTML a kind of object-code where presentation is hardcoded into the on-the-wire output (like eg. PostScript), I would have to call around to all web-masters in the world and beg them to change their render-methods to accommodate my unique disability.
'Huh? Why would that be a valid point? It's no harder to swap
out different kinds of render methods than it is to swap
style sheets.'
its much much harder to switch rendering engines than to switch css files
try changing this websites rendering engine, first you need to hack the server, then you need to understand the source code(and learn the language if you dont know it already), then learn how the renders are perfomed, how the data is modelled.
then try switching its stylesheet, that can be a click away if you want it.
What you say is true, but only because the software most people use on their servers makes it true. The conclusion is not that we should continue to use the current broken infrastructure, but that we should build different infrastructure. Your argument is kind of like someone in 1904 arguing that air travel will never be commercially viable because there aren't any airports.
I find it a bit distressing that I would have to explain this here on HN of all places.
I didnt make an argument I pointed out a blatantly incorrect statement.
but to follow your point is there anything fundamentally flawed in the concept of html/css/javascript that makes portable sites impossible, or are you suggesting we make some pluggable generic server side rendering that can be controlled by the client because css doesnt deal with heights very well yet?
> is there anything fundamentally flawed in the concept of html/css/javascript that makes portable sites impossible
No, of course not.
> or are you suggesting we make some pluggable generic server side rendering that can be controlled by the client because css doesnt deal with heights very well yet
Yeah, pretty much. That way you don't have to wait for the standards bodies or the browser developers.
To engineers who are accustomed to rigid runtimes, compilers, and so forth, this opinion that HTML is object code will resonate. However, it makes the assumption that by abstracting away the underlying HTML, you stand a better chance of delivering your program to the intended audience. I don't believe this is the case.
If you embrace the fact that HTML/JS/CSS will at best represent an approximation of the interface you intend to create, and leverage this accordingly, you will write code that will more easily adapt to best fit the environment in which it is run.
The power of web technologies is their resiliency. Programs written in compiled or runtime-based languages either run or they fail. Web code is much more dynamic. We should appreciate this characteristic, even when faced the frustrations of immature, misimplemented, and unsupported standards.