Node.Js vs. Rails: How to Learn Web Development the Smart Way

And The Number 1 Mistake Beginners Make When Choosing A Web Development Stack

If your goal is to become a Full Stack Developer you need to decide which programming language you’re going to learn. And if you’ve researched different web development technologies, you probably came across Ruby on Rails, NodeJS, AngularJS, JavaScript and perhaps even the “MEAN” stack (MongoDB, ExpressJS, AngularJS and NodeJS). The appeal of the MEAN stack to beginners is quite obvious since it implies that all you need to learn is JavaScript – a single programming language – and you’re ready to conquer the world of Full Stack Development.

In fact, I frequently get asked questions like this:

If all I need to learn is JavaScript, and I use the technologies: MongoDB, ExpressJS, AngularJS, and NodeJS, won’t web development be 4 times as easy for me? Doesn’t that mean all things considered, if I work as hard as someone who doesn’t use this stack I would be four times as good?

Although it sounds intuitive that becoming a full-stack JavaScript developer is an order of magnitude easier to learn, it’s incorrect! Here’s why.

Thinking that learning JavaScript is the fast track to becoming a full-stack developer is based in the incorrect assumption that learning programming language syntax is the hardest part of becoming a full-stack developer.

You should know that the hardest part of becoming a programmer is not learning the domain specific knowledge of a single programming language, but instead learning how to figure out the things that you don’t know. It’s the procedural knowledge about how to teach yourself foreign concepts that is the hardest part to master when becoming a full-stack web developer

This means even though there will overlap of a small percentage of the domain specific knowledge, this will make your coding skill progression a negligible amount easier in the grand scheme of things.

If you’re thinking about making the correct long-term decision that will produce the least amount of friction, and ultimately give you the highest chance of success, you should be asking a different question altogether. The right question to ask is:

What is the right tool for the job?

This means when you evaluate technologies you should evaluate different technologies based on merits of the technology – not the hype, “number of Google Searches” or a number of irrelevant details.

Let’s think about a practical problem you could potentially face outside the coding world. The analogy holds true in the coding world as well.

Problem: You Need to Build A Bookshelf

Potential Solution #1

First, we could use a wide variety of different tools. We could use a saw to cut the wood, nails to connect the pieces of wood, a hammer to drive the nails through the wood, wood-glue in some places that aren’t appropriate for nails. A drill could come in handy to, depending on the blueprints we’re using.

Potential Solution #2

Or, we could just use a hammer. Instead of cutting the wood with a saw, we could use the opposite side of the hammer to split the pieces of wood into smaller pieces. We could connect the pieces of wood with nails we drive into the wood with the hammer. We could avoid using blueprints, because those would just be another thing we’d have to learn about how to use.
Now, let’s return to our argument in this case:

If all I need to learn is how to use a single tool like a hammer won’t building bookshelves be 4 times as easy for me as someone who uses a hammer, a saw and glue, and blueprints? Doesn’t that mean all things considered, if I work as hard as someone who uses all the other tools combined I can produce 4 times the amount of bookshelves.

This argument is obviously completely ludicrous. Figuring out how to cut wood with a hammer is probably possible, but why would you want to do it, given there are better tools out there? That’s why the argument of learning to be a full-stack JavaScript developer for the sole reason of it being easier to learn 1 thing than 4 things is completely wrong.

NodeJS, ExpressJS, AngularJS and MongoDB are all excellent tools at solving some problems, but in many cases there are different specific tools that will work better in a wider range of cases. You should always try to understand which problem a specific technology and available alternatives solve before you choose a tool to complete the job.

As someone starting out, determining the right tool for the job can be a difficult task. In order to understand the right tool for the job you’ll need to understand the problems at hand. To understand the problems that each tool solves, you’ll need to understand a variety of moving pieces and how web applications are built at a high level.

Without knowing anything about how web applications are built, we’re likely to believe anything that we read about the “latest programming language” hype that anyone tells us.

This post will teach you exactly how to evaluate different technologies when learning to become a web developer.

