A lot of things are changing with the advent of HTML5 + the rise of iOS/Android.
We are going to have to throw out a lot of how we make service oriented Apps.
This stuff isn’t going to be done overnight, but the kind of web frameworks that exist now and new web frameworks and languages going forward are going to need to adapt to a new dynamic of smart clients like HTML5 browsers and iOS/Android Apps.
The next steps for service architectures remove HTML/CSS/JS from the equation. Apps will consist of: data store access, business logic, and static file + JSON service endpoints, with separate client code driving interaction and interfacing with the service endpoints. Notice what’s missing? No more “page” classes. Client agnosticism is coming, and it will make service development a bit more abstract but a lot more fun to do in the long term.
No More HTML Munging
The curse of web development is working with an ugly mess of strings that is HTML. Why do we put up with this? No one really wants to work with putting HTML together, it’s long been just a necessary evil. Template frameworks help but also add complexity and present annoying walls to rapid development.
So celebrate, this is going away, it will be the client’s problem to deal with the interface! Yes HTML will still exist, but JQuery is now a great solution for putting pages together from scratch, you get more dynamic interfaces and importantly interfaces that are clearly separate from server code.
Before, a big reason to do server-side HTML munging was SEO. (Thanks Chris for rescuing that article from my old blog). Today, Facebook and Twitter both use what will likely grow more and more common: Google’s #! syntax. Many apps don’t even need SEO, and Google themselves have moved to JS driven clients.
Now that we have HTML5, killer fast JS engines and and rich plugin resources like JQuery’s, putting all web pages together on the client transforms from a Quixotic time sink into the smart design decision.
Finally: HTML browsers are now just another client for backend services, iOS/Android apps are a major way to consume services - the most cost effective and maintainable solution will move to a common API layer for all clients.
Developing based on cookies is not a good model for server development. Cookies are a terrible model for maintaining state between the server and client. They add latency, they are extremely limited and a hassle to work with, and are the source of a litany of exploits.
Cookies are going to be less and less relevant. localStorage APIs obliterate the space limitations of cookies. Request header manipulation + cross domain request standards provide security + flexibility as well as natural speed improvements by eliminating the cookies model of sending state variables back and forth with every single request.
Service Oriented Frameworks
I’m through with web frameworks. What’s the point of a web framework when I do my HTML generation on the client, or iOS/Android apps use my service?
That’s a huge reason I’m through with PHP. PHP was a language built from the ground up for web development. It was a great tool for HTML munging, for rapid development, and for scaling to large numbers of page requests. PHP is not fundamentally a good language however, and now that the HTML munging and page request models are fading, it’s time for something else.
Node.js is right now at a great position for leading a new model of service oriented development. There’s no framework yet to make this stuff easy or idiot proof, but the fundamentals of Node are all right on target to drive the next generation of web and smartphone apps.
I’m only about 50% of the way to converting all my code to Node.js, there’s no question to me that it’s still immature but there is also no question that it has huge strengths for developing next-gen services and it’s well designed + fun and deserves the growing momentum it’s getting.