Oh this web

About a year ago, I seriously thought about the topics about hatred for html, recently made noise on the Habr. Indeed, html is just a means of markup the text, it can not be used to build a UI, which is 90% of layouts. Rather, you can, but hell turns out. Among other things, the case with html is when data is mixed with a view. It will not work to download separately html, but separately data. There is an idea of ​​parsers.

And even if in a thousand and one template engines this separation is explicit, then it ceases to be such at the output. Has anyone wondered why the server is generating a view that the user needs, but does not need the server? In addition, there is a problem of checking the data displayed for all users: these xss and so on. I didn’t close the tags - I killed the site, which also fell on users.

In my opinion, the only html task is to display br, strong, a, and so on. There is no need to try to lay out in blocks, because block layout is an attempt by html agents to make layout. And the whole idea of ​​hierarchical block content crumbles to dust when a child crawls out of the bounds of the parent. Who ever came up with such an inconsistent idea of ​​encapsulation, why is this even possible? WYSIWYG, from the point of view of the code, is somehow strange - you see one code, and it can be displayed as anywhere. Why is this ambiguity needed?

And it will not work to make a complex blocky ui without crutches of the form -999px, etc. By the way, why is there still no native support for layouts? Already in a low level language it is faster to describe an interface than on the web. And note: each designer is scolded over the creation / styling / placement of controls that have long been in ANY OS. So why so many gestures to create the same, but different? For what? By the way, why should each site have a unique design? Is this something forced? Why is desktop ui with the same controls not bored, and how very motley-non-standard interfaces on the desktop are considered bad manners? Well, yes, you can write another 20 pieces of template engines that allow you to abstract from the sad realities. And let designers use their -99999px nails to nail ui to html.

The comments suggested that QML be embedded in browsers. This, IMHO, is a very interesting approach. By the way, no one bothers to generate qml using the same methods as html.



To summarize, the logical web for me would be:
  • user accesses the address% s
  • the server gives it one script, binary, or qml code
  • the code independently uploads public content from, for example, redis deployed to public
  • the client script independently generates the ui representation from this data, while simultaneously escaping and everything else
  • as soon as the user needs a private area, the usual methods give him session_id / private_code
  • further communication of the client and server is mq. Key mq = session_id. Redis will handle it at first.


There are several projects that use redis in this way, but this is not mainstream. The idea itself is pleasant in that the data is not sent to the same place (and not then) from where they were asked. The user himself repeatedly requests for the data that he needs. And does what he wants with them. In this case, let him write at least his own ui.

As a result, the task of the programmer will be only one: to write business logic that generates the correct data. And that’s all. That is all at all. And what to do with this data, how, when, why, and why - the tenth thing. There is no need to edit templates, reorder requests, etc. Then the server part of the web-app will initially look like a set of interfaces for receiving data. We do not care what data the main page of the user and his personal account will consist of. If the user wants - he will write his ui.

And one more assumption that I really want to make: data and code should always be separate. And web is no exception.

If the roles are divided:
  • the server is NOT involved in direct or indirect UI generation
  • the server is engaged in data output
  • server authentication
  • the customer is engaged in rendering of content from the data itself
  • all troubles with shielding bad data fall on the client. And the client knows what needs to be screened, because he himself asked for the data
  • the server should only filter data that can damage only it. Everything else is the client’s task.


So:
  • html is not a suitable convenient tool for creating ui
  • the generation of a cast from data and views is unprofitable and not forced, to her throat with Occam's razor
  • the request-response model breaks asynchrony and binds both parties too much
  • the consequences of html in the form of validation of all data in general are disgusting: the browser does not know in advance what it will receive, therefore it cannot set the correct filters on the data. And so that he knows this, he himself must explicitly ask them


Almost any interesting site today is not just a page, but a host of interfaces and data processing methods. Why not separate the interface from the data right away? It turns out that any site today imposes its idea on me. And I really do not like it. I go to the site to get information, and not to look at pictures and new css3 lures (I do not argue that sometimes it is very beautiful, but beauty is distracting and ultimately the usability drops). It infuriates me that the search button I am looking for is a search on the page. It infuriates me that on all sites of the same destination, the buttons are located in different places. I want to see sites just like all desktop apps.

I don’t want to fuel a holivar, just think: how many unforced assumptions today's technologies contain. How many times have you asked yourself questions like: “Why am I here?” It is quite possible that if you do not take everything from the threshold as a given, one ideological regroup will put everything in its place.

Personally, I think that too much of the design effort settles on ui. It is there that the focus of crutches and redundancy. This is what first of all must be made convenient. And you can’t do with generators here: they themselves do not solve the problem, they only facilitate the stumbler.

I take this opportunity to congratulate everyone on the occasion and wish them creative success.

Also popular now: