devboxWhat is Web Development?
Web development is a broad term for the work involved in developing a web site for the Internet (World Wide Web) or an intranet (a private network). Web development is the coding or programming that enables website functionality, per the owner’s requirements. It mainly deals with the non-design aspect of building websites, which includes coding and writing markup. Web development ranges from creating plain text pages to complex Web-based applications, social network applications and electronic business applications.
The Web development hierarchy is as follows:
- Client-side coding
- Server-side coding
- Database technology
Why Web Development is so important?
Once you have your website designed, it’s unlikely you’ll need to make too many changes to its design, but just because the main site is complete, it doesn’t mean your overall web development stops. It’s important to keep your site updated with fresh and interesting content, for instance. This is not only good for SEO but also helps to engage the people who read your site. You might also need to make alterations to your site when you launch new products or services. On a more dramatic scale, if you decide to brand your business, your website is likely to need rebranding.
What is Web Development Future?
The future of Web development isn’t MVC, its MVM. When Ruby on Rails hit the Web development world in 2005, it changed everything practically overnight by bringing a pattern rooted in Smalltalk to the Web. I’ve been playing with the recently-released Meteor Web framework and I think that’s an important and equally momentous shift is taking place in the Web world.
It started with Node. js:
More recently, Node.js changed everything again with the idea that the Web could evolve beyond the model where every request / response pair was fully cached on the server before processing was complete. Unfortunately for all of the interesting new possibilities that Node offered it was pretty low-level if you were coming from a mature Web framework.
Node allowed you to write Web services that were difficult or impossible to write previously. Streaming services that made long-running connections and broadcast-style chat apps became trivial to write instead of requiring lots of tweaking and custom server configurations.
However the power that made writing the average chat application easy made doing a Rails-style application tedious. Frameworks like Express came on the scene, letting you develop with a more Sinatra-style API, making doing Restful applications fairly easily. However, I don’t think using an Express on its own really harnessed the power of what Node was capable of. Sure, if you needed some server-push goodness it was trivial to drop in Socket.IO, but then you could have used a hybrid solution, using Node for just the server push parts.
Classic MVC on Node:
Those of us interested in building data driven single-page applications noticed that we were building complex object models in JavaScript on the client. The classic MVC pattern just didn’t map well to doing this. Libraries like Backbone.js became a popular way of creating a client-side JavaScript collection that mapped to a Restful API on the server, creating a MVVM-style (Model-View-View model) development model. At this stage the more observant of us might have noticed that if we were using Node.js on the server, we had the same language running everywhere and were doing a lot of work on the client just to model what we already had on the server in the same language with two impedance mismatches along the way. Let me explain what I mean about impedance mismatches. When we write a data-centric application, we start with some data. That data is going to be stored somehow, probably in a document storage or relational database. On the server, we have some query language for retrieving what we want.
Why Meteor (framework) is a game-changer?
When I first looked at Meteor I was trying to figure out where the server-side controller code was running on one of the sample projects. When I looked at the server code I was surprised that there wasn’t really anything there except a pair of MongoDB collection definitions. Meteor provides an ORM layer that loosely mirrors the Mongo query API. The thing is, this full API is available directly on the client. When we want to query our data store, we can do it transparently from the client-side data models. So, I’m thinking of what Meteor does as MVM (Model-View-Mapper). There is still a model in my mind, which is essentially a view model since they are created largely to support the bound views. I’m thinking what would have been the controller in an MVC model has actually been replaced by some ORM code that supports what the views need to display the data.
