We can taunt Ballmer for this half-insane nervous breakdown, but his message hit the mark. If you do not give developers the tools and knowledge they need to work with your system, they will not only experience difficulties, but they will also not be able to develop what you are working on!
Alas, in practice, we see that in this respect, the developers themselves can be their worst enemies. They choose terrible "frameworks" that make them work harder rather than smarter, or they deliberately flaunt their ignorance of the fundamentals and copy someone else's code in the hope that it will do the required task.
In no other area is this more obvious than in an arrogant, indifferent, if not downright contemptuous attitude towards HTML. There is no limit to the endless nonsense and erroneous statements from those who are unable to write a single line in this language.
In a nutshell, developers don't take HTML seriously enough, but what happens if you point out their weakness to them? In response, we will only wait for an endless stream of meaningless excuses as to why they should not be distracted by its correct implementation!
List of weak excuses
"HTML is not a real programming language"
It is a sequence of commands that computers follow to complete a task. If there is another definition of a programming language, then in four decades of writing software, I have not heard it. Is from Turing complete? No ... but nevertheless it tells the computer how to convey the grammatical and structural meaning of the content in a machine-independent way. There are rules for using its tags, order, and syntax.
"Nobody cares about the code if it looks right to the user."
Exactly until the moment you run into blind users. HTML is not just what the page looks like ... No! I'll fix it - HTML is not about how something looks at all. HTML is needed to communicate what the elements should be in terms of grammar and structure so that the user-agent can convey this value to the user. So we have CSS to describe how the elements should look . If any of your tags, ids, or classes communicate how the elements should look, then you have chosen the wrong code based on the wrong assumptions.
Screen readers (software for reading a page out loud), Braille e-books, TTYs… these are all non-visual targets; and don't forget that search engines don't have eyes either. They don't even care how your page "looks".
In addition, it is important for people that your page is slower or more expensive to host, or it violates accessibility guidelines for people with disabilities, or it clogs up the entire available channel. Non-semantic markup , endless and meaningless DIVs that do nothing, presentational classes - they all add up and affect the result!
You will hear the same excuses for many other aspects of web development, and it is almost always a lie. Whether it's bad / broken semantics, accessibility issues for people with disabilities, bloated optional JS, using "web application" technologies for things that shouldn't be an application, etc., etc.
Very often, when using all this, the user realizes that something is wrong, but cannot explain it. Users are not programmers, they do not know what the mistake is and who is to blame for it, but they feel that something is wrong, everything is at random.
What about the next unfortunate loser who has to support the result of your work, which contains all the errors from the list, how NOT to use HTML? People are always chatting about how their terrible broken "framework" is supposed to "help us work together." How can two or ten times the amount of code that does not conform to the basic rules of HTML and violate the very purpose of the language, can "improve collaboration"?
"But examples in frameworks work exactly like this, and they were written by experts"
They are not web development specialists. Rather, they are specialists in marketing, propaganda and deception. Markup in examples of systems like Bootstrap and Tailwind are nightmare HTML practices. They stink of a horrible mixture of “I don't want to learn HTML and CSS” and “I miss the markup of the 1990s,” giving up over twenty years of progress. Just because they are used by millions of sites ("the majority cannot be wrong"), and self-appointed experts sing praises to them (appeal to authority), does not make them or similar practices good.
"Vanilla code is harder to work with."
You make it difficult. That's the problem: By ignoring the semantic structure rules and the whole point of HTML's purpose, you make it harder to work with. Contributing to this is the fact that noob baits like W3Schools (aka W3fools) are overflowing with inaccurate information, vulgar simplifications, and the complete absence of most of the basic concepts of HTML.
Content should define the markup, content + markup + target environment / user-agent capabilities should define structure. By following the basic semantics, and by gradually improving and using the correct separation of functionality, you will end up with a set of instructions that make it easy to create easy-to-maintain pages. If you are having trouble with this and think that these "HTML / CSS frameworks" are making your life easier, then you don't know enough HTML or CSS to do any of the tasks.
In general, Tailwind is simpler than vanilla HTML / CSS, you just need to learn over 500 classes, 90% of which already exist as CSS properties, and then ignore almost all the rules of how HTML should be used!
In case you didn't get it, it was sarcasm.
"You attach too much importance to HTML"
I hear this nonsense all the time, and I am annoyed by its shortsightedness!
It's like saying that I pay too much attention to the soil under the construction site or the materials used to create the foundation. If you neglect such details, then do not be surprised that then everything will "in an incomprehensible way" collapse or be sucked into a karst sinkhole!
HTML is the foundation and cornerstone. If you neglect it, then do not be surprised that the results will be a complete disaster.
Indeed, many of the misconceptions that web developers use to convince themselves not to worry about the future are no different from those that lead to all engineering disasters. Saving on quality, ignoring specifications or the end user, fueling your own ego; besides, many make a fatal mistake - they confuse art with design.
The latter mistake leads to buildings that dazzle people with the sunlight reflected from their windows: someone who imagines himself an artist convinces people in costumes to spend billions on a project in which form is more important than function.
"But HTML doesn't give us the tools we need to deliver the UX."
There are many different versions of this excuse, but in general they imply the above. Those who say this almost always refer to fans of "web applications" or "single page applications", they try to use JavaScript everywhere, they don't care about accessibility for people with disabilities and insist that "users" somehow "need" all their fancy stuff to improve the "user experience".
But to be perfectly honest, these clowns know as much about UX as artists who have fallen into the illusion of being "web designers" know about design.
And you can see the results of their work NOW in our entire industry: fragile, swollen, slow solutions that "can improve scripting" slow down the shopping cart systems of online stores so much that many of them are not even able to maintain uptime (hello Zotac) ; at the same time, users are fiercely pressing on the F5, hoping that they will still be able to buy a video card. Because of reloading the entire page and re-running the script, all functions of the "application" only lead to a REDUCTION of the page loading speed. And this is even more pronounced if you spit on the markup using the presentational classes.
And since scripts can be turned off, and script-generated content is harder for screen readers, Braille e-books, and so on, single-page applications (SPA) violate accessibility guidelines for people with disabilities.
I’m not saying that SPA and the like don’t have any sensible uses, but if you cannot create a simple shopping cart or fast loading banking portal that loses little by disabling scripts, then you probably shouldn’t be doing any work. nor was it a business. Web apps should NOT be used for something ridiculously simple like a shopping cart on a website!
And if you think that using scripting to do this really improves the user experience, then you obviously haven't tested the system with real users and real traffic! At the very least, they did not perform a real comparison of the division of tasks using the cache in normal page loads and on pages with newfangled scripts.
So the web developer is to blame for everything?
No way . Let's go back to the beginning of the article and to Ballmer's cries of "developers, developers, developers".
When he played out his little sketch, it was designed to solve the problem that in the late 90s Windows was by no means in the first place, because developers often did not use the tools provided by Microsoft. Borland has published the best documentation for the Windows API. People were using non-Microsoft tools because "visual" languages were considered toys. They were so far behind web development technologies, we can say that they are still trying to catch up with them!
The W3C and WhatWG have similar problems with the so-called"Specs" are simply not written for the people who write websites. Let me repeat: the specification of the language used to write websites is not for the people who actually write websites . It's written for people who write user-agents! The browser is the user-agent, but the UA is not always the browser.
In fact, it's so absurd that the idiotic version of WhatWG's "dynamic document" refers to MDN for "mere mortals" to understand.
: , « » (living document), HTML- . HTML 5, , HTML 5, HTML 5 ? !
Simple fact: to get descriptions of tag meanings in plain English, you have to turn to third-party sources, many of which do not even agree with each other. What's more, the W3C has become completely toothless, blindly agreeing with everything WhatWG says, even though WhatWG has proven over and over again that it is not qualified to create a descendant of HTML 4 Strict. Acceptance of EMBED as a valid tag, creating and / or maintaining tags that are redundant relative to OBJECT, no longer supported (fortunately) the HGROUP tag, which showed that they do not even understand what numbered headers are for and how to use them ... who worked on it, the challenge for HTML 5 has never really been to create a specification or standard that tells us how to build useful websites!It was about documenting whether people are doing right or wrong today and that browsers can support, but not what they should support! Given that during the development of HTML 5, most developers still pushed in HTML 3.2 and sketched the twisted doctype of HTML 4 on top of it, why be surprised that everything turned out to be such a cluster of bad, outdated and old-fashioned practices?
If developers don't take HTML seriously enough, then those who developed it as a "specification" are to blame; even calling it HTML 5 was such a serious crime against web development ... Just like a crime against music was giving a Grammy to Billie Eilish for her mediocre creations.
The W3C and WhatWG are not even taken seriously by other standards organizations, and for good reason.
What should be the solution?
It would be a good idea to start with getting developers not to perceive HTML as an underdeveloped child from the world of programming languages. In particular, getting them to practice semantic markup with separation of presentation from content, which will greatly increase usability, accessibility and efficiency.
In addition, we ourselves, as developers, have our say and baffle the W3C for the disastrous failure of its work as a certification body . We need to demand simpler and cleaner language documentation from the official source. It cannot be justified that a document describing something as simple as HTML is five to ten times longer than the constitutions of most developed countries.The very fact that the specification of the language used to build websites is not written for the people who use the language to build websites is a vote of no confidence.
But we need more than just improved official documentation, we need to cut down the language, make it more task-oriented. Revive many of the ideas that were contained in HTML 5 before the W3C threw them into the trash and adopted the WhatWG version. The fact that Microsoft has spent decades making IE prevent us from using OBJECT is not a reason not only to keep the IMG tag, but to add many new tags unnecessarily (VIDEO, AUDIO). Just because "artists" and marketing crooks like to open new windows for the user, whether he likes it or not, is not yet a reason for the specification to include
TARGET="_BLANK"
...
Moreover, the EXPLICIT use and meanings of tags should be placed at the center of the specification , and maybe even in a separate use guide for those still living in 1997.
Creating a simpler, cleaner, more useful version of HTML that will guide us all is not a big deal.
In addition, it will be useful for us if the browser developers have less weight when creating it. Microsoft, Mozilla, Apple, and Google have a huge impact on the W3C and WhatWG, and this is completely unethical. Their weight in decision-making goes against the very concept of a free and open web.
Advertising
Epic servers are VDS for hosting sites from a small online store on Opencart to serious projects with a huge audience. Create your own server configurations in a couple of clicks!
Join our Telegram chat .