First, we’ll cover the difference between front-end and back-end, what a web application is, how databases work and what our server does.

Then, with the context we need to understand the problems that the specific technologies solve for us, we will discuss the benefits and drawbacks of different technologies.

Finally, you’ll be properly informed and able to make the decision answering the most important question:

Node.Js vs Rails. Which is the best tool to help me achieve my specific goals?
Let’s go!

Full 360 Degree View of Modern Web Applications.

There are a number of different aspects of modern web applications that all full-stack developers need to learn. But first, what is a web application?

Web Applications

A web application is a program that generates a dynamic (i.e. constantly changing) webpages for each web request that comes in. They often will have forms that will accept user input. If you want to do any of the following you’ll need to build a web application:

Allow users to login to an account
Display user generated data on a page (think: custom uploaded photos, comments, tweets, etc.)
Have different users interact with the same data

Examples of web applications are: Facebook, Twitter, Instagram, Pinterest, and Yelp.

Databases

Databases store the information that powers our application. Our web application will connect to our database in the access data. There are many different types of databases, and ways to store user entered data.

Front-end

The front-end of our web application is very close to the things that users see. Front-end code is usually very visual oriented and changing the code at this level will impact what users see.

Back-end

Back-end code is the glue that allows us to take abstract things like a user asking for a specific page on the internet, connecting to a database, and spitting things out in a format that is visually processable (front-end). In most cases it’s where the most complex logic lives.

Full-stack developers are expected to understand each of these layers. Each layer also has a variety of different technologies that can be used.

Now, let’s do a deep-dive on each of the layers, talk about the problems they need to solve, and the different solutions (technologies) that are out there. When we fully understand the problems, making a decision about the correct tool for the job.

Front-End Code

Web browsers (like Google Chrome, Internet Explorer, Safari, etc.) understand 3 different coding languages. Front-end code encompasses all the languages that browsers understand.

HTML is the building block of what the internet is built up of. In short, HTML is a way to code up documents in ways that web browsers understand. Every single website on the Internet uses HTML in some level.

CSS describes how the page should look. It’s the lipstick of the internet. Take the following two screenshots of pages. The only difference in the two is one has CSS and one does not.
Here’s a page with CSS:

Here’s the exact same page with the CSS removed:

You can see that they contain the same content and words, but the visual experience with the page that has CSS is more defined than the “blank” visual feel without CSS.

JavaScript

Sometimes you’ll want to change the contents of the page or visual representation of the page without doing a full page refresh. In order to do this, you’ll need to write code that is known as run inside a web browser.

Because web browsers know how to run deal with these technologies: if you want to be a full stack web developer, you’re going to need to learn JavaScript, HTML and CSS.
Let’s walk through how JavaScript actually works inside web browsers.

Vanilla JavaScript

Modern web browsers all support the ability to modify the content on the page and cool ways to get data from different locations without reloading the page using the programming language JavaScript.

The JavaScript web browsers understand requires many lines of code to do very simple tasks. To get around these shortcomings an awesome developer implemented a way to make JavaScript easier for web developers. He called it jQuery.

JavaScript + jQuery

Most modern web applications use jQuery because it makes JavaScript development a lot easier. Basically jQuery allows you write only a couple lines of code to achieve the same thing that would take dozens of lines of code without it. With a little bit of jQuery and JavaScript you can implement a lot of custom functionality that runs in the browser.

Single Page Apps & JavaScript MV* Frameworks

Sometimes when you’re building web applications you may want to have a web application with a super complex interface without reloading the page. Applications like this are called “Single Page Applications”. Example of single page apps you’ve used are:

GMail’s inbox: When you click on an email thread it loads the message without reloading the page.
Facebooks stream: When you get to the bottom of the Facebook feed, it will automatically load the next status updates.
Twitter’s Stream: When new tweets arrive you’re prompted to update your feed without a full page refresh.
Front-end frameworks are generally useful only in the context of single page apps like these, which have complex user flows without any page refreshes.

The most common mistake people make when deciding a Front-End Framework is using a framework, when a solution without the framework would’ve been simpler and better.

