The idea of the Semantic Web has been present since 2001. Back at 2006, Tim Berners Lee, widely recognized as the inventor of the World Wide Web came publicly with an initiative that was supposed to make the web a better place. The goal was to form a web of data which would contain elements linked by ontologies. The ontologies are actually a formal way to represent naming, types, and relations between elements.
Some tools for this purpose were built, such as RDF (Resouce Description Framework) who’s purpose is to describe internet resources,
The benefits of this approach are obvious, it would make the web more searchable and accessible.
Even though that exact idea didn’t get much further, the goal of standardizing the web remains.
One of the efforts in this regard was the adoption of HTML5, which is an HTML specification that has semantics as one of its core ideas. For example, anyone can notice that recently <b> and <i> tags in HTML are replaced with <strong> and <em> tags. This is because bold and italic are too much presentation related, and don’t speak much of the content. Bold and italic wouldn’t matter much on a browser for blind people, for example.
Separation of concerns
This leads us to the next point which is – the separation of concerns. To be more precise, one of the key Semantic Web concepts is the separation of content and presentation. It’s a philosophy that says that the meaning of any document should be contained in one place, while that the logic for presenting it should be in another.
In the usual setup, it would mean that the content should be covered within the markup language – HTML, while styling should be done with a tool that is intended for such a purpose, such as CSS. I think that this makes sense in practice too, as by structuring HTML around what content actually means, rather than how it looks, you can later change the way it looks without having to edit both the HTML and the CSS.
My intention was to talk generally about the idea in this article. I don’t do much frontend stuff, so I am not going to discuss the actual development of Angular or Bootstrap apps, but rather the consequences it creates.
The most problematic thing to me is that frameworks such as Angular, Ember or Bootstrap clutter your HTML with needless elements, attributes and attribute values which make your HTML not conform to the original specification.
Personally, I don’t see how Angular’s ng-click is better than onclick, as these new attributes are not part of the original HTML specification. Yes, there are workarounds for this, if we are talking about Angular, but unfortunately most people don’t use them.
Bootstrap also has a bad practice of giving non semantic class names and if you thought that class names don’t matter, check this . Class names like “big” and “small” are diminishing the efforts to achieve separation of concerns.
It just doesn’t contribute much to bringing order to something that matters so much to everyone, don’t you think?
Would you like to recommend this article to your friends or colleagues?
Feel free to share.
Thank you for the bright thoughts on the current front-end state. Although this article dates from mid-2015, the topic still produces sparkles between back-end and front-end colleagues.
Should we bring order to something that matters so much to everyone? Yes, we should. We are developers and that is actually our primary responsibility.
Bootstrap looks completely misunderstood and overused today. It is not a production framework, but a tool for scaffolding web projects and rapidly prototyping. If you are worried about the best practices, Bootstrap offers the ways to achieve them: you can extend custom Sass (now an official port) class names with Bootstrap ones and keep the markup clean.
Bootstrap is great to learn from, even from its weaknesses. Every front-end developer should be able to think in a component-based way. With the help of several CSS naming concepts (BEM, SMACSS, OOCSS), you may create highly flexible and modular front-ends that fit your/company needs. This process may take some time and that is why many companies today rely on a half-baked solution. The benefit of having an internal front-end framework is a lower dependency and higher maintainability.
Angular’s `ng-click` isn’t that bad because it is actually a shortened HTML5 attribute `data-ng-click` but compiler handles it behind the scene. I wouldn’t call it a valid tradeoff but we may prefix all the custom attributes with data-* and validator will be happy. As someone said “single-page apps draw a line in the sand of progressive enhancement” and that might be an issue. The question is what are you building and who is going to use it? If your app is going to be used by a specific organization or banking department people, it may be perfect to use (or create) a framework when you know the exact context and required features.
The web is an evolving medium—our expectations and playful interactions were unimaginative in the 90s, not to mention the range of devices, browsers, operating systems etc. Front-end today has to fit in various development and deployment processes, support different environments, care about security, handle data provided by back-end (REST), communicate asynchronously, and do a lot of stuff that wasn’t intended initially.
I believe the nature of client-server communication will continue to develop even more, provide the new frameworks, tools and paradigm shifts because our wishes and artificial needs will never expire :)