Comments for Hoisted From The Comments
We're certainly in agreement that more strictness narrows the audience, but some measure of strictness is unavoidable. Some level of strictness is required to give a language structure. For instance, people who want to play in the HTML space must be able to read, write, and operate a keyboard. They can't simply mash out random characters and expect meaningful results. When it comes to HTML, illiterate people can't play. Would it be nice if illiterate people could play with HTML? Absolutely! Is it possible? I don't think so.
Obviously, the appropriate level of structure and strictness is highly dependent on the task at hand. But less strictness is not always useful, or productive. <valleygirl>Like, you know, whatever!</valleygirl> (should I start that sentence with a "" tag for clarity? hmm...)
Regarding iteration: feedback is a good term to use, since tight feedback loops are vital to rapid iteration. However, certain forms of feedback require strictness (type systems being a good example). So, setting up strictness and feedback in opposition to each other doesn't seem like a useful way to pursue our goal of providing less hassle and more livablity in our systems.
"no" is the only valid feedback in some cases. Saying "no" is feedback to the designer that their input is non-computable. Saying "no" is failing loudly, and failing early, when the designer's attention is on design and diagnostics, instead of (potentially) days/weeks/years down the road when they've moved on to other projects, and must do a mental full context switch before fixing a problem. Saying "no" can help the designer fall into the pit of quality.
I'm very exited to see what sort of workflow is enabled by optional typing, but I can't agree that runtime type strictness has few gains. Programs fail at run time, and no matter how well we test and type-check at design time, it's almost impossible to account for every failure mode. When (not if) a program fails, diagnostics are much more efficient if the type information is available. In fact, diagnostics are almost always part of my design workflow, so I would argue that tight feedback diagnostic feedback loops are just as important as tight design feedback loops.
So yes, I didn't outline the entire spectrum of strictnesses in this post, but you've hit on the essential nature of the differences without considering the impact to people other than yourself. I.e., the stricter you are, the fewer people can play. If you don't think this is the case, I ask you to consider what the anchor tag (<a href="...">) means. There is no strict definition for what it does, only convention. Think beyond its parsing, its very behavior is ambiguious. Clicking on one isn't guaranteed to do anything in a browser by any particular spec and nobody much cares. As a result of both parsing and behavioral ambiguity, an order of more people can use anchor tags than can write the equivalently functional JS.
Finally there's the question of feedback. You're saying "strictness at development time helps", but I'd like to push back on this and suggest that what you're really putting your finger on is feedback. You want to see the effects of what your program will do quickly. Types are a handy way of saying "please give me feedback about this thing in this small scenario". Optional and gradual typing (currently best understood in the form of Dart) gets you there but still breaks the "you need types at runtime" fallacy. Put another way, your runtime gains little by being strict and in fact can get a lot of leverage out of ignoring strictness and just muddling on.
So yes, I feel the pain you're describing, but it's time to stop asking for strictness and start asking for feedback. One is about saying "no" and the other is about saying "this is what will happen, what do you think about that?". I know which one I want and the evidence is that systems which give you feedback and not a hassle are the ones that will be better to work and live in.
3rd paragraph (supposed to be: if ): it’s about relationships. “This thing references that thing over there and does something with it” is hard for a search engine to tease out <> it’s hidden in code, but if you put it in markup
Second-to-last paragraph (missing word: that) Combine that with systems that let you iterate fast, and you can grow very large things <> can evolve in response to user needs without turning into spaghetti quite so quickly.
Last paragraph (supposed to be: for ): So lets banish this sort of small-town thinking to the mental backwaters where it belongs and get on with building things <> everyone.
Great post, caused me to consider the issue of JS vs markup.. and strict in what you output or input.. and I had to look up a11y (I learned is shorthand for Accessibility). Thought provoking for sure.
JSON's lineage is from programming which is definitionally strict, and as a result, is the purview of a much smaller community of producers than either those who build markup or the designers who use tools. To the extent that the web depends on programming and not markup, the group of people who can produce it will shrink. If you think that's a good thing, I suggest you take a look at the history of what happens when economies of all sorts begin to shrink. It ain't pretty.
But will widespread JSON usage lead to leniency? I think so. Many JSON parsers accept JS-style comments today, over and above the dead body of RFC 4627. I've seen leniency in parsing of trailing commas, etc. Many parsers have support un-quoted property names. It just comes with the territory.
As for MDV's role in all of this, I'm incredibly hopeful that the common mode of use for MDV will be as progressive enhancement. I.e., you'll serve your DOM in the page as your "fallback content", that will be consumed by MDV as the model, and your templates will be what is cached and applied later to generate the UI. MDV does operate on a JS object tree, but that tree can be DOM, and if it's an HTML DOM, can continue to reap the benefits of reliable parsing. I'm optimistic as a result.
Regards
Is the proliferation of application/json a counterexample to this argument? Or is it a format in need of displacement? Does JSON.parse need a fault-tolerant parser? Do we need to consider the impact of introducing something like Model Driven Views that encourages use of JSON?
Matt: I don't know of any system that re-works XHTML for HTML today other than the reliable parsing of browsers. I.e., do you have a system that fixes <br/ and turns it into <br? I'd love to see such beasts and hear how people get on with them.
My ideal system would be an editor in the web inspector that has something like jshint for HTML embedded, that way I'd be able to see the real-time effects while getting feedback based on (customized) rules. Those rules should never be an exception (the thing won't load), but instead should be highlights and advice.
Strictness enables (relatively) unambiguous expression of a developer's intentions. As long as (roughly) deterministic behavior is needed in our products and services, some level of strictness will be required.
Also, I personally find that a certain level of strictness very helpful when it comes to rapid iteration. For instance, I find it far less time consuming to refactor code in a strongly typed language, because the compiler/interpreter will catch a lot of human errors (e.g. passing in a date object into a function that used to accept a formatted string). In dynamically typed languages, such mistakes often aren't caught until runtime, unless I re-invent a static type system with unit tests.
This seems to be what Austin's doing too. He (?) mentions "XHTML 1.1" in context of developing HTML applications. I don't think he's actually publishing anything using an XHTML doctype. This sounds like a sane practice to me.
Something my team has to deal with on a daily basis is multi-language, multi-region contexts for presentation, data and business logic. We also run a/b/m-v tests continuously and beta test site re-designs and new features regularly on multiple sites.
This may not be a typical scenario but I'm sure there are others who share our pain points.
MDV looks good but how long do we wait?
In the meanwhile we are looking to implement server and client templating using the same model (JSON) and the same markup (Mustache spec) but thinking seriously about whether the server side app is needed at all (outside of SERP considerations).