We lost that web.

Original author: @johnallsopp
  • Transfer
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 developers have taken and fragmented everything again ... Perhaps we need to understand what we are losing before we lose this Web forever.

Exactly a year ago, web industry patriarch Anil Dash wrote: “ We lost the Web, ” mourning the early, “pre-social” blogosphere, for all of our postings of photos, videos and thoughts that find their last refuge in the catacombs of Facebook, Twitter, Instagram and YouTube. This resonated with many who caught those days; many who, ironically, then went to work in these catacombs.

Especially if that period, until about the mid-2000s, was earlier than your full presence on the Web, you should take the time to slowly read his article thoroughly. The web has indeed changed over the past decade, and not always for the better. Anil writes:

“We lost the basic ideas that underlie, and worse, abandoned the fundamental values ​​that were at the root of the web world.”

... and notes that one of the purposes for which he wrote a note is for people creating new social applications to touch history and find out its origins.

Probably some of these ideas really are in the air, because in the last couple of weeks Faruk Ateş and Jeremy Keith have also been thinking about this topic.

And I, for the most part of the past year, thought about this, feeling that we had lost something from the early web, although I was thinking about a much more limited component of the Internet. About what usually does not fall into the field of view of most Web users - about its code. I think that it also applies to him " ... abandoned the fundamental values ​​that were at the origins of the world of the Web ."

Browser wars


Anil has been talking about the Web since about 2000, but I want to talk about the term since 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 were fighting for control of the Internet, trying to make their browser dominant.

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

There was no “standard version of HTML." Instead, new language features have appeared with newer versions of browsers - such as img, lists, tables, frames, font, embed tags, and so on. Entire languages ​​(Javascript) and complex architectures such as the DOM appeared. It was mostly good. The web grew in complexity and quickly gained vital functions.

But none of the functions was originally standardized, no one developed standards, each of them initially appeared in one of the browsers, and the others hastily re-engineered successful solutions and then implemented independently, as a rule, 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 be to this day ) Decisions made at the architectural level can have a very long half-life, and therefore must be done very carefully.

This is the usual fad of today's web developer complaints; simply put, browser mismatch is the cause of the headache in web development. Imagine what it takes to develop sites on the latest, barely made and poorly documented features that change with each release of browsers?

It was this chaos that the W3C group saw, the role of which is still often not understood. The purpose of this committee has been and remains - to establish a dialogue of stakeholders in order to standardize innovations. A bit later, web developers felt the need to uphold the adoption of new standards, and so the Web Standards project was born (which, funny as it may seem, at the beginning of this year stated that “Our work here is finished.” Why it's funny, we will look a bit below).

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

And it’s absolutely amazing, especially if you are familiar with the Internet events of the late 1990s, with the confrontation of Netscape’s JSSS (JavaScript StyleSheets) and CSS, incompatible undocumented DOM, JavaScript and JScript, a fierce battle between Netscape Communications and Microsoft - against this background we created A web that was not fragmented by standardizing HTML, CSS, JavaScript, and the DOM, giving exhausted developers the benefits of such a Web. It was a wonderful achievement; Many people from Microsoft, Apple, Mozilla, and Google have done a lot of the ungrateful job of standardizing technology with those who advocated educating developers on standards-based technologies. Some became well known, most worked hard for modest rewards, but everyone felt that the Web should be just that.

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

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


What have we done?


This does not mean that everything around is completely bad. This is far from the case. Each of these technologies and innovations brings new challenges to developers. Many are charting ways for future standards. But collectively, we took a relatively simple set of independent technologies - HTML, CSS, JavaScript, DOM; each with its clearly defined roles, each relatively finished to master and start working with it, and created a chaotic zoo of competing technologies, many of which do exactly the same thing, but in a slightly different and incompatible way.

And on this way, dependencies on other languages ​​and environments were added, because the assembly stage appeared in the workflow, which the Internet did not previously have.

What did we get?


Perhaps the developers are 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 development more productive. Did you read something from your literature? (Remember how you convinced us to remember our heritage a little higher.) And software developers have long realized that only a small percentage of the cost of the system refers to the initial stage of its development. Maintenance over the years and decades is a very significant fraction of the cost of the system (yes, there is a lot of literature on this subject).

But what have we lost?


Web development once began to differ from most other technologies in that we spoke the same language, some Koyne , lingua franca , like the development for Windows, the largest platform for many years, where a myriad of languages, foundations and development environments was based Windows API This common language has brought a number of advantages, including easier learning of web technologies and simplified project support. This has increased the vitality of your web developer knowledge and experience.

   Learnability

Having a common set of technologies for the frontend simplified the training. Finding textbooks, experts, and workshops on these technologies was relatively straightforward. Mastering skills and knowledge was relatively simple. You can write some HTML and CSS code and build something useful. Over time, you can increase your knowledge of them and add an understanding of JavaScript and the 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 fragmenting technology on the Internet, digging catacombs of institutes of expertise, with a fraction of the common language? We should at least be aware of the potential consequences of our choice. Realizing not only the individual advantages of the choice, but also the fact that together we can lose.

   Maintainability

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

Traditionally, more than half of the cost of a complex system came during the operation phase, so with a big change 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 more and more difficult, and for critical projects, the maintenance phase will become more and more lengthy and costly. And again, it is well understood that maintainability is highly dependent on the capabilities of disparate developers in order to understand and have reasons (motivation) to maintain the code base for a long time, than to simply use copy-paste for editing . ].

   Interaction

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

