Web Standards vs JavaScript MVC
- published:
- 2014.12.28
- topics:
- javascript
Web standards pioneer Eric Meyer recently wrote a blog post asking folks to share what excites them about the web right now and what has their attention for 2015 and beyond. As many of you will know, Eric has been facing some significant life challenges, and he has reached out to the web community to find his way back into the flow. Eric's a great guy and generous person who has given a lot to the web community such as the An Event Apart conferences, the books he's authored, and he graciously supported the Minneapolis web scene by being an inaugural keynote at the very first MinneWebCon -- something that I quite personally appreciate.
Naturally, I was quite eager to reply to his post. As I began to write my comment, I discovered that a major theme had been bouncing around in my head unexpressed for awhile. My comment turned into a small essay. Eric Meyer's unique position in the industry and his history with web standards both make him the perfect audience for these ideas. I think what I had to say is important for all of us in the web community to consider, so I decided to reproduce an excerpt of the comment here on my blog as well.
So, please read on to see my thoughts on Web Standards vs JavaScript MVC. But also remember to head over to Eric's blog and share with him your own thoughts on what will be big in the web world in 2015.
Hi Eric! :)
If I had to pick just one single important development in the web industry that I think needs your attention, that thing would be JavaScript MVC libraries/platforms. Examples of these would be Angular, Ember, Backbone, React, etc. This might not immediately seem like your wheelhouse (well, this is an assumption, but I don't think you claim to be a JS expert) but hear me out...
These JavaScript libraries/platforms are shifting the very fabric and character of the web. Web servers are beginning to serve up basically nothing other than a large, obfuscated JavaScript file... an executable payload if you will. That runtime code then takes over entirely all handling of sending HTML/CSS to the browser on the client side. This is substantially different than the many-pages model of the past, or the idea that a web server should serve up a web page that is consumable without JavaScript or without a custom JS client. It's even starting to change the very nature of the idea of a URL. It has certainly changed the nature of View Source already.
Eric, the quickest way you can start to see for yourself the impact of these libraries would be to go to TodoMVC.com. Check out the Angular, Ember, and React examples in particular. View HTML source. Inspect the DOM. You are going to notice some things that are probably quite surprising. If you'd like, you could also view the JavaScript source code, but the usefulness of that will depend on your personal relationship to JavaScript.
These JavaScript MVC libraries have also led to a large influx of web developers who come from a backend or systems programming background. Tools like Angular are very familiar and comforting to folks who have little web experience but a lot of .NET server programming experience, just as an example. (Not meant as a slight towards .NET!) On the one hand, this is a good thing. It is making web publishing and development more accessible to a wider range of people. That's great! On the other hand, some of these folks are not familiar with web standards or the web standards movement. Many are used to a monolithic, single-corporate-authority coding platform. Some are not familiar with the idea or history of open standards.
Some of this is simply a product of people being new to web dev. There's nothing wrong with being new. However, this situation is also somewhat novel because many of these new JavaScript MVC developers are NOT new to programming in general. Also, somebody new to web design is likely to join a community with many mentors and will learn common and best practices through that lens. Whereas somebody coming to JavaScript MVC programming from a career of systems programming is less likely to join a community with mentors experienced in the history and culture of the web.
In hopes of being clear, I'm not saying any of these changes or technologies are in themselves bad. And, I have much faith in my fellow web developers to gradually migrate towards the best solutions. And of course progress demands that the web change with changing needs. In fact, I believe these JavaScript tools have a lot of good new ideas to offer that we will all benefit from. What I am saying is that there's a tremendous amount of rapid progress in the JavaScript development sector right now, and there's perhaps not a lot of context for the history of the web or how we got to where we are today. I think that a lot of the hard work that web standards advocates have done over the years could potentially be undone fairly quickly unless those folks in the web standards field turn some attention towards JavaScript and chime in on its progress.
It's an area of the web world that desperately needs leadership. There's dozens of competing technologies and ideas, and to some extent the ideas are competing via corporate marketing instead of via critical thinking.