Building your first Front-End Web Application in 2019: Should you use React, Angular, or Vue?

Source: https://www.youtube.com/watch?v=xDhzYQ4VyCw

React, Angular, and Vue are the three most popular tools for creating Front-End applications in 2019. But which one should you use for creating your first web application?

As you might expect, the short answer is something along the lines of “They are all great tools and you can be successful with all three. Use the one that is best for your situation!”, but that isn’t a very satisfying to hear. First and foremost, we need to know more about each option so we can make an informed decision.

There are many factors that one can consider when comparing the three:

  • What kinds of features are offered?
  • Do they have differing levels of performance?
  • What kind of support is available?
    • Documentation
    • Active community
    • General popularity
  • What will be the anticipated longevity of my application?

And many more…

It’s a bit overwhelming. So let’s break it up and look at all three in turn.

React

React is a library for building interactive user interfaces, or UI for short. It is built for easy and lightweight component creation. In other words, it was designed to be relatively simple to learn (assuming a working knowledge of Javascript/HTML) while still being an efficient way to render and update content to your application.

React is very popular and has a large active community. This has led to the development of a good number of open source extensions for popular text editors, like the Visual Studio IDE, and this lessens the barrier to entry for React.

React was developed and is maintained by Facebook and is used in many of the world’s most popular apps such as Twitter and Netflix. It is still evolving at a fast pace and the documentation can vary in quality due to this dynamic nature. However, Facebook takes the stability of React very seriously and you will not experience breaking changes from version to version of React.

React’s main focus is on the UI, so if you want to use React in your application then you should expect to also end up incorporating other third party libraries (It should be noted though that there are many great libraries available for use). Also, React uses JavaScript XML syntax (or just JSX) which is a way of writing HTML in Javascript. This can be an initial turnoff to some, but is not that large of a mental stretch after a little experience. The Babel module that is included when you create a new React app will compile the JSX into plain JavaScript for the browser to understand.

Angular

Angular is a framework that is much larger than React or Vue. Like libraries, Frameworks have built-in and reusable code, but unlike libraries they also provide a larger structure for building out an entire application. This makes Angular more suited as a single solution for building out a full scale application.

Because Angular is the oldest and largest of the three, it also has the most capable command line interface. Angular also uses TypeScript which is a bit friendlier to developers who don’t have a deep knowledge of Javascript.

Angular’s large API is both a gift and a curse. While it provides many “in-house” solutions, it accordingly has the steepest learning curve.

Angular code can also become much more complex than React or Vue and this can also become a barrier to entry when using Angular for the first time.

Vue

Vue is somewhat of a middleground between React and Angular as it is a smaller scale Framework than Angular, but still offers a wider variety of tools than standalone React.

Vue is also an interesting blend of being easily accessible for new developers while also being powerful enough for experience developers. It is certainly not a tool that you would outgrow.

Vue is also known to be well documented which is always a great plus. On the flip side of this, Vue is also the youngest of the three and consequently has the smallest active community. While it’s community is not as well established, it is projected to grow significantly in coming years.

So now we have some information about React, Angular, and Vue, and maybe this was already enough for you to start making an informed decision about which might be best for your first application. In case you are still on the fence, I’d like to turn to some polling data from Stack Overflow – https://insights.stackoverflow.com/survey/2019

In most polls, React comes out as one of the most desired Web Frameworks (React is technically a library, but when coupled with other third party libraries it has the same functionality as a full web framework) to use and to be skilled in professionally.

We can also see in this polling data that Vue is more wanted/loved than Angular as well, although the implications of this aren’t so clear. There are still more professional jobs available for developers with the Angular skillset, but the polls indicate that this might change in the coming years.

Given all of the available data, React seems like the best option for building your first web application as it has a lower learning curve and is also a desired skillset in the workforce. Skills you gain by developing in React would also be somewhat transferrable to React Native which is used for developing mobile apps.

All in all, you can’t go wrong with any of these tools and all three have a unique blend of advantages and disadvantages. While I would lean towards saying that your first web application should be built with React, every developer needs to weigh the available data along with their own circumstances. I hope that this information will lead you towards making the best decision for your personal advancement as a web developer!

How Chess Inspires Me To Be A Better Web Developer

When getting to know me, it doesn’t take long before I mention my passion for playing chess. Unsurprisingly, I often get prompted on why chess is my favorite game and truthfully I’ve never been able to give a concrete answer. I could say that I enjoy the complexity and I wouldn’t be lying. But I could also say the same about enjoying my involvement in the larger community of chess players, being able to follow the careers of top professionals, and maybe most simply just the raw competitive thrill that comes from playing tournament chess. What I’ve come to realize though is that the most fundamental reason of all is that I love immersing myself in the process of learning, practicing, and improving a skill, and chess is a perfect medium for that process.

With this perspective, it’s no mystery to me why I also deeply enjoy web development and more generally, computer science. Personally, my process for learning and improving at chess and learning and improving as a web developer is largely the same. It isn’t that difficult to show how both disciplines utilize similar methods of logical thought. After all, you can’t play good chess or write good code without a decent understanding of control flow. More interesting is how improving at chess and improving at coding requires you to research in a similar way. For example, as a developer I frequently consult online documentation of different computer languages, parse through forums where people asked questions similar to mine, and, when I have time, read published books that cover the topic I am interested in. This is all necessary in order to learn new things and improve (or often just fix) my code. The same is true for chess. I am always working with game databases, chess programs, and chess literature in order to find answers to my questions and gain new insight into the game. The answers are almost always there if you look hard enough.

I could sit and list the similarities between chess and web development at length, but that wouldn’t give you the full picture. To me, it’s not just that the two are similar, it’s that chess has now become inherently tied to web development. Even though “modern” chess has existed for hundreds of years, the overwhelming majority of chess games were played in the last decade alone because of the advent of internet chess. Back in 2014, one major website claimed to have served over a billion games! https://www.chess.com/article/view/chesscom-1-billion-games-served There has been an ever increasing demand for more and better chess features, and the chess websites are delivering.

There is also a growing demand for live-streamed chess, but that is a story for another day…

One website that has recently inspired me to be a better web developer is lichess.org. Lichess was built out of a desire for there to be a free and open source chess platform that could be accessible to all. While it is worked on primarily by a core group, much of the site was built via the contributions of many passionate developers from over the world. For 9 years it has been continually improving and pushing the boundaries of what is possible for a chess website to offer, and earlier this week it became even better. The site has been completely revamped to fix current limitations and also established a better foundation for future features to come. https://lichess.org/blog/XMvcJSwAADkA0hPE/lichess-v2-is-here

Most of the time lichess is praised for adding some cool new feature, but this time the praise really needs to go to how they approached improving their user interface and website speed. Take this example snippet from the above linked article:

“Highlights include:

  • Rewriting all 365 Twirl templates to Scalatags templates. This is long and boring work, but we now enjoy added type safety and expressiveness of pure Scala templates. Also supposedly faster to compile and run.
  • Rewriting the entire website CSS to SASS and gulp. The use of build tools allows for building better production stylesheets, that only contain the required selectors. While v1 homepage loads 5 CSS files for a total of 22.6KB, Lichess v2 only needs 3 files and 13.8KB.”

The dedication of the lichess team to continually improving the user experience and site functionality is a genuine inspiration for me. It continually reminds me of why I dove into web development in the first place and heartens me for the future. One day too I hope to contribute to projects like lichess and I look forward to what happens next for me, and for chess!

Easily Access Public API Data With Some Nifty Ruby Gems!

Overview:

  • What is an API? (in brief)
  • Where do we find data on an API?
  • How can we make sense of this data?
  • Pulling data from server with ‘rest-client’ gem
  • Parsing JSON with ‘json’ gem
  • Seeding a database with data (example relies on ActiveRecord/SQL and Rake)