More than 95% of the web applications you use on a daily basis are not single page applications. This means if you tried to use the tool on one of these problems you would only make things unnecessarily more difficult.

It’s incredibly common to take a simple problem that could easily be solved in several lines of jQuery and JavaScript, to have a much more complicated solution using a front-end framework. The allure of these frameworks is they can simplify radically complex userflows built into JavaScript, but most userflows are not radically complex. A run-down of the different front-end frameworks are: BackboneJS, AngularJS, EmberJS, ReactJS.

These do a great job at helping people build single page applications, although they have a number of challenges, they allow you simplify very complex JavaScript code.

If you use front-end frameworks in situations where they shouldn’t be used you’ll likely run into the problem that you need to have dozens of files that need 3-5 lines of “the magic incantation” that doesn’t actually do anything, but without them your application won’t work. In contrast you could just write several lines of code in a single file to do that exact same thing.

In order to fully understand “why” you’re using a framework like this, it’s important to write a complicated single page application without using a framework to actually understand the problem.

Database System

Web applications generally need to store user entered data in some way. Instead of storing data in files, web applications store data into database that allow users to add and extract data from the database.

There are two main categories of databases. Relational database and NoSQL databases. Both have pros and cons.

Relational Databases

Relational databases use a language called SQL (pronounced sequel), the Structured Query Language as a protocol to deal with the database. There are several implementations of SQL that are generally used in production: MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL.

You can connect to these databases with almost any programming language pretty easily. Although each implementation has slight quirks that cause it to be slightly different than the other implementations, the implementations are basically identical with small changes that are pretty easy to pick up.

Once you learn one implementation of SQL, you should be able to be comfortable in other ones. It’s much like learning English in the UK or US, there are some differences, but the fundamental language is usually the same.

When you think about the data, it will be stored in a manner similar to an excel sheet: there are tables in the database, which has columns and rows. And similar to keeping your excel columns understandable, SQL requires you to specify the columns headers up-front.

SQL is a tried and true database and is used by many modern web applications. Yahoo! uses PostgreSQL extensively, and Google and Facebook both use MySQL.

One of the big developments in writing database driven applications is known as “ORM”s or “Object Relational Mappings”. Systems are in place to convert regular code that is written in a programming language to the exact SQL commands that are needed to communicate with the database. ORMs for SQL databases exist in most programming languages.

ORMs make it very simple to get the data you need out of a database, or push additional data into the database. This means instead of writing SQL code, which is written in a different language than the other code in your application, the code that you write will be in the same programming language that you’re already used to and will be a lot easier to read than the SQL commands the database actually needs in order to run.

NoSQL Databases

NoSQL databases are a relatively new phenomenon. Instead of having a defined structure, they allow you to have lists of databases and push anything into the list regardless of the structure.

Inconsistencies can exist in how the data is stored. It’s generally considered a bad idea to do so. You’ll generally want entries to have a consistent structure, but the NoSQL database is flexible and will accept anything.

There are a number of different NoSQL databases: MongoDB, CouchDB, RavenDB, Redis.

Currently we don’t really have a standard for how data should be stored inside of NoSQL databases, so each NoSQL database will be considerably different. That means if you learn one type of NoSQL database, it won’t translate well to any other implementations.

MongoDB is one of the most popular implementations of NoSQL databases. It has a few features that allow for some interesting properties while scaling up an application to millions of users with hundreds of millions of database requests (or building applications at so-called WebScale).

Mongo’s features make it an good solution for ad servers and other applications that need to handle hundreds of millions of requests a day. On the flip side, it makes a it a poor choice for things like: Marketplaces, eCommerce sites, or other sites that handle less than 10 million requests per day (which is most web applications).

NoSQL Usage in the Real World

For every 10 web developers who write applications with SQL, there will be around 1 web developer who is writing applications with NoSQL.

In short: if you’re a web developer you’re probably going to need to work with SQL databases eventually, so you better start with learning what everyone else is using already.

Back-end Technologies

