Ever since Facebook open-sourced Relay, I’ve wanted to try it out. The thing is, I never had enough time to set up all the things I needed: the backend server, the GraphQL configuration, the schema, the database, the endpoints, etc. There were just too many things to do!

I even hesitated over whether I had to do the backend in Ruby on Rails, which is what I’ve been using on the backend for years, or on something like Express with this starter kit. Every time, I concluded that I should do the backend in Ruby, as that is what I would use if a new project were to pop up with this stack. The problem is that I ended up doing nothing.

I’ve been working with React for quite a while now, creating apps of all sizes for several clients. In my opinion, React was one of the major breakthroughs in front-end web development, and it has brought the joy back to creating interesting and complex UIs in the past few years.

A couple of months ago, a friend of mine who also uses React recommended Elm to me. That was when I noticed it was mentioned in several blog posts, in the docs of Redux and in a number of conferences such as the Reactive Conf or the React Conf 2016. One thing of note is that “Rethinking All Practices: Building Applications in Elm” was the only non-React or React Native talk in the whole conference.

For those who don’t know Elm, Elm is a functional programming language that compiles to JS, HTML & CSS, and one of the biggest selling points is that the language guarantees no runtime exceptions and an easy front-end development experience. The idea is to provide a solution to Javascript’s lack of maintainability and hard-to-catch production errors.

React is used by a number of well-known companies with large applications that cater to millions of users, and their code base is being constantly changed by engineers.

A wide range of articles show how to create simple apps like ToDo lists with React, but there aren’t many that show how React is used in production.

This is why I’ve been working on a series of interview articles that will show how React is used in large apps.

In my first article, I had the honor of asking a couple of questions to Leland Richardson, Software Engineer at Airbnb, and the main contributor to their React Testing Library Enzyme. Read on to find out why they chose React, how they use it, and what challenges they have encountered in the process.

Say you’re a web developer and have been interested in mobile development for years, but you haven’t had the time or the motivation to learn it. You know it will take a great deal of effort because you would need to learn not only a new programming language like Objective C, Swift or Java, but also a completely different set of tools — for example, Xcode or Android Studio.

In the past, you got excited when different frameworks like Ionic or Apache Cordova appeared. They promised to give you the ability to target multiple mobile platforms with just one code base, but for some reason you lost all your interest when you noticed that apps created with these frameworks didn’t feel like real native apps.

Last year, React Native suddenly appeared, and you were not sure that investing your time and effort in it would worth it.

Why would this time be any different?

The short answer is that you should use CSS Modules. Here’s why:

As you all know, the JavaScript & React ecosystem is evolving at a fast pace. Many people say that it may even be evolving too fast. You may find yourself using a library for a new project, and two months later you’ll find out that the library is no longer the industry practice, and everyone has started using some other newer, shinier library.

After Facebook announced the Flux Architecture in 2014, there was a Big Bang explosion of different libraries that solved the state management problem in a number of different, subtle ways. There was a new library on GitHub almost every month — nearly every week. Some examples include: DIY Facebook Flux, Fluxxor, McFly, NuclearJS, Flummox, Fluxette, Lux, Marty, Reflux, Alt, Yahoo-Fluxible, Delorean, Barracks, Fluxy & Redux (which isn’t exactly a form of Flux architecture, but it has certain similarities and solves the same problem).

As time has passed, this chaotic environment has begun to stabilise, and three final contenders have emerged as the industry practice: Alt, Reflux & Redux. A few months later, Redux came out on top, and it is now the only state management library that people are talking about.

The same thing is happening with the way we manage our styles. After agreeing on the historical problems CSS presents (e.g., Global Namespace, Dependencies, Dead Code Elimination, Sharing Constants), lots of new libraries have suddenly appeared. The following are some of the new ways to style React components: React Built-in Inline Styles, Radium, React Style, React Inline, jsxstyle, React JSS, CSS Modules, React Shadow, react-in-style, React Free Style, React Look, smart-css, Stillr, React Inline CSS & react-css builder, among others.

If you’ve used different flux alternatives in the past – with the state of your application spread across multiple stores – you may think the way Redux manages your app in just one object would bring about performance issues, especially as the object becomes increasingly large.

I had the same doubts, and I have seen quite a few people ask the same question. Even Dan Abramov, the creator of Redux, addressed the subject. Check out what he had to say here.

So… am I going to have performance issues with a large state?

The short answer is no.

It’s a common misconception that the state is held in a gigantic object. Remember that in Javascript, objects are passed by reference.

I know this sounds easy, but I’ve seen this question several times in stackoverflow, the reactiflux chat and the react subreddit.

“I’m trying to write a simple If…Else statement in JSX, but for some reason I can’t make it work.”

“I feel dumb asking this, but what is the best way to write an If…Else in JSX?”

I understand the uncertainty here, as learning React was quite easy for me, but it took a long time before I knew the best way to write simple If…Else statements in JSX.

Every time I needed to write a conditional, I would do it in a different way, and I would feel frustrated by my inconsistency.

Here are some different ways you can write If…Else conditionals in React:

It all began two weeks ago, when I started working on a really interesting design and coding freelance project outside of Viralica’s working hours.

I charged a fixed fee for this project, so I thoroughly estimated all the tasks that needed to be done, and identified all possible contingencies before calculating that fee.

Although I’m not paid an hourly rate, I decided to track how many hours I put into the freelance work to determine whether my estimates were correct. By the end of the job, I realized that I didn’t end up logging more hours than I’d thought.

I could have tracked my time on a piece of paper or on a Google Docs Spreadsheet, but I wanted an easy-to-use time tracking app with an integrated stopwatch. After doing a little research I found Harvest, a really neat app with a free plan and a simple user interface.

After using this app for two weeks, I noticed that it offered some amazing benefits — even more than I’d assumed in the first place. I was able to track the time throughout, and calculate the total hours I spent on the project.

Let’s say tomorrow I had to create a startup from scratch without knowing how to code. No Ruby, no HTML, not even a single line of code. What would I do?

Lately I’ve came across with lots of articles talking about finding your technical co-founder. I think it’s super important to find a good technical partner but is something I wouldn’t do in a hurry. While searching for someone, here I list a couple of things I would do:

Last week I was lucky to participate on Sean Ellis’ Ask Me Anything on Inbound.org.

For the ones who don’t know him, he is the CEO and Founder of Qualaroo, the author of Startup Marketing and a tremendous Growth Hacker.

When he was asked about what was the biggest mistake he made or constantly sees others make, he gave the following reply that got me thinking and made me write this article.

The biggest mistake I’ve made and see others make with SaaS tools is always trying to get the big win customer acquisition channel rather than doing the disciplined work of managing all of the growth levers. SaaS is something that can become a 20%-50% M/M growth rate through hundreds of micro optimizations across every part of the business.
Disciplined patience growing a business at 20%-50% M/M revenue growth gets really big after a couple years. And with SaaS multiples, within a couple years you can become worth 100s of millions of dollars. SaaS is not a get rich quick scheme, but if you are delivering true value in a disciplined way, you can build a very valuable business.

Continue reading...