What are APIs? In plainspoken terms, an application programming interface, or API, is a way for one program to access features or data from another program. Many APIs are publicly available/free, but just as many are paywalled. Here I will be considering APIs that have free public access to endpoints and are written in JSON. A quick aside on endpoints and JSON: Endpoints are exactly what they sound like – the data locations. JavaScript Object Notation, or JSON, is a standard format for structuring data (it looks a lot like Ruby hashes and arrays).

So I’ve painted an extremely vague picture of what an API is, but how do we use one? If we are utilizing an API which stores data on some server, all we need to do is make an HTTP “get” request to that server to obtain the data. Let me demonstrate by example. Consider this free Pokemon API:

APIs like this can often be found by simply querying something like “Pokemon API” in your favorite search engine!

Ok this is a nice interface, but where is the data? Let’s check out the API’s documentation which is conveniently linked in the top right corner.

As a side note, I want to make clear that most APIs are presented differently and many do not have documentation as nice as this one. Documentation is typically found via a GitHub ReadMe or some similar markdown document. But for now, let’s enjoy this nice interface!

WOW. Look at the left side-bar. This API contains a TON of Pokemon related info!

A little navigation leads to a page like this where I am now very close to what I was trying to find. Notice the urls in the picture:

ENHANCE! The urls all seem to point to a location where data is stored on the server

Url’s like these are where the API endpoints exist. Or in other words, where the data lives. Navigating to one will probably bring you to a page like this:

Yikes!

Ok that’s a bit overwhelming. How can we hope to use the data effectively if we have to comb through it with a microscope? Luckily for us, there are tools that will assist us to take a closer peek at the data on a page. Often these tools can be found as free browser extensions that enlarge and structure the JSON to make it legible.

An extension that has served me well is the JSON Viewer for Google Chrome:

https://chrome.google.com/webstore/detail/json-viewer/gbmdgpbipfallnflgajpaliibnhdgobh?hl=en-US

With this extension activated, the previously jumbled page turns into this:

That’s a huge improvement! The page is longer and more structured.

The page has become broken out into a much more user-friendly form and we can better see what we are dealing with!

Now that we have an idea of where data lives on a server and know how to identify the structure of the data, let’s actually demonstrate how to pull some data from an endpoint.

In this example I will be seeding a SQL database by creating a Rake migration for a table called ‘wild_pokemons’ and a corresponding WildPokemon class that inherits from ActiveRecord. Unfortunately, I will not be delving into the specifics of Rake and ActiveRecord here since it is beyond the scope of this demonstration. However, I will begin by investigating two helpful Ruby gems: ‘rest-client’ and ‘json’.

I’ve added these two gems into my Gemfile. Don’t forget to run bundle install after adding new gems!

So what do these two gems do for us? Essentially, ‘rest-client’ makes it easy to copy JSON from a specified url and ‘json’ converts that JSON into more familiar Ruby hashes and arrays. Time to see this in action. Let’s say I wanted to get data on a specific Pokemon from the API (conveniently I have already gone and found the url endpoint for this). In a db/seeds.rb file I would make a method that looks like this:

Don’t forget to require your ‘rest-client’ and ‘json’ gems in the file!

Let’s break down this method. Firstly, this method has an input attribute, which I have called ‘id’, that is used in the url of the GET request on line 5 . Since the information for different Pokemon is organized by the Pokemon’s index, this ‘id’ attribute will be interpolated into the url string so that I get data for the desired Pokemon. For a more static case this attribute might not be necessary, but in this case a dynamic url fits the bill.

