And it also seems that as soon as a new framework is being published, all others become garbage. Frameworks fight against each other, they disagree on everything except on how your backend should be. They believe that backends should just serve JSON.
Backend are just dumb entity and the client side scripting is where all the magic happens.
When I read posts about new frameworks, it always seems like the frontend folks look down on their backend peer as their retarded siblings. Not clever enough to help out with the frontend.
Don’t try to help me do my job. Give me the JSON and I’ll take it from there.
Looking objectively at the code however, there’s a clear pattern. The client side tries to do everything by itself. Validations, model relationships, security, etc. While the feeling is that the backend is a limited kid, the reality is quite the opposite. The backend is more like a father watching his son’s every move to make sure he’s not making any mistake. The client can validate the user’s input as much as it wants, but you can be certain that the server will recheck the values.
Backends are very capable beasts. Demeaning them to simple JSON interface is absurd. If I take Rails, for example, it has HTML helpers to help you build forms, it has protections against XSS that are built right into your HTML templates, it handles different MIME types according either the URL or the Accept header.
All those things are thrown out the window when you deal with JSON.
What we should aim for is JS framework designed with the pros and cons of the underlying framework the project uses.
Let’s not kid ourselves: there are pros and cons with every framework. And thinking that JSON is a way to nullify everything that happens on the backend is ludicrous. I’ve said it before, HTML is a much richer data format than JSON. It carries context through the choice of HTML element, the element rendered, the class and id associated with those elements. An HTML snippet is built around decisions that were made on the backend.
The future, the status quo?
Hell no. I just think that the future won’t revolve around JSON. I think it will revolve around HTML snippet. I think full page reload is just as wasteful as JSON response. Because there’s already techniques we’re using that could fit right in the middle. And I think the missing piece appeared just recently: Virtual Dom.
Yes, you read this right. I think Virtual DOM is part of the future. It’s a great idea that browser should embrace. I think the Virtual DOM should make it into the Web Standard.
Using Virtual DOM, it would be possible to build something that leverages the power of the backend and the flexibility of the frontend while keeping the updates as fast & smooth as possible. Let’s take an example where you want to update a list with its pagination when a user changes a page.
<ol class='posts'> <li id='post-1'><a href='posts/1'>A title</a></li> <li id='post-2'><a href='posts/2'>A title #2</a></li> <ol> <div class='pagination'> <span class='current'>1</span> <span>2</span> </div>
Here’s what happens when a user clicks on a new page.
<ol class='posts'> <li id='post-4'><a href='/posts/4'>Title #4</a></li> </ol> <div class='pagination'> <span>1</span> <span class='current'>2</span> </div>
ol = document.querySelector('ol.posts') batchUpdate(ol, response.HTML) pagination = document.querySelector('div.pagination') batchUpdate(pagination, response.paginationHTML)
The DOM would then be updated using VirtualDOM so only new elements are created when necessary and the old one would be recycled.
With this contrived example, there’s a few things that can be interpreted.
- Pagination ordered, which was necessary to check on the backend, is preserved in the response;
- HTML snippet includes the links and the ids at the right place, without extra calculation on the frontend;
- Corner case like end of pagination are covered in a single place;
- If the page is out of bound, the error is produced once and the frontend code just renders it.
No need for data-binding. No need for convoluted MVC code.