From the same circle - the question of how technologies will interact with each other. Say you like how Sass implements variables, but you want to use @ debug in LESS as well. You need both LESS and Sass, and probably a hell of a mess will erupt around. The monolithic approach of many “innovations” significantly affects how they interact with each other.

   Durability

If you have spent years developing knowledge and experience in Flash or Silverlight / WPF, this knowledge becomes more and more useless. The same thing will happen with jQuery, as it was with other seemingly dominant JavaScript libraries and frameworks such as Prototype. This will happen with all the libraries and frameworks that we study today so hard: 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 efforts are justified.

What to do?


jQuery, Backbone, AngularJS, CoffeeScript, Bootstrap, Sass, LESS (we’ll just name some of the most popular frameworks, libraries, languages ​​and preprocessors that we have developed over the past few years to solve problems, to do increasingly complex things without highlighting anything specifically ) are sophisticated, powerful technologies, well proven in so many work processes used by thousands, tens of thousands of developers or more. They do not go away. And after them others will come. You may need a slow dive from high technology to HTML, CSS, DOM, JavaScript. After all, programmers write, if at all, assembly language, not to mention machine code. But, as Anil Dash wrote about another Web, " we have abandoned the fundamental values ​​that were at the forefront of the web world.", and I think that this is true with respect to the code being created.

What can be these basic values? It is easy to see that they are clearly described by the W3C consortium (once again, Anil said:“ learn a little history to know its origins ”) .

“The 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 breaking what already works. The principles of simplicity, modularity, compatibility and extensibility underlie all our designs. ”
      W3C Objectives, How It Works, and

Are They Oriented Are developers guided by 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 for polyfills and prollyfills . They do not have the goal of “boiling the ocean” by organizing a huge array of functionality, but rather, they follow the model of “free attachment of 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 essence of the issue. Instead of solving a specific problem through simplicity, modularity and compatibility, our solutions often become more and more complex piles of solutions to all kinds of problems. Here's an example of what CSS pre-processor architects report on Sass design principles :

»There is no formal process by which we add new features to Sass. Suitable ideas can come from anyone and everywhere, and we are happy to see them from the mailing list, IRC, Twitter, blog posts, other CSS compilers, or any other source. "


... which are more likely to resemble Homer :


Free attachment of small pieces


In 2002, one of the pioneers of the web, David Weinberger (incidentally, co-author of 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, whether it be our own sites, for our customers, employers, or the technologies themselves that develop on the Internet.

If every time we took a solution to a problem, we thought, “how can I solve this small problem?”, Or even “ reallyis there a problem? ", and then solve it on the principles of modularity, compatibility, and extensibility, as far as possible, we will choose a long way to tame the explosion of complexity that we have seen over the past five years or so, and will return, at least partially to the Web that we lost.

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

But, before we lose this web forever, I think that we should really understand that web and what ensures its accurate operation. And when we make technical, architectural decisions about what the web will be like, 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 wrote on the blog in a week and here - in a day; I will give the start of translations of English commentators, all in a row:

start comments on the English version
* Brilliant article! I think that these phenomena are cyclical, and that the current fragmentation will be standardized, and fragmented again, because people will come up with various solutions in order to work effectively. ...
* I struggled with this quite a bit myself, moved from Jquery to the “old-fashioned” vanilla, and there was a craving for Sass, and more and more people are looking for experience with them ...
* Some significant events in the history of the web. We see the advance of technology, as in other areas ...
* This is a really good post, you make a lot of excellent observations.
* It's all bloated. I have been making websites of the year since '97, DOM, CSS and template languages ​​- not problems of the same order as they were in the Netscape and Microsoft war. They all come down to standard technology ...
* Powerful article - I feel that most technologies require warnings about moderate use ...

and another 5-6 comments.
In general, there is a little more, but for the week, nevertheless, but we do not lag behind in the completeness of the analysis of the situation, we noted all the special points in the comments.

Also popular now: