We lost that web

In short : after the browser wars, the W3C organization and development teams, such as the Web Standards Project, worked long and hard to restore a single unfragmented Web. But in the past few years, we, the developers, took it, and re-started everything again ... Probably, we need to understand what we are losing before we lose this web forever.

Exactly one year ago, the web industry patriarch Anil Dash wrote: " We lost the Web ", grieving over the early, pre-social blogosphere, before all these postings of our photos, videos and thoughts that find the last shelter in the catacombs of Facebook, Twitter, Instagram, and YouTube. This caused a response from many who caught those days; many who, ironically, then went to work in these catacombs.

Especially if that very period, approximately until the mid-2000s, was before your full-fledged presence on the Web, you should find time to slowly read his article in order to take your time. The web has indeed changed over the past decade, and not always for the better. Anil writes:

“We lost the basic ideas that were at the core, and even worse, we abandoned the fundamental values ​​that were in the origins of the web world.”

... and notes that one of the goals for which he wrote a note is for people who create new social applications to touch history, to know its origins.
')
Probably, some of these ideas are really in the air, because in the last couple of weeks Faruk Ateş and Jeremy Keith have also been thinking about this topic.

And I, including most of the past year, thought about this, feeling that we lost some of the early web, although I thought about a much more limited part of the Internet. The fact that usually does not come into the view of most web users - about its code. I think that it also refers to " ... abandoned the fundamental values ​​that were in the origins of the world of the Network ."

Browser Wars

Anil has been talking about the Web since about 2000, but I want to talk about the term from about the mid-1990s. Now almost all of us have heard of browser wars. If you ask what happened then, most will say that it was a time when Netscape and Microsoft struggled to control the Internet, trying to make their browser dominant.

But in what way they tried to achieve dominance? In a sense, browser wars (originally Netscape and its predecessor Mosaic fought each other) may be called “HTML Wars” because the battlefield, figuratively speaking, for numerous browsers, including those that appeared before IE, was HTML.

There was no "standard HTML version". Instead, new language features appeared with new versions of browsers — such as img, lists, tables, frames, font, embed tags, and so on. Entire languages ​​appeared (Javascript) and complex architectures such as DOM. Basically, it was good. The web has increased in complexity and quickly acquired vital functions.

But none of the functions was initially standardized, no one developed standards, each of them initially appeared in one of the browsers, while others hurriedly redesigned successful solutions and then implemented them themselves, usually in the form of a somewhat incompatible version.

From this period, we learned that the one who “walks first” wins (for example, the “img” tags proposed by Mark Andressen, despite the opposition of Tim Berners-Lee, who advocated a more flexible mechanism, won and continue to appear to us today ). Decisions made at the architecture level can have a very long half-life, therefore they should be made very carefully.

This is a common fad of today's complaints from web developers; in other words, the mismatch of browsers is a headache in web development. Imagine how to develop sites on the most recent, barely made and poorly documented features that change with each release of browsers?

It was this chaos that the W3C group saw, whose role, as before, is often not understood. The purpose of this committee was and remains - to establish a dialogue of stakeholders, in order to standardize innovations. A little later, web developers felt the need to uphold the adoption of new standards, and the Web Standards project was born (which, no matter how ridiculous, stated earlier this year that “Our work here is finished.” Why is it funny, we will look at it a little later).

But it seems that we lost sight of the fact that the consequence of browser wars and the subsequent basis of the W3C and the Web Standards project was the avoidance of "balkanization" on the Internet. We knew that universality and compatibility were important to the Internet. And we knew that the Galaxy was in danger because of browser fragmentation.

And absolutely admirable, especially if you are familiar with the events of the Internet of the late 1990s, with the opposition of Netscape's JSSS (JavaScript StyleSheets) and CSS, incompatible undocumented DOM, JavaScript and JScript, and the fierce battle between Netscape Communications and Microsoft - we created A web that was not fragmented, standardizing HTML, CSS, JavaScript, and DOM, giving exhausted developers the benefits of such a web. It was a remarkable achievement; The efforts of many people from Microsoft, Apple, Mozilla and Google have done a great thankless job of standardizing technologies by those who advocated training developers of standards-based technologies. Some have become well known, most have worked hard for modest rewards, but everyone felt that this is how the web should be.

And then, step by step, like that frog , which does not notice its death in slowly boiling water, we threw this web away.

• We allowed, encouraged and accepted the fragmentation of the DOM libraries and frameworks, each of which has its own way of accessing attributes, changing elements and managing the DOM.
• We have fragmented javascript languages ​​compiled into it.
• We have fragmented HTML with tons of template engines.
• We have fragmented CSS with preprocessors like Sass and Less.

What have we done?

This does not mean that everything around is completely bad. Far from it. Each of these technologies and innovations brings new concerns to developers. Many are setting out ways for future standards. But in the aggregate, we have taken a relatively simple set of independent technologies - HTML, CSS, JavaScript, DOM; each with its well-defined roles, each relatively complete, to master and start working with it, and created a chaotic zoo of competing technologies, many of which do exactly the same thing, but somewhat different and incompatible.

And on this path dependencies on other languages ​​and environments were added, because the assembly stage appeared in the workflow, which was not the case before on the Web.

What did we get?

Perhaps the developers now - more productive. Perhaps we made life easier during the initial phase of project development. But there is reason to doubt that there is more than individual successes in the name of maintaining faith. Believe me - this is a common argument of any new technology - that it will make the development more productive. You read something from your literature? (Recall how slightly higher we were convinced to remember our heritage.) And software developers have long understood that only a small percentage of the system’s cost refers to the initial stage of its development. Maintenance over the years and decades - a very significant proportion of the cost of the system (yes, there is a lot of literature on this topic).

But what have we lost?

Once upon a time, web development began to differ from most other technologies in that we spoke the same language, some Koine , lingua franca , like the development for Windows, the largest platform for many years, where a myriad of languages, fundamentals and development environments were based on Windows API. This common language brought with it a number of advantages, including facilitated learning of web technologies and simplifying project support. This has increased the vitality of your knowledge and experience of the web developer.

Learnability

Having a common set of technologies for the frontend has simplified learning. Finding textbooks, experts, and working meetings on these technologies was relatively simple. Mastering skills and knowledge was relatively simple. You can write some HTML and CSS code and build something useful. Over time, you will be able to increase your knowledge of them and add an understanding of JavaScript and DOM to expand your capabilities. There was a network effect due to the existence of a large group of developers having common languages ​​and concepts.

Do we really want to reduce this network effect by fragmentation of technologies on the Internet, by digging into the catacombs of institutes of expertise, with an insignificant share of a common language? We should at least be aware of the potential consequences of our choice. Realizing not only the individual advantages of choice, but also the fact that we can lose together.

Maintainability

Having a common set of technologies makes it easy to maintain the existing code base. The underlying technologies HTML, CSS, JavaScript and DOM are stable for a long time, unlike most frameworks, libraries, languages ​​and preprocessors (not to mention the tools and languages ​​they partially rely on). Will the base of your service be maintained for 5 years? And, based on less common technologies, the number of developers capable of maintaining the code base is significantly reduced.

Traditionally, more than half of the cost of a complex system came during the operation phase, so that with a large restructuring it is easier to throw everything away and start building anew than to lead the evolutionary development of software projects; what we are building for the Internet is becoming increasingly difficult, and for mission-critical projects, the maintenance phase will become more and more lengthy and costly. And again, it is well understood that maintainability depends heavily on the capabilities of disparate developers to understand and have reasons (motivation) to maintain the code base for a long time than simply using copy-paste for page edits . ].

Interaction

One of the basic principles of the Web is "compatibility." While this directly concerns the concern that “computer languages ​​and protocols ... are designed to avoid market fragmentation in the past,” I would argue that not only should fragmentation be a concern when it comes to systems with our running code. We should also be concerned about the fragmentation of the web development community. The fewer developers with a working knowledge of technology, the less opportunities for them to interact on technology issues.

From the same circle - the question of how technology will interact with each other. Let's say you like how Sass implements variables, but you also want to use @ debug in LESS. You need both LESS and Sass, and probably a bloody mess breaks out. The monolithic approach of many “innovations” significantly influences how they interact with each other.

Durability

If you have spent years developing knowledge and experience in Flash or Silverlight / WPF, this knowledge will become increasingly useless. The same will happen with jQuery, as it was with other seemingly dominant JavaScript libraries and frameworks such as Prototype. This will happen with all libraries and frameworks that we study so hard today: AngularJS, Bootstrap, <... substitute your name ...>. Very few technologies have lived in recent years, not to mention decades. As a person who spends a reasonable amount of time studying technology, I would be concerned that the effort be justified.

What to do?

jQuery, Backbone, AngularJS, CoffeeScript, Bootstrap, Sass, LESS (just to name some of the most popular frameworks, libraries, languages ​​and preprocessors that we have developed over the past few years to solve problems in order to do more and more complex things without highlighting anything specific ) are complex, powerful technologies, well proven in so many workflows used by thousands, tens of thousands of developers or more. They do not leave. And after them others will come. You may need a slow dive from high technology in HTML, CSS, DOM, JavaScript. In the end, programmers do little, if at all, write in assembler, let alone machine code. But, as Anil Dash wrote about another web, " we abandoned the fundamental values ​​that were in the origins of the web world ", and I think this is true of the code being created.

What could be these core values? It is not difficult to see that they are clearly described by the W3C consortium (once again, the words of Anil: “ learn a little history in order to know your sources ”).

“W3C is committed to technical excellence, but is well aware that what is known today may not be enough to solve problems tomorrow. Therefore, we strive to build a Web that can easily turn into an even better Web without disturbing what is already working. The principles of simplicity, modularity, compatibility and extensibility underlie all our designs. ”

W3C objectives, operating principles and their focus

Do developers follow these principles of simplicity, modularity, compatibility, and extensibility when they develop new languages? Frameworks? Preprocessors? Of course, in many cases - yes. This is especially true of polyfills and prollyfills . They have no goal to “boil the ocean” by organizing a vast array of functionality, but rather follow the model of “free joining small pieces” that do one thing but do it well.

But in many cases, our solutions are not modular, not simple, or incompatible (especially in arbitrary combinations). In fact, I would say that this is the crux of the matter. Instead of solving a specific problem through simplicity, modularity, and compatibility, our solutions often become increasingly complex piles of solutions for all kinds of problems. For example, the pre-processor CSS architects report on Sass design principles :

»There is no formal process by which we add new features to Sass. Ideas can come from anyone, anywhere, and we’re happy to review them from the mailing list, IRC, Twitter, blog posts, other CSS compilers, or any other source. "

... which rather resemble Homer :

Free connection of small pieces

In 2002, one of the pioneers of the web, David Weinberger (by the way, co-author from Cluetrain Manifesto) described “ small loosely connected pieces ” - a way of thinking that makes the Internet special. I have long thought that this also applies to Internet technologies, and these principles should determine how we create projects for the Internet, be it our own sites, for our clients, employers, or the technologies themselves that are evolving on the Internet.

If every time we took a solution to a problem, we would think, “how can I solve this little problem?”, Or even “ is this really the problem?” And then solve it on the principles of modularity, compatibility, and extensibility, as far as possible, we will take a long way to tame the explosion of complexity that we have seen during the last five years or so, and return, at least in part, to the Web that we have lost.

Perhaps this web would also have to grow up to respond to the challenges of increasingly complex models that we are building. When the web consisted of documents and websites, perhaps we would have kept the simplicity, but in the age of applications simplicity is a luxury that we cannot afford. Perhaps over time, fundamental improvements of all necessary platform fragments will be needed.

But, before we lose this web forever, I think that we must truly understand that web and what ensures its efficient operation. And when we make technical, architectural decisions about how the web will be, we should not think only about our own benefits, but also about what the current Internet will lose with them.

UPD 12.12.2013 16.00 : It is interesting to compare what the author's blog wrote in a week and here in a day; Let me give you the beginning of the translation of English commentators, all in a row:

In general, there is a little more, but for a week, all the same, but we are not lagging behind in the full analysis of the situation, we noted all the special moments in the comments.