Modern Client-Side Times
Reinout wrote a blog post about the client side and what it means for server-side web development. Lots of it is very interesting to me, so I'm going to give some feedback here.
(By the way, I prefer the term "web service" to API, but the difference is at best subtle. A web service promises some discoverability (using, say, hyperlinks) that an API perhaps does not. A RESTful web service leads to resource-oriented modeling, which is subtly different from traditional OOP API design.)
Since I've been doing a lot of work on client-side single-page user interfaces that talk to RESTful (or web socket) backends in recent years, I figure I'd comment. I've been working on and with Obviel, and I've mostly worked with Grok-based RESTful + JSON backends.
The new way obsoletes the old?
So, back to Reinout's question: is the new paradigm going to obsolete the old? Does the rich client-side user interface approach obsolete server-side web frameworks?
Reinout disagrees, and I do too. There is a huge area where server-side rendered HTML is the way to go. Not all web sites are single-page web applications, nor should they be. Not all rich web applications are single-page either.
I do find rich client side web applications a very interesting part of web development. I think much innovation takes place here. I am attracted to areas of innovation as I like being creative. I think the client-side paradigm can, when used well, lead to improved application design, with better separation between UI and backend code.
I'll also note that the old way informs the new: I've found it extremely useful to think about Obviel as a web framework and think about what server-side web frameworks do and what this might look like in the client. Your knowledge of server side web development is not obsoleted even if you develop in the client-side paradigm.
What goes and what stays?
With a single-page rich client application, the server-side web framework has to do less. What tends to go away from the server side?
server-side templates (templates are now client-side).
form generation (at least with Obviel; though form-definition generation is still there)
sessions (a single-page web app doesn't need a session; it can store whatever it likes between requests to the backend service)
What remains is still significant, however:
serving up JSON on URLs with hyperlinks to other URLs
processing POSTs of JSON content (this may include parts of form validation)
traversal or routing to content
integrating with a database (SQLAlchemy in this case)
authentication - who are you?
authorization - who can access this URL?
serve up an initial web page pulling in a whole bunch of static resources (JS, CSS)
The client web framework (such as Obviel) gains some features that are traditionally done on the server-side:
form generation and part of validation
routing (though this is in addition to any routing done by the server - it's to allow URLs for different aspects of a single page application)
i18n (if your client side web framework can do it)
Saying that the server side becomes "just an API" is an overstatement, I think. Much of what was useful to a server side web framework is still useful. The main thing that changes is that what goes over the wire from server to client isn't rendered HTML anymore. This is a major change that affects everything, but much does stay the same nonetheless.
Random extra points
Reinout makes a few assorted extra points, and I'll respond to some:
I try to design web services where the web service in itself makes sense, independent of user interface. I haven't gotten this 100% right yet, but I do notice that I can develop the back-end and the client-side rather independently from each other. I don't find myself switching from client-side to server-side and back again the whole time when developing a new feature or fixing a bug; usually the problem is isolated in one place or another.
Ideally, the web service isn't the servant of one UI; doing so will create a service that is purely ad-hoc and doesn't expose clean resources. The web service should be designed in a clean way independent of particular UIs. In the real world of course there are compromises, but if you just go into this direction a little the UI will be brought down from its kingship and become a proper citizen.
(Obviel still needs a kick-ass localization system for things like dates and such - want to help?)
I'm not entirely sure what this is about. Server-side web development doesn't go away, and you can do whatever you want with data sources and customization there. The main difference I see is that when you need to display the results in a UI, you don't use a server-side template but serve up JSON and use client-side templates instead. I'd also say the concept of a data source can become more explicit if it's also served up under a URL.
Perhaps this is therefore also about user interface customization. The way this is done would have to move, at least in part, from the server to the client, but that is certainly possible (Obviel offers one way to do that, and you can drive UI construction from the server).
"Repeatability, rebuildability, customizability."
It's not as good as the Python world, I think.
For Python projects we created a static resource packaging solution called Fanstatic, by the way. But it's one way of many.
Server-side web applications aren't going to go away. Server-side concepts often apply to the client side. These things will exist in parallel. So: you are not obsolete.
Client-side web development is trendy, and trends tend to bring in hype, and hype is overstated. Let's not throw away our server-side wisdom just because new ways of doing things have emerged.
Solid, client-side development can be done, but it's not as mature as with Python. A corollary to that: there is a lot of creativity on the client side, and that is fun!
And a plug for Obviel: Obviel is a client-side web framework that you can adopt incrementally, and it's informed by server-side concepts.
CommentsComments powered by Disqus