React Native UI library choices come in many different flavors and sizes. A lot of thought has been put into these libraries to save developers many hours of tedious setup time. The creators are also very interested in fixing bugs and making their libraries even better so that we all can benefit. They are great tools for development and get you up and running fast.
A Simple Question
When starting out, I felt it was important to learn about the UI library options out there, and I wanted the “correct” one implemented into my projects right away.
I realized that many libraries had a learning curve, and used different approaches to accomplishing the same thing. I also found myself often digging into the default styles, and other “under the hood” type of things, to fit my clients’ designs.
Some components also had bugs in them that left me at the mercy of the developers, unless I spent some time getting into the library’s code and fixing things.
I found the libraries began to work a bit against me, instead of making my workflow easier. I still felt this was the way to go. The libraries have so many re-usable components all set up and ready to use. I felt once I got over the learning curve, and default adjustments, it would be smooth sailing.
Some time later I got a new project which I had the opportunity to co-architect. I spoke to my teammate on the project with my options for UI libraries, suggesting my favorite ones. His response was simply, “Do we really need one?”.
At this point in time I had not really thought about that question. I guess I assumed we did need one because, how could we possibly work fast without one? We had to build from scratch otherwise, and it did not make much sense to me.
I’m glad my colleague asked this really simple question though, because he was right, did we really need one? The answer for our project, I found, was definitely no.
Think More About “why” and Less About “how”
It felt great to just start getting things laid out right away as we began working on our project. I did not have to think about how a particular library requires that I nest items or configure them. Finding and tweaking default styles was out of the picture.
Each component was controlled by a simple style file, and some global colors and fonts — the rest was just a combination of built-in components. View, TextInput, TouchableOpacity, TouchableHighlight, and list components got me very far. I was aware how I was affecting every part of my components because I had full control of the styles I was adding. If something was off I knew exactly where to fix things. I could finely tune whatever I needed.
I was getting work done extremely fast. In fact, it was probably the fastests I’ve ever done layout in React Native before. And I felt less stressed, and happier as I worked.
I learned a good lesson here. I thought I should use a React Native UI library because it seemed like a requirement for React Native developers, but I never asked myself why I needed to use it to begin with. It would have been completely unnecessary in this case. And I feel we would have lost a lot of time.
Don’t get me wrong, these libraries are really great and powerful. They just don’t help you all that much in all projects — especially those with very custom design work.
I have been learning to question current standards and choices more as I continue to get more experience in software development. Instead of just assuming that there is good reason for a specific decision, I have learned to ask why was that decision made — and why it is better over another option. My work has improved because I have now come to understand that it is OK to question what seems to be the standard.
