I’ve been pretty excited about Meteor since I first saw a demo of it, but it can be a little daunting to get started, so I thought I’d create a simple tutorial that can get you running in about 30 minutes or less.
I’ve included a YouTube video along with this blog post to help you get up-to-speed quickly.
What is Meteor?
Before we get started we should talk about exactly what Meteor is.
Meteor basically provides all the plumbing for you to build a Single Page Application or SPA, without you having to wire everything up and worry about syncing data and updating templates.
What is a cloud IDE?
When I first heard of a cloud IDE, I didn’t really understand what it was–rather, I didn’t grasp how valuable a cloud IDE was. A cloud IDE will let you develop and run an application completely in the cloud with your browser.
This means that you can log into your IDE from any web browser and start developing your application.
For Meteor, this is really neat because you don’t have to install and run Meteor locally. You can utilize a Cloud IDE to run and develop a Meteor application completely on a Linux box in the cloud. You don’t even have to know much about Linux.
Now, I found that most of the Cloud IDEs out there were a bit sluggish when trying to run a Meteor application on them. I had almost given up, until I discovered that I could hook up the Cloud9 IDE with my own more powerful Linux virtual machine that is hosted at Digital Ocean.
This setup was so fast and impressive that it is completely worth setting up, so in this tutorial, that is where were are going to start.
Getting set up
The first thing you’ll need to do to get set up is to create a Digital Ocean account. Digital Ocean provides extremely cheap Linux virtual machines in the cloud. In fact, this website is hosted on a Digital Ocean machine that I pay $20 a month for (and it gets over 100k hits a month.)
Like I said before, you can just use the Cloud9 IDE by itself for running your Meteor app, but if you instead utilize a $10 / month Digital Ocean box, you’ll find everything to run about 3-to-4 times as fast–no joke.
The other alternative is to download and install Meteor on your own Linux box or Mac, but I like how easy it is to develop in the cloud–especially since you can do real-time collaboration with another developer.
If you want to use your own machine and don’t want to use a cloud IDE, just skip down to the section where we install Meteor and you can follow the same instructions, just on your own machine.
(By the way, the above link is an affiliate link–just wanted to let you know–so thanks if you sign up through it.)
Creating a Cloud9 account
Next, you’ll need to create a Cloud9 account. You can just sign up for the free account for now, but if you want more private workspaces, you’ll need to sign up for a paid account. I find the prices to be pretty reasonable though.
(By the way, the link for Cloud9 is not an affiliate link. They don’t have an affiliate program, but I still recommend them, because they are awesome–especially when hooked up to a Digital Ocean box.)
Connecting Cloud9 with Digital Ocean
The next step is to create a new Digital Ocean box that we are going to use SSH to connect to from the Cloud9 IDE. Don’t worry though, this is easier than it sounds.
Rather than repeating all the steps here, you can watch this excellent video that a Cloud9 developer put together that shows you exactly how to do it:
Now that we are all set up, we need to get Meteor installed. Fortunately, this is pretty easy. In fact, you can do it with a single command.
Just execute the following command at a terminal window:
curl https://install.meteor.com | /bin/sh
This command will pull down and execute a shell script which will install Meteor in your environment.
Yes, it really is that simple.
If you want to test out your Meteor install, execute the following command to create an example application that you can play around with:
meteor create –example leaderboard
This will create an example Meteor application called “Leaderboard.” Now, execute the following commands to switch to the Leaderboard project’s directory and start the application:
If all is well, you should see Meteor start a MongoDB instance as well as itself. You can connect to your Leaderboard app by going to the IP address of your machine and port 3000.
If you are using a Digital Ocean box, just use the same IP address you used when you set up the SSH connection to Cloud 9.
Go ahead and play around with the Leaderboard example app and take a look at the code. To really see the power of Meteor, you’ll want to open up two browser windows, each pointing at the app and see what happens when you make a change in one.
The Meteor tutorial app we are going to create
Ok, now we are ready to move on to creating our own Meteor application.
The application we are going to create is going to be a very simple TODO list application that we’ll call “Spartan TODO.”
The application will have a very simple UI and have the following basic features:
- Show a list of items to be done
- Add a new item to the list
- Click an item to toggle it to and from a “done” state
- Double click an item to delete a done item (I’ll leave this one for an exercise for you to do on your own.)
A pretty simple application, but it will take us through a pretty good cross-section of what Meteor can do. So, let’s get started.
Creating the project
The first thing we need to do is to create a new Meteor project.
In order to do that we just need to go back a directory from the Leaderboard project and create our TODO list app project. In order to do that execute the following commands:
meteor create spartan-todo
This will create a default “Hello World” project for us in Meteor that we can modify to create our own project. Let’s go ahead and start it up with:
Ok, so here is something pretty cool about Meteor: The whole time we are developing our application we can just leave it running. We can make changes to our application and–without having to recompile or restart the application–those changes will be applied live. We don’t even have to refresh the web browser. This is pretty cool.
Point your browser to the address of your machine and port 3000 to see the application.
Go ahead and try changing some text in the HTML to see it update live.
What’s in the Meteor tutorial project?
Before we move on, let’s take a quick moment to talk about what is in the Meteor project we created.
If you look in the spartan-todo directory, you should see 3 files:
- spartan-todo.css – the style sheet file for our entire application
- spartan-todo.html – the main HTML file that will be displayed
Meteor is pretty flexible in how you structure your project. The default app template is a very simple project structure, which we’ll stick with for this Meteor tutorial.
With this structure, you can expect the HTML file to be rendered using Meteor’s templating language, Spacebars (very similar to Handlebars.js) You can define any templates you want your application to use inside this HTML file, or you could create additional HTML files that this main HTML file references. The name of the file doesn’t matter, Meteor will just look for all the HTML files in your project and will actually create a single HTML document to be transferred to the client. But, for the purposes of this Meteor tutorial, you can ignore that. We are just going to use one HTML file.
We can use those functions to have code only run in the client or the server, if we need.
There is also a folder convention we can use that controls whether code runs on the client or server or both, but for now we’ll ignore that and keep everything in these three files.
You can find the exact details on how this works in the Structuring your application section in the official Meteor documentation.
Creating the user interface
Now that we have a running Meteor tutorial application, the first thing we are going to do is create a hard-coded version of the UI that we’ll be using in our application.
I always find it is best to start by just hard-coding all the HTML for a screen in an application, before going and adding real functionality. It makes things less confusing and you don’t waste time trying to change layouts and code at the same time.
Open up your spartan-todo.html file and replace its contents with the following code:
This will create our basic user interface for our application. If you switch to your browser, it should auto-update and you should see something that looks like this:
The next step will be to go from having a completely hard-coded HTML page to an HTML page that uses hard-coded Spacebars templates. In Meteor, we can define templates in our HTML files in order to break up and abstract away parts of our application as well as allow for our HTML to be generated based on data from our application. For now, we are going to keep things pretty simple. We are just going to break apart our HTML into a couple of templates. Replace the contents of your spartan-todo.html file with the following code:
When you go back to your browser, you shouldn’t see anything different, but now we are utilizing templates–just not very well.
Populating data with templates
The next step is to make it so the templates are actually being populated with data from our application. We are going to start off by hard-coding the data, in the application, but making it so the templates use that data to render the HTML.
Again, I like doing this baby-step approach–especially when starting out.
What we really want to do is make it so that the <li> elements we have in the HTML are not hard-coded, but are generated by some data that defines the items in our list.
We can do that in Meteor by utilizing the #each syntax in the Spacebars template.
Replace the content of your spartan-todo.html file with the following code:
What we’ve done here is replace the hard-coded list items with some templatized code that tells Meteor to loop through some collection of things called items and for each thing in that collection to write out a list item and a field from that item called “description.”
So, in order to get this template to work, we need to provide the template with a collection named “items” and the items in that collection need to have a field named “description” that has the description of the TODO list item we want.
Replace your spartan-todo.js file with the following code:
When Meteor renders the template, it will utilize the helper method to fill in the data the template needs.
After you’ve made this change and saved the file, your browser should automatically reload the changes, and you should see the new TODO list items we created.
Now, the data is still hard-coded, but it is coming from the actual application itself.
Populating data with collection
We still are hard-coding data and we have no way to add new items to our TODO list, but before we can fix that problem, we need to move the data down just one more layer and introduce an important concept in Meteor called “collections.”
Remember how I said Meteor uses a MongoDB as a document database for your application? Well, that is where we ideally would like to store our TODO list items.
In order to do that, we need to define a collection in our Meteor app, which we can use to populate our MongoDB and query it later to get TODO list items back out of it.
In Meteor, by default any collections we define on the server are also available on the client. What this means is that in your browser, you can actually interact with the application’s MongoDB instance as if you were writing server code.
Meteor does this by creating a MongoDB proxy on the client side that forwards data down to the server. This MongoDB proxy is also kept in sync with the server instance by default. So, that means any data that exists on the server, can be accessed directly from the browser. (This is the default behavior, which you’ll want to eventually turn off in your application and specify manually which data to sync, but for the purposes of this Meteor tutorial, we’ll take advantage of this.)
Replace the contents of your spartan-todo.js with the following code:
There are two things we did here. First, take a look at line 1. Here we declared a new Meteor collection called items. Since this code is outside of the client and server blocks, it will be run on both the client and the server. We don’t have to write the same code twice. This code will define a MongoDB collection we can use in our application. With a document database, like MongoDB, we don’t have to declare what fields are on the collection or anything else.
Next, take a look at lines 13 through 22. What we are doing here is populating some default data if the MongoDB collection is empty. This will just give us some seed-data to work with. We could leave this code out, but if we did we wouldn’t be able to tell if everything was working.
Finally, take a look at line 6. Here, we have updated our helper function for items to cal Find() on the Items collection to get its data instead of using the hard-coded values we had before. If you switch over to your browser, you should see the TODO list with the default items we added to the collection. Now that our application is being driven by real data in a database, we can add some actual real functionality to our Meteor application.
The first real bit of functionality we are going to implement will be to add new items to our list. In order to do this, we just need to add new items to our Items collection and Meteor will take care of the rest for us.
We’ll need to utilize template events to execute some code when someone clicks the add button to add a new item to our list. In Meteor, we can define events on a template, just like we can define helpers. You can really think of these as event handlers, since we’ll be writing code to handle different events that occur inside the template.
What we want to do is to define an event on the controls template that will be triggered when the form is submitting. This could happen when someone clicks add, or when they hit enter on the keyboard. In our event handling code, we’ll want to cancel the default action of submitting the form to the server, since we’ll handle everything in our client code.
Then, we’ll want to get the description of the item from our text input and insert a new item into our Items collection. Meteor will know that there is a change in our collection and will respond by rerendering the affected part of the DOM in the browser. Meteor templates are by default “reactive” in this way and constantly watch for changes that would affect the HTML they rendered.
Replace the contents of your spartan-todo.js file with the following code:
Take a look at lines 10 through 17.
What we are doing here is adding an event handler for the “submit form” event. Whenever the form is submitted on the page, this code will be executed.
In this code, we are first canceling the default action, which is to post the form to the server.
Them, we use some JQuery to grab the value of the newItem text input and store it in a variable.
Finally, we insert a new object into the Items collection with the proper description.
After you save this code, you can go ahead and try it out. Add a few items to the list. You can also try opening a second browser and watching how the data is synced between both clients.
Marking items done
The last step we want to do in this Meteor tutorial is to make it so that we can mark items as done by clicking on them and unmark them by clicking a second time.
Again, we will need to use events to do this.
The basic idea will be to create an event handler that will respond to a list item being clicked in the list template that will toggle a “done” field on the item to indicate whether or not the item should be marked as done.
We’ll use a CSS class that will apply a line-through to the list items marked as done.
Let’s start with the CSS class. Just add the following line to your spartan-todo.css file:
Next, replace the contents of your spartan-todo.js file with:
Let’s start by looking at lines 25 through 30.
What we’ve done here is created a new event handler for the list template that will trigger when a list item is clicked. This event handler will simply update the item in the Items collection by setting a “done” field on it to the opposite of what it was. This will result in the done field being set to true the first time it is clicked and from then on toggle between the two values.
How do specify which item we want to update?
Every object in our collection automatically gets a special field named “_id.” We can use this field to uniquely identify each item. But, how do we get a reference to the item?
You may have noticed the “this” keyword being used in this code. Whenever we are executing event handling code in a template, the this variable always points to the data that triggered the event. We automatically get the correct context, so when we refer to “this._id,” we get the ID of the object that represents the list item that was clicked on.
Notice also the special syntax we have to use to update an item and set a new field value in MongoDB. It might seem a little bit strange, but that is how it is done in MongoDB.
Next, take a look at lines 8 through 13.
Here we are defining a helper function called “doneClass” that will either return the string “done” or an empty string, depending on whether or not the item being evaluated when this helper is invoked in the template.
We can use this code to make it so the list template can assign our “done” class only to items that are marked as done.
In order to do this, simply replace line 15 in your spartan-todo.html file with the following code:
Save everything and open your browser and you’ll find that you can now click on items to mark them as done and click on them again to mark them as undone.
The template calls our helper function “doneClass” to determine what text to insert into our class statement on each li element.
Ok, now it’s your job to implement deleting items in our Meteor application.
I’ll give you a bit of a hint. You can utilize the “dblclick li” event to make it so that whenever someone double clicks a list item it is deleted. See if you can figure out how to implement that functionality in the Meteor app.
Meteor tutorial wrap up
So, there you have it: a very simple TODO list application in Meteor. I’ve actually created a screencast you can watch to follow along, if you’d like. You can find it below:
If you happen to be in the Copenhagen area or are planning on attending the At the Frontend conference on Nov 4th 2014, I’ll be there doing a “Getting Started With Meteor” session where I’ll be creating this TODO list application and going over a little more about Meteor.
If you found this tutorial helpful, please share it with anyone who you think might be interested.
Also, join over 5,000 other developers who are part of the Simple Programmer community by signing up here. You’ll get weekly emails with career tips, tutorials and other practical advice for software developers and special discounts on Simple Programmer products.
Some additional resources
And, I have created a Pluralsight course called “Meteor.js Fundamentals for Single Page Applications” that covers Meteor much more in-depth.
I don’t do many product reviews on this blog–and there is a good reason for it.
I get plenty of requests for companies asking me to “pimp” their stuff on this blog, but most of the stuff I am asked to write about I just don’t use or would never really find myself using.
However, I was pretty excited when Telerik contacted me and asked if I would be interested in letting them sponsor a post about their Devcraft developer tools, because I actually really like these tools–I’ve always been a big fan of Telerik–and the whole Devcraft package is something that I truly feel increases developer productivity.
So, yes, this is a sponsored post. Those of you who follow this blog know that this blog is one of my main income streams. But, as I am sure you can tell if you read this blog regularly, I hardly ever allow sponsored posts or guest posts, because the money is not worth trying to make up some crap about how some product I’ll never use is so great.
That that said, here is my honest opinion of Telerik’s Devcraft offering.
What is it?
I guess, before I can really get into what I think of Devcraft, I have to address what it is.
You can check it out for yourself here: Telerik Devcraft.
But, essentially it is a collection of almost all of Telerik’s .NET focus tools–all together. So, if you aren’t a .NET developer, you might not find all that much value–although, I have to say that the Kendo UI part (which is a jQuery-based framework with a bunch of responsive widgets and and other nice HTML components, including an MVVM framework) is great for any kind of web development.
Here is roughly how it is broken up:
There are a bunch of different UI controls for ASP.NET AJAX, ASP.NET MVC, Silverlight and even SharePoint. Plus, the Kendo UI framework that I already talked about. It is really a crazy amount of controls, and they look really good.
Again, tons of controls, and all of them look really great. I designed some custom controls for Windows Forms myself back in the day and these controls put everything I ever did to shame. They have controls for both WPF and the old Windows Forms.
As you might have guessed, the mobile side has Windows Phone 8, Windows 8 XAML and Windows 8 HTML controls. I would have liked some Android and iOS controls, but I guess you can’t have everything. I haven’t done a lot of Windows Phone or Windows 8 development myself, but I played around with some of the controls and I was really impressed. Again, polished top-notch controls that were really easy to get working.
Also, on the mobile side I found I could combine Kendo UI with PhoneGap to create some pretty nice mobile applications. (Although, I knew Telerik has their AppBuilder platform, which basically does this for you–it used to be called Icenium)
Telerik doesn’t just have UI controls, they have everything else as well. They have an NUnit-like testing framework–which is actually free.
But, they also have JustCode, which is a Visual Studio plugin that makes you more productive and adds all kinds of automatic refactorings to Visual Studio. (Think Resharper, but faster.)
And, I really like the JustMock tools that is part of Devcraft. I found this mocking engine very easy to use and I liked how it had the power to mock non-virtual methods, non-public members, sealed classes and even static methods. (Although, I’d suggest using that power with care.)
There were even tools on the debugging side. JustTrace turned out to be a very robust .NET memory and performance profiling tools–with a very nice and easy to use UI. I finally felt like I could actually us a profiling tool and understand what it was doing.
I’m also pretty well acquainted with JustDecompile. I’ve been using that .NET decompiler ever since that whole Redgate fiasco over .NET reflector. Telerik has done a pretty good job of making this decompiler easy to use.
I’ll also include the reporting and data access tool in this grouping–although I suppose you could argue that they aren’t really developer tools. Devcraft also has a reporting solution that is pretty lightweight and seems to be nice for generating reports and they also have a data access component that is basically a visual object-relational mapper. (The data access component is free.)
I’m not too much into reporting or data access these days, so I didn’t really use these parts very much–but they looked pretty nice to me.
So, what do I think?
Well, I have to say, many of the tools in Devcraft I was already using. I have been familiar with Telerik’s products for quite a while, but I never really had a chance to dig into many of their controls until now.
I was always very impressed with how the controls looked, but I now I am equally impressed with how easy they are to use and especially with the documentation available.
It was obvious that controls for desktop apps and ASP.NET AJAX would be fairly easy to use, but I am most impressed with how easy Telerik made it to use their ASP.NET MVC controls and the Kendo-UI bits.
Without knowing anything about how the ASP.NET MVC controls worked–and without reading any documentation ahead of time–I decided to just pick a few controls and see if I could get them working.
I found that for each control there was a live demo on Telerik’s site. I could simply go to the control, see how it worked, and see the source code below. This made using any control I wanted extremely easy. I didn’t have to memorize how to use each control, since I could just learn how to use a control when I needed to use it.
The big problem I have now is that I don’t see how I can go on using regular controls or trying to create my own UIs for ASP.NET MVC apps anymore. I know that sounds a little lame, but I am actually a bit worried. I have to figure how to convince clients I do work for that they need to invest in these controls, because I can’t see recreating some of this stuff, like I did before, now that I know it exists and how easy it is to use.
It’s also crazy how well all this stuff fits in together. The ASP.NET MVC controls are actually wrappers around the Kendo UI stuff, so you can actually utilize the same Kendo UI controls in your ASP.NET MVC applications very easily.
There also seems to be controls for just about everything you can imagine. I spent hours just looking through the controls and trying them out. I was getting great ideas for applications I could build, just from looking at the controls. I’m really excited now to use some of these controls on my next project.
All together though, the biggest thing for me about Devcraft was the productivity enhancements. I am all about developer productivity, so that is one of the main reasons why I like Devcraft.
I know what it is like to spend days trying to make a custom grid control or customize a grid control to do what I want. I know how much time can be wasted looking for that perfect jQuery plugin to use for your app. I think there is a huge value in having all of that in one big package.
It’s also pretty nice to not have to hunt for different solutions for testing, mocking, refactoring, tracing and more. Having everything together without me having to think about it, and knowing the quality is high, makes things much more simple and allows me to focus on what is really important.
So, overall I would have to say I am very impressed with Devcraft. I’ve been using bits and pieces of Telerik’s software here and there over the years, but until I did this review, I didn’t realize how well it all integrated together and just how much stuff there was available.
Now, the price is a bit high. At the time of this writing, there are three editions:
- The UI Edition at $1,299
- The Complete edition at $1,499
- The Ultimate edition at $1,999
But, with the value in these collections, I still think it is a pretty good bargain. I’ve purchases–or been responsible for the purchase–of many of the individual components in the past, and it seems like a no-brainer to me to get everything all together than trying to buy them piecemeal.
Also, Telerik has kindly offered to give away a license for Kendo UI Professional. To enter the contest, just leave a comment below. I’ll randomly select a winner in a week.
How to Create a Blog: Getting started
One of the biggest barriers that many developers have with creating a presence on the web is getting started. I’m going to try to make getting started as easy as possible, but not gloss over some of the important details that could hurt you later on when you grow.
In life, I have learned there is always a balance that needs to be achieved between doing things the best way and doing things in a way that is easy enough that you will actually do them.
So, I am going to present you with a few options for how you can get started with creating a blog and you can choose which path to follow based on what fits for you.
The first thing we should talk about is blogging software. What kind of software should you use for your blog?
There are quite a few options out there, including writing your own custom made blog, but I think the best option for most developers is to use WordPress.
I don’t say this lightly, and I realize that in the developer community WordPress might not seem like the best option, but let’s dissect this a little bit.
When you are creating a blog, most of the time your goal is not to show how good you are at creating a blog or using blogging software, but instead your goal is to get your message out, control your image, and build a home base for yourself on the web.
In business, we’d say that your blog software is not your core competency, instead the content you put on your blog is your core competency.
Many developers are tempted to start out by creating their own blog or use a less popular blogging software solution, and they end up wasting a huge amount of time messing with or creating software instead of blogging.
I choose WordPress, because it is the most popular and widely used blogging software, which means it is well supported, has tons of plugins and just works.
You can literally get a new WordPress install up in minutes, even from a bare server, and you can find plugins for just about anything you can think of.
Sure, I come from a .NET and C# background, and WordPress is PHP, but I can’t deny how easy it is to use and customize WordPress.
You can, of course, use another popular piece of software or write your own blog from scratch, but if you want to get up and running quickly, I’d recommend you just use WordPress for now and you can switch later if you want to, once you have a better idea of what you are doing.
Buying your lot
Your first goal should really be to create something that belongs to you and only you.
If you spend a large amount of time producing content for a blog and someone else is ultimately in control of that content, you are putting quite a bit at risk.
Just like you wouldn’t build your house on someone else’s lot of land, you shouldn’t build your blog on someone else’s domain.
So, the first thing you want to do is buy your lot. You are going to need your own domain that is owned by you.
Several free blogging platforms will gladly host your blog for you and give you an address within their domain. Even though this is free and the cheapest way to get started, you need to look a little bit deeper into the future and realize it is worth the $1.99 or whatever it costs to buy a domain for a year.
Whatever you do, don’t botch this one up, because you will regret it. Everything else can be changed later on, but moving domains and trying to keep your search rankings and all your content in place, is a pain that you don’t want to have.
You can register a domain pretty cheaply by using a service like GoDaddy. I usually use GoDaddy for initially registering my domains, even through I may move the registration later.
Choosing a hosting method
As long as you have your own domain, the choice here won’t be as important when you are first starting out, but it is still good to consider your options.
There are three main options to choose from for hosting your new blog.
Completely Free Hosting
This option is the cheapest and will allow you to get a blog up without having to do much management of any software or any operating systems, but it has the drawback of giving you the least amount of control over your blog.
I started out my blog with this option using WordPress.com, but you can also use a fee service like Blogger, from Google, or one of the other free blog hosting companies.
I originally started out with this option, because I didn’t want to make a big investment in something that I didn’t know if I would stick with. But, I later came to regret that decision, because of the lack of control over my blog.
With this option, you basically just register a new blog and can start posting immediately. The hosting company gives you access just to create and edit posts and a few management functions, but you don’t have access to more advanced options that you would get with your own install of WordPress or other blogging software.
This might not seem like a big deal, but if you eventually want to put ads on your site, sell something, or customize your theme, you may quickly regret this decision.
If you do go with this option though, make sure you pay the optional fee most of these services offer to allow you to use your own custom domain for your blog. Don’t make the mistake of skipping this. You do NOT want to change your domain later—trust me.
With this option, you are usually using some space on a web server that is shared with other blogs or websites, but you are in control of a large portion of that space.
Shared hosting companies usually will have some options to preinstall or automatically install WordPress or another blogging platform for you and give you access to that blogging software as if it were installed on your own machine.
You usually access your “server” through the use of a control panel application that gives you options to add and remove certain software applications, access your database and files directly, and do other administrative tasks that you can’t do with a free hosting platform.
Once I got off of free hosting on WordPress.com, because I wanted to be able to fully control my theme and add plugins to my blog, (something you can’t do with free hosting,) I switched to Bluehost.com, one of the most popular shared hosting platforms for WordPress. I was able to get everything migrated from WordPress.com to my WordPress install on Bluehost pretty easily, and my readers never even realized it.
This is actually the option I’d recommend for someone starting out, but I’ll get to why a little later on.
The other thing about this option is that it is pretty cheap as well. The prices can vary based on features, but you can expect to pay around $6 – $10 a month for a fully hosted setup when starting out. (In my opinion well worth it compared to the free hosting.)
I ended up moving off of shared hosting pretty quickly, because by the time I had moved from free hosting to shared hosting, my blog was a little too big already. I ended up having a little more traffic than the shared hosting could easily handle and I wanted to experiment with the 3rd option, which I’ll tell you about next.
I could have stayed on shared hosting, but my blog was getting frequent enough spikes from articles becoming popular on Hacker News that I decided to try and optimize things myself.
Virtual Private Server or VPS
This brings us to the 3rd category of hosting options, VPS or virtual private server hosting.
VPS hosting is pretty close to what it sounds like. A VPS is basically a virtualized private server in the cloud. Most VPS hosting solutions will give you the ability to create your own virtual server running Linux and configure it how you wish. You are basically given the keys to the car and you are on your way.
This of course can be a bit intimidating for starting out, but if you know what you are doing, or you are willing to learn (sometimes the hard way), this can be the most cost effective and efficient option to choose. But, you can definitely get yourself into trouble—I know I have.
With great power comes great responsibility!
This blog is currently hosted through a VPS provider called DigitalOcean, but there are several other VPS solutions out there as well. I found DigitalOcean to be the best priced option and it also seemed to have a very simple to use interface to create new virtual servers. I actually run several VPS’s for my different blogs and sites through DigitalOcean and I only pay for what I use, since DigitalOcean bills by the hour based on what kind of hardware configuration you are using for your server.
So, like I said, the big benefit of a VPS is that you have ultimate control of pretty much everything. You are just given a Linux server and the root password and you are on your own.
But, this can also be the big disadvantage with a VPS. You have to know or learn enough about Linux and installing your blogging software to be able to get up and running, and you’ve got to be able to troubleshoot your own problems.
For me, it is worth it because I get quite a bit of traffic to this blog, so my optimizations really make a difference, but for someone just starting out, I really wouldn’t recommend a VPS until you feel you’ve outgrown shared hosting.
My recommendation: shared hosting
If you are just starting out with your blog, I’d really recommend going with shared hosting with a company like Bluehost.
Going with free hosting is nice, really easy, and you can’t beat the price, but it comes at a cost of not really having control over your blog. I felt this pain pretty quickly with my blog, but I didn’t have enough knowledge to know what to do about it and to know what my other options were.
Free hosting really restricts what you can do and diminishes a large amount of the value of using something like WordPress for your blog. WordPress has a huge number of free plugins available that allow you to add many different features to your blog and really customize the appearance of it, as well as integrate with other software systems. For example, I use a WordPress plugin with my Get Up and CODE podcast to automatically publish my podcasts to iTunes when I publish a blog post of a new podcast episode.
Free hosting also tends to hide you from what is really going on with your blog. When I first moved from WordPress.com to shared hosting with a real WordPress install, I was a bit overwhelmed, because I had to try and figure out how to add the same functionality I had with my free hosting on my new shared hosting install. I had really wished at that time that I had just started out with shared hosting.
The other thing to consider is that you’ll probably eventually want to move off of free hosting when your blog grows, especially if you want to monetize it somehow, and even though migration is possible, it isn’t the easiest thing and it is a bit nerve wracking. I was very concerned that something would go wrong in transferring my blog over to shared hosting—that was not a very fun time in my life.
On the other end of the spectrum, is the VPS, which really is not something I’d recommend for starting out, because you won’t see any real benefit when your blog is small, but you’ll inherit quite a bit of headache. I’d still rather see you use a VPS than free hosting, but if you do go with a VPS, just know what you are getting into.
So, all things considered, my recommendation for starting out is definitely shared hosting. You get the benefit of a very low price to get started, good support, and the power to do what you want with your blog.
Bluehost is the shared hosting provider I’d recommend, simply because the price is really reasonable, the customer service was excellent, and I felt like the setup was extremely easy. I was able to sign up for an account and click a single button to install WordPress. (It appears that Bluehost actually has a VPS offering now as well, but I haven’t tried it yet.)
Hopefully this two part series has helped you realize why having a blog is so important to promoting yourself and advancing your career, and given you enough information to get started creating your own blog.
I’ve just talked about the basics here, but I’ll be posting more about marketing yourself and creating a blog in the future. Make sure you sign up for my newsletter, so you don’t miss any of these kinds of posts and I can let you know when I release a few products I am working on that cover more about marketing yourself and creating a blog than I can fit here.
And be sure to let me know what you think. If you use this information on how to create a blog to create your own blog, send me a link to it or leave a comment below.
I consider myself to be pretty open-minded, especially when it comes to technology, but in both of these cases, I was being a bit narrow-minded and I think it is important to be willing to admit when you are wrong.
Let me explain a bit further.
Onto responsive design
I actually had a very enlightening conversation with a gentleman on Twitter, who really helped me take a second look at responsive design and why it was more useful than I thought.
One of the biggest ways that he shifted my thinking about responsive design was by helping me to realize that it isn’t just PC, mobile phone, tablet, but that there were all kinds of forms factors and kinds of devices that a web page should look good and function well on today.
It also seems that right after I had written that article that I ended up having to use my phone for doing web based things much more than I had before then. I quickly became frustrated with websites that did not implement some kind of responsive design and found myself smiling when I happened upon a website that was mobile friendly and altered the UI to make it much easier to use on a phone.
When I thought about it more, it turned out that I was responding instinctively to the fad of responsive design, but not realizing the actual value that was there. I probably have a tendency to backlash hard against technology trends that seem to be fads or trendy. Sometimes, I do get a bit overzealous in doing so and don’t realize that even though many people are ignorantly worshipping some new technology or trend, there are many others who are wearing the latest techno-fashion, because it really is good and useful.
By the way, I found this book, to be a good resource for learning about responsive web design, if you are looking to get a bit more understanding of it.
I still don’t think it is healthy or smart to jump all into responsive design without a good reason for doing so or having a good understanding of the value it will bring. (Responsive design is not for everyone.) But, I do think responsive design is a good solution and should be implemented in many more cases than what I had originally thought. I can see a large amount of value in making an existing site responsive, because it can attract more business and make it easier for existing customers to give you money or use your product.
I even find myself wishing that my website was more responsive. This blog has a default mobile theme, but I am wondering how much mobile traffic I am losing out on, or how many opportunities to convert that traffic to customers to one of my products I am also missing out on, because I am not presenting the information on this blog in the best way I can for a smaller device.
A good lesson
It turns out being wrong about these two technologies was a good lesson for me, because it helped me realize that even though I like to think that I have eliminated most of my technology biases, there are still plenty that exist.
One of the key things that I’ve always said about this blog is that I am not going to stop from saying something because I am not 100% sure of what I am saying. What I mean by this is that I will give my view to the best of my knowledge, but that view is subject to revision. There really is no need to hold onto a viewpoint that is wrong, once you realize it is wrong and it is ok to be wrong sometimes. We all have to be willing to grow and learn along our journey. If we want to be able to improve, we have to be willing to allow ourselves to be wrong and to be ok with that.
There are so many posts that I have written for this blog that I wouldn’t agree with 100% today and that is because my knowledge and experience is changing. I really wouldn’t want it any other way. If I agree 100% with what I wrote about last year or the year before, I would be 100% the same person I was back then, so I wouldn’t be growing and improving. I’d rather be wrong sometimes and grow than think I am right all the time and stagnate.
My latest course was just released on Pluralsight:
If you haven’t seen Firefox OS yet, it is worth taking a look. I think this mobile operating system has a large amount of potential, because of its focus on HTML5 from the start. I was surprised how nice Firefox OS looks and feels and how easy it is to develop for using skills you already have.
Here is the official course description:
Firefox OS is a new exciting mobile operating system that has the goal of taking HTML 5 and making it a first class mobile citizen. In this course I’ll teach you the basics of Firefox OS and show you by example how to create two real Firefox OS applications as well as how to get those applications into the Firefox Marketplace.
In this course, we’ll start off by learning a little bit about Firefox OS and what makes it different. We’ll also talk about some of the benefits of a mobile operating system that uses web technologies you are already familiar with and take a quick look at the OS itself.
After that, we’ll create a very basic Hello World application as we go through the pretty simple process of installing the Firefox OS simulator and creating a very basic application to run inside it.
Once we have those basics down, we’ll go straight into creating our first application. First, I’ll show you how to create a hosted application which is an application that you can actually host on your own webserver, but is installed like any other mobile app on Firefox OS.
Then, we’ll create another full application, as we learn how to create a packaged application that is able to access more of the APIs that Firefox OS only exposed to apps that are actually installed on the device. We’ll still use the same HTML 5 technologies you are used to for this application, but we won’t need to host the app ourselves, because the user will install in directly on their device.
Finally, I’ll take you through the process of deploying your Firefox OS applications. We’ll talk about the different options you have for getting our application into users hands including distributing it yourself and using the Firefox Marketplace to host your apps.
Well I finally did it…
My latest Pluralsight course, Meteor.js Fundamentals for Single Page Applications, is my 50th course since I started this wild ride about 2 and a half years ago.
The technology is still in its infancy, but I think it has huge potential. Not very often I get this excited about a technology.
And here is the official course description:
Meteor is an exciting web development platform that has the potential to change the way you develop single page web applications.
Unfortunately, since Meteor is so new, there isn’t a large amount of information available to learn how to develop applications with it.
We’ll start off by learning about what Meteor is and learning about the technologies that Meteor uses.
Then, we’ll dig deep into Meteor to demystify the “magic” around it and discover how Meteor is able to do so much with so little code.
Then, we’ll actually create our first Meteor application and along the way we’ll cover some of the code concepts of Meteor needed to create a basic Meteor application.
Once we have the basics down, we’ll expand our application and discover some of the more advanced concepts of the platform that really allows us to utilize the power of Meteor.
Finally, we’ll go beyond Meteor as we learn how to deploy our application to both the Meteor servers and a Linux machine in the cloud and also discover how to use community created extensions to do things like add routing to our application.
“There is no such thing as a ‘self-made’ man. We are made up of thousands of others. Everyone who has ever done a kind deed for us, or spoken one word of encouragement to us, has entered into the make-up of our character and of our thoughts, as well as our success.”
- George Matthew Adams
One major lesson I have learned in my career and in life in general is that if you want to be successful, find others who are already being successful at doing what you want to do, and do what they do.
I thought I’d share in this post some of the web developers, (although I hate to classify anyone so narrowly), that I follow and that have inspired me or provided me with great resources or advice.
This guy just recently schooled me on responsive web design. Best part is he did it in a way that made me actually feel smarter and not like I was stupid. Hard to find someone so brilliant with so much tact.
If you want to know about responsive design, listen to Brad Frost. He is laying out the future of responsive design and blazing trails in every direction.
I haven’t ever had the chance to hear Brad speak myself, but I hear that he is an excellent speaker as well. I definitely plan to try to attend one of his sessions in the future.
Brad makes extremely compelling and convincing arguments about the things he believes in and it is really hard to argue with someone who checks all their facts and knows what they are talking about.
Brad has put together an excellent resource called This Is Responsive that contains lots of great information about responsive design.
Christian is the Principal Developer Evangelist of the Mozilla Developer Network. I have to tell you, I really like this guy. I’ve only had a couple of conversations with him on Twitter, but he seems to genuinely care about making the web a better place.
He is extremely well spoken and has an awesome German accent—oh, and he also knows what he is talking about. He’s written many articles and blogs posts for Ajaxain, Smashingmag, Yahoo, Mozilla, ScriptJunkie and others. And his Twitter stream is legendary. If you want to know what is going on in the web world, check out his stream.
Dan is a very experienced web developer that has kept up with the changing tides in web development. He is the founder and owner of The Wahlin Group where he provides consulting and training on web technologies.
Lately Dan has been producing a huge amount of great content about Angular.js, including his very popular AngularJS Magazine on Flipboard.
Glenn is another one of those developers who seems to have a contagious passion for development that you can’t help but catch. Glenn is always doing something cool that I want to learn about. He was involved in all kinds of cool things at Microsoft like Web API, Azure and MEF.
Glenn Block, until recently, had been a PM at Microsoft, working on—you’ll never guess it—that’s right, node.js. How cool is that? He was one of the main guys to bring node.js on Windows to Azure. I like how Glenn is able to combine these two separate worlds and make them make sense. I consider Glenn to be very pragmatic.
Glenn is now working for Splunk, and I am sure he’ll do amazing things there as well.
Oh, and I almost forgot. Glenn actually combined C# with node.js and birthed scriptcs, a way to write C# code without compiling. Pretty cool stuff.
John is an awesome developer and an awesome guy. He used to be a technical evangelist for Microsoft on Silverlight and much of his training and guidance was on using Silverlight.
But, after Silverlight… died, John found a way to reinvent himself and now is highly respected as an expert on SPA or Single Page Applications. He is an amazing and inspiring example of how a person can redirect their career and use their existing strengths and knowledge to go in a different direction when needed.
John also is one of the most talented technical speakers that I have ever heard. He speaks at conferences all over the world and even used to host the Silverlight TV show on Channel 9.
I’ve had the opportunity to meet John in person at the Orlando Code Camp and even interviewed him on an episode of my Get Up and CODE podcast, and I can tell you he is a genuinely nice and kind person as well.
I like Kelly because she is transparent and passionate about development. It is rare to find anyone who is so excited about technology and learning.
Both her blog and Twitter stream are constantly filled with valuable information. Some of the things she talks about and writes about make my brain hurt. For example, she wanted to learn about how to write very high performance code, so what did she do? Oh, just learned C and wrote her own HTTP server called Haywire.
Many developers are ok with surface level answers to questions, but not Kelly, she keeps digging and digging until she finds a real answer that makes sense. If you want to learn how to learn, follow Kelly. (Plus, you have to love the name of her domain.)
Paul has had a huge impact on the modern web and although his blog isn’t updated all that often lately, it contains a huge amount of in-depth information about browsers and browser technology. I turn to Paul when I want to understand the deep questions of the web.
What I like about Paul is that sheet volume of code that he has written. He doesn’t just talk about technologies, he makes technologies.
Rob figures out ways to simplify complex things, which of course is something I really like. He owns a consulting company called Blue Spire and he speaks at many events and writes articles regularly at devlicio.us.
I’m going to go out on a limb here and assume you’ve already heard of Scott Hanselman—it is hard to be involved in web development and not have heard of him.
Scott has this natural talent of cutting through the BS that is out there in the tech world and getting to the heart of the matter. He posts many things about the web and web development that other people are afraid to say or ask.
Scott also is the host of 3, that’s right, 3 podcasts. I’ve been listening to Hanselminutes for a long time and I’ve even had the honor of being on the show a few times.
He is also a very talented public speaker known for meticulously preparing every detail of his presentations and rehearsing them to a diamond-like polish.
One thing I really like about Scott is that he seems to reflect the interests of most software developers and technologists. His posts on all kinds of technical topics interesting to developers, not just web development and programming. Scott is diverse.
Troy is the person I trust more than anyone else to tell me what I need to know about security in today’s web world. Sure, everyone knows about SQL injection and salting passwords, but Troy’s knowledge goes far, far beyond that. Troy routinely finds big security vulnerabilities in production websites and posts about them.
If you are doing web development and you don’t want to get hacked, you better pay attention to what Troy says. His tweets and blog posts are like the bitter pill that you need to swallow if you want to live. Oh, and he is a pretty nice guy as well.
Also, a Pluralsight author with some excellent courses on security.
That’s my list, what is yours?
Obviously I can’t list every single influential person in web development that I rely on for advice and wisdom, but this is a pretty good list of some of the people I have found most helpful.
Getting good advice and mentorship is really important to advancing your career. I’m actually putting together a package of all my advice on career development that I have learned over the years, in a product that I’ll be launching sometime next year.
The project itself is still a bit secret, but sign up here if you are interested and I’ll be sure to let you know the moment it becomes available.
What about you? Who is your list of top resources for web development? Leave a comment and let me know. Also, if one of the developers I mentioned above has helped you, leave them some love in a comment.
We are in the middle of a period of rapid change in the software development world and I think the pace of change will only continue to speed up in the next few years. So, I thought it would be a good idea to post some software development predictions of what I think will happen in our software development world in the near future.
Mobile Software Development Prediction
Mobile is perhaps the biggest areas that everyone is curious about and it is really starting to seem that this space is ripe for an overhaul. None of the major players are innovating in this space at all.
Apple keeps releasing new versions of its mobile OS and new iPhones, but they aren’t really doing anything new or different. I also think moving to the flat design is going to turn out to be a bad move, because in doing so they took something that looked flashy and sophisticated and made it look extremely simple and plain.
On the Android side, there also isn’t much innovation. The OS itself seems pretty stagnant and the devices aren’t really adding any new exciting capabilities.
I think consumers and developers alike are getting a bit tired of the App Store / install apps model. It seems really burdensome and the more apps you get, the more updates you need to do and the more difficult it is to keep track of them all.
I think consumers are also finding that they don’t really like having so many devices to have to plug in, sync data with and carry around. I’m starting to feel the weight myself of having a fitbit, a phone, a tablet, a notebook, and a desktop. (Those are all links to the hardware I have, if you are curious.) I’d really like to have a single device that can adapt to a couple of different form factors and do everything I need.
My prediction is that we are going to start seeing the devices and OSes merge both on the Apple and Android side. I fully expect to start seeing devices from both Google and Apple that are tablet / notebooks which are similar to the Windows 8 notebooks we are seeing today. There is just no reason to have a tablet and a laptop when they can be easily combined into a single device with a detachable keyboard.
I am not sure this will happen, but I’d actually like to see it taken one step further and see the idea Ubuntu Mobile is pioneering take over. With Ubuntu Mobile, the idea is that your phone has enough processing power to be your laptop or desktop computer, so you can just carry around your phone and plug it into a monitor and keyboard. The actual OS adapts to the form factor depending on whether it is plugged in or not.
I’d actually like to see things go one step further than that (and I imagine they eventually will), and see a “computer” reduced to a very small block that you carry around with you which is able to display itself on any display technology that is around and utilize any external devices. I imagine, the phone form factor would still be the best way to use this device for now, since you probably want to have a portable display anyway, but I’d like to just be able to pull out this device and tell it that I want the output to go to my TV or my monitor and for it to remember that it should utilize my keyboard and mouse for that profile. At that point, I might have a tablet device as well, but it would only be a dumb screen that receives a display signal wirelessly from my phone.
I am getting a little bit far into the future though. But, I think realistically next year we should see a merging of OSes from both Google and Apple and I would really expect Google to take the lead here, because I can’t think of one single competitive advantage that Apple has retained at this point. There is no “magic” anymore with Apple products, the fairytale is over.
Web Software Development Predictions
I don’t know if Meteor itself will become very popular, but the ideas within the platform are very likely to spill over to the rest of the web and become the defacto way of doing things.
Meteor also gets rid of REST and replaces it with data synchronization that just seems to magically work. This is extremely powerful, because I am finding there is a huge waste of time involved in creating and consuming REST services ultimately to just sync data between two systems.
Right now the browser is an OS, but I think within the next year or so, we’ll see the PAGE or tab become the OS. And that is essentially what technologies like Meteor are doing. They are deploying their infrastructure code to the first page load and then running the app in their own environment on a tab in your browser.
I think we’ll see a much bigger adoption of Google’s Go language, because it seems to be a very good general purpose language that has many of the performance characteristics and power of C and C++, but has the ease of use and leverage of Java and C#.
We’ve sort of reached the place in the C# and Java space where just about everyone is doing “cargo cult programming.” What I mean by this is that a majority of developers are writing unit tests and using IoC containers without understanding what value those practices bring or even if those practices are actually bringing any value.
This complexity and confusion is preventing many new developers from learning C# and Java and it is starting to seem that Python is now the standard beginners language.
I expect that we’ll see a rise in both Python and Go. Google has the potential to greatly increase the popularity of either of these languages if they decide to move Android / Chrome’s primary language from Java to either Go and Python. (My bet would be on Go.)
We are overdue for a new statically typed language that incorporates all the things we’ve learned about in the past decade from Java and C#, but I don’t see that language on the horizon, so I am wondering if statically typed languages will eventually fade away. The increase in tooling and support for dynamic languages has for the first time in history made this a possibility and I am actually starting to wonder if I might be ready to turn over to the dynamic side after all these years of being a staunch defender of statically typed languages. (To be honest, the lines between what is statically types or strongly typed and not is blurring anyway.)
Only time will tell
Well, those are my software development predictions, and to some degree my hopes, but I’m not very confident in many of them at this point. The only one I’d bet on is that both Google and Apple merge their mobile and desktop OSes and develop ways to build web / native hybrid apps. That is the only direction that makes sense to me.
What do you think? How far off am I? What have I left out?
Really excited about this course. I’m a little late to publish this post. But, last week my Pluralsight course on creating a Chrome extension was published.
Here is the course description:
In this course, I’ll show you the basics of creating Chrome extensions as we create 3 different Chrome extensions. We’ll start off the course learning a little bit about the basics of Chrome extensions and how extensions work in Chrome and then we’ll dive right in and start creating our first extension.
Once we have the basics down, we’ll build a more powerful extension that has its own user interface and options page and is able to save data using the Chrome APIs and add its own entry to the right click menu for Chrome.
We’ll actually have our extension modify the Pluralsight website course listing page to make the course listing table sortable—so, you won’t want to miss this.
Finally, we’ll wrap up our tour of Chrome extensions by learning how to debug extensions as well as deploy them.
So, if you are interested in Chrome extensions, but have always thought it might be too difficult to create one for yourself, you definitely need to check out this course. Trust me, it is much easier than you probably think and this course will show you how to do it.
(Update: My view is starting to change from when I first wrote this article. Thanks to numerous people who have pointed out many things I overlooked and have helped me to understand what responsive design really is and what goals it is trying to achieve, I am getting a better understanding of why it may indeed not be a waste of time. There are still some valid points that I brought up in this article, but I don’t stand by my original blanket statement that it is a waste of time. It especially seems like responsive design may be worth the “trouble” for ecommerce sites where you are more much likely to make the sale if someone can easily purchase and browser your products from a mobile device. Thanks everyone who has been giving me great advice and resources for better understanding responsive design and for mostly doing it in a “nice” way.)
Response design seems like a good idea.
At first look, it makes sense. Why wouldn’t you want your same website to scale down to a mobile device and display differently?
For example, there are many WordPress themes now that offer responsive design baked right in. If you are using one of those themes, you might as well take advantage of the hard work someone else has put into making the design responsive.
But, if you are creating a new website or you are considering converting your existing website to a responsive design, I’d suggest you think twice before making the plunge.
The extra work of responsive design
The biggest problem with responsive design is the extra work involved. Sure, there are frameworks and tools to make responsive design easier, but no matter how good those frameworks and tools get, to make a site adapt from the desktop to a mobile device, it is still going to require significant work.
If you have a really simple site with just a few pages or pages that pretty much all use the same layout, but just differ in content (like a blog for example,) then the work might not be that much, so go ahead, make it responsive.
But, if you have a website of any considerable size, you’ll probably find that responsive design is going to add a non-trivial amount of extra work to your project.
It actually turns out the adding responsive design to a web site can add more work than creating a separate desktop and mobile site, because you are creating a user interface that morphs or adapts to the mobile form factor–which, by the way, is ever-changing.
The problem with one-size-fits-all
Consider this. Which is more difficult to create: a car that turns into a motorcycle, or a car and a motorcycle?
Here is another one. Which is more difficult to create: a multi-function printer or a printer and a scanner?
When you try to make a product that can do multiple things, the complexity of creating that product increases exponentially. It is almost always easier to create two separate products that do two different functions or have different form factors, than it is to create an all-in-one product that is able to do many things.
Besides the increased difficulty, trying to create products that do more than one thing usually results in them not doing either function that great.
I’m not saying you can’t design a great responsive website that serves desktop clients and mobile clients wonderfully and makes their eyes light up with joy every time they see your beautiful site. I’m just saying you won’t.
I’d also rather not be handcuffed to my original design because changing anything will incur the cost of making changes to the reactive layout as well, that scales down to mobile.
The reuse fallacy
What are you really trying to do by creating a reactive design, instead of just creating a desktop version and mobile version of the site? Reuse some HTML and CSS?
When you think about it, it doesn’t make much sense. I’m all for code reuse, but responsive design is like putting ifdefs all over your code base. Are you really saving much time and effort by reusing your front end code for both platforms?
It seems to me, that if you have to have your site display differently on a mobile device you are better off just forgetting about trying to reuse the HTML markup and CSS, and instead focus on reusing the backend code for both the mobile and desktop versions of your site; that is where you’ll actually get the biggest bang for your buck.
Again, I don’t know about you, but I’d much rather maintain two front end codebases that are simple than one monstrous complicated front end codebase.
It is good enough already?
Most desktop websites actually look fine on a mobile device without any reactive design. To me it makes much more sense, in most cases, to focus on just creating a desktop design that looks good on mobile or even a mobile design the looks good on the desktop as well.
Sure, responsive design is pretty cool, but do you really need it?
It is the browser’s responsibility anyway
Aside from the practical reasons I’ve talked about so far, there is another major reason why responsive design might just be a waste of time anyway: this should all be the browser’s responsibility, not the web developer’s.
This is even already starting to take place. Consider the special input types in HTML5, like the number input type. On a mobile device it brings up the numerical keyboard in mobile browsers.
I predict as more and more websites are viewed from mobile devices, the types of things that web designers are doing to make desktop sites responsive right now will be incorporated directly into the HTML markup and the browser itself. So, creating a responsive design manually might end up being a big waste of time.
I’ll leave you with one final point, then I’ll get off my responsive design soapbox.
We are in a time of constant flux right now
Things are changing rapidly. Mobile devices are getting bigger screens and higher resolutions and becoming much more powerful. While two years ago it was a pain to visit a desktop site from a mobile browser, it is much less painful now. With my new Galaxy S4, I hardly feel the difference at all and I even find myself specifically requesting the desktop version of a mobile site from time to time.
The trend says that mobile browsing will eventually take over desktop browsing as the main source of visitors to websites. If this becomes reality—which I see no reason to doubt—responsive design won’t make much sense at all. In that case, it will make much more sense to build websites optimized for mobile and not really worry so much about desktop.
If you are going to do responsive design, at least get a good book on the subject. There are many subpar books floating around, because responsive design is so hot right now.
What do you think? Am I off my rocker? If you have a convincing argument as to why responsive design is worth the effort or why it isn’t as much extra effort as I have painted it to be, I’d love to hear it. Let me know in the comments below.