When you’re building any web application, you need to have a server to power and make it dynamic. The server that powers our web application will run on a specific technology and will likely perform most of the work that the web application needs to do.

Programming languages and web frameworks will allow you to write code that will allow you to store information in a database, retrieve the data, and determine what a user should see (like which avatar should be in the top-nav of the website). First you need to pick a programming language to use inside a server. Each programming language has popular web application frameworks as well.

Ruby

A popular choice for a programming language to use in your back-end is ruby. The programming language is a good option to choose for a first programming language.

Node.Js (JavaScript)

You can also use JavaScript in the back-end as well. When JavaScript is used in the back-end it’s called “NodeJS”. Node Js is exactly the same as JavaScript, except it indicates that it is JavaScript that is not running in the front-end.

JavaScript has a number of complicated language features that make it a good choice to learn once you’ve mastered a different programming language.

Things that make JavaScript hard to learn as a first language are: anonymous functions, callbacks, prototypical inheritance. Complicated topics like these are deeply ingrained into JavaScript, so even to understand basic code you need to understand a few very complex computer science topics.

It’s much easier to learn JavaScript after becoming a competent programmer in other languages first.

Web Application Framework

Web application frameworks help developers do things that are common and happen many times in most web applications with only a few lines of code instead of dozens or even hundreds of lines of code. Web application frameworks make your life as a developer easier, since you can focus on features you care about rather than mundane repetitive stuff.

If you’re building a web application: you should DEFINITELY use a web application framework to help you do the work!

Ruby on Rails

Ruby on Rails is a web framework that focuses on developer happiness. The core principle of ruby on rails is: Convention over Configuration.

This basically means that even though there are many ways you can do a particular thing, there is a certain way the the community will deem as “correct”, and if you do things the correct way your life will be easier.

This means once you understand how one application works, you’ll notice other applications, even written by other developers will organized in a remarkably similar manner.

ExpressJs

ExpressJS is a web framework that runs on NodeJS. It’s an unopinionated web framework. That means it doesn’t make your life easier if you do things “the right way”.

Comparisons between the two frameworks can be found on many places throughout the Internet:

Overall

Once you learn one web framework, you’ll learn the key principles and will be able to learn other frameworks very quickly, usually just by following the publicly available framework documentation. The hard stuff to learn about web application development applies to all frameworks equally: You need to understand databases, REST, HTTP requests and more.

If you’re good at Rails, you’ll be able to pickup Node/ExpressJS very quickly. If you’re good at ExpressJS, you’ll be able to pickup Rails quickly.

So to learn new web frameworks once you learn one it will likely take you about a weekend of coding to feel confident and able to be productive in the other framework, assuming you’re a self sufficient coder, which is what you should always strive to be.

In short: In summary of NodeJS vs Ruby on Rails comparison by the Co-founder of Buzzfeed, NodeJS is a great technology for a narrow band of problems. 100% JavaScript is generally overrated though. Rails gives you more of a full package, and makes things easier to do once you learn it.

Here are few notable quotes from the post:

However, it’s [NodeJS] really just a talented high school track star to Ruby on Rails’ Olympian.

Finally, assuming you have equivalent frameworks, database, and modules all set up, Node.js just takes much more time to string everything together [than Rails].

In many cases, it’s 1 minute versus 1 hour (which adds up if you have 4-5 database objects to contend with). It’s not necessarily hard work, but very prone to typos and simply a lot to remember.

In most cases Ruby on Rails will help you you’ll be able to code things quicker, with cleaner code, and better community support.

Node.Js vs. Rails: The Key Take-Away

If you’re a beginner learning to code web applications it’s important to consider what the right tool for the job is. For most web applications the right tool for the job is Ruby on Rails paired with a SQL database with some JavaScript & jQuery on the front-end. Using these tools will generally allow you to make progress on your application much quicker and be less error prone than the Full-Stack JavaScript approach.

Reposted From : TheFireHoseProject Blog

Node.Js Magazine

TOP-R-ad

Random Posts

Node.Js vs. Rails: How to Learn Web Development the Smart Way