Next I store the results of RestClient.get("...") in a variable I have called ‘data’. This RestClient.get() function is available to us through the ‘rest-client’ gem and it simply makes a HTML request to the desired url. Since the content of ‘data’ is JSON (which we can’t modify like a normal Ruby hash or array), we need to convert it into something more familiar. This is what we are doing when we call JSON.parse(data) in line 6. We are converting the content of ‘data’ to its equivalent Ruby hash/array version while conveniently making it this data the method’s return value at the same time.

That’s a great start! Now we have a way to access data from the API and turn it into a familiar Ruby structure. Let’s say I had made this rake migration table:

Making a database table called :wild_pokemons in db/migrate/001_create_wild_pokemons.rb

And also this model class:

Now I have a database to seed. Let’s go ahead and see what that might look like. Being a fan of the first generation of Pokemon games, I want to store some information about the first 151 Pokemon in my table. Unfortunately for me, the descriptions of each Pokemon are stored in a different area of the API! Looks like I’ll have to make another helper method:

This is what the structure of descriptions looks like in the JSON viewer. Descriptions come in different languages!
Similar to before, but with more digging into the data structure to get what I want.

This time the data I wanted was nested a bit in the data structure. Each Pokemon has multiple descriptions and many of them are in different languages! For simplicity’s sake, I just iterate on the array of descriptions (which was stored as the value to the “flavor_text_entries” key in the hash) and return the first description that is in English. Sometimes you really need to dig out what you need! Now that I have all of my data, I can use the ActiveRecord ‘create’ method to start seeding my database.

A bit verbose, but structurally very clear

Here I take a simple loop that will also continually provide me with a new index of a Pokemon to instantiate in my database. First, I use my ‘get_pokemon_data’ and ‘get_description’ helper methods to request data on the current Pokemon index and store the desired information in variables. Next when I call the ActiveRecord ‘create’ method on my WildPokemon class, I can set the table columns equal to those variables and all the data will be instantiated into the table. All I have to do now is call the ‘seed_wild_pokemons_table’ method somewhere in my seeds.rb file and when I run the file my database will be seeded with all of my desired information!

Hopefully this example of using an API to seed information into a database will help you to manage API data of your own. APIs are powerful sources of information and learning how to tap into them is invaluable. Happy coding!

Ruby Array to Hash with Array Elements as Keys and Element Counts as Values

As a newcomer to the Ruby language, I’ve been leaning extra heavily on online Ruby documentation as I am not yet accustomed to many of Ruby’s common built-in methods. It wasn’t long though before I encountered a scenario that I thought would have a simple built-in method solution, but surprisingly didn’t.

I wanted to take an array of elements and turn it into a hash where the array elements would become keys, but duplicates of that element would be counted and stored as value of that key. For example:

As I soon discovered, there are many solutions to this problem. But before I show a few examples that you can implement yourself, should you be in a similar scenario, let me show you my first attempt and how I came to refactor my code into one of those more concise solutions.

My first attempt went something like this:

Not exactly elegant, but it does work as intended. My method takes in an array as an argument and iterates over that array to create a hash. As the .each method goes through my array elements one-by-one, it checks if that element is already a key in my new hash. If it isn’t, I create a new key and set the initial value to 1. If it is, I simply increment that key’s value by 1. At the end, I return my beautiful new hash.

Ok but this is clunky. The first thing that stands out is my conditional statement in the .each method. Is this really necessary? Not at all. A quick but significant change makes this simple to condense:

The big change here occurs in line 2. Hash.new(0) will give new hash keys a default value of 0, rather than the default nil value we had from the simpler { } assignment. This is what allows me to immediately increment a new key and eliminate my need for a conditional statement.

Since I can still make this code more concise without distorting the process, I’ll go ahead and do that. After all, it is always satisfying to have a clean 1 line solution.

Nice! A simple solution to a simple problem. However, when it comes to coding there is rarely only one way to go about solving a problem. Here I’ll share two additional solutions that I quite like:

A very clever solution that builds the keys using the .uniq method and the values using the .count method
Source: http://carol-nichols.com/2015/08/07/ruby-occurrence-couting/