Interviews

Interview with Marcin Grzywaczewski and Robert Pankowecki

Hello everyone,

Development is not only about your code, development is also about the bright people you meet along the way. Today, just before the upcoming webinar React.js from a Rails Developer’s Perspective, we want to share an interview with Marcin and Robert, known for their book on React for Rails developers. They kindly agreed to answer our questions, and we hope you will enjoy the discussion.

Hi Marcin, Robert, thank you for taking the time to speak with us. I believe all Rails developers interested in React.js already know you, but for those who don’t, can you tell us a bit about yourselves?

Marcin: Hello! I’m a co-author of two books about React.js and my goal is to ease the pain of backend developers  writing JavaScript. My primary interest right now is researching all potential educational opportunities Arkency can provide to our awesome community.

---

Robert: Yo! A few years ago I was disappointed by Rails speed in development mode so I wrote the active_reload library. It was later incorporated in Rails 3.2 so everyone benefits from it every day. I blog regularly about Ruby, Rails and React.js and some of those posts have thousands of readers every month :)

---

When and how did you get acquainted with Rails? What do you like about the framework? What are some of its weaker sides, in your opinion?

Robert: Wow… I think I heard first time about Ruby and Rails in 2007 thanks to the amazing Beyond Java book. I was studying at my university at that time and working with Microsoft technologies. I was certain that I did not want to spend my future working with Java. In my perception it was used everywhere but it was not a language appealing to me at that time.

As a Linux aficionado I wasn’t going to bet my future on Microsoft technologies, so C# was not an option either.

And although I only had experience with desktop apps, my gut was telling me that the Internet and web applications were going to be the future of programming.

Also, I rather prefer to work in smaller companies. Java and C# seemed so ‘enterprisey.’ I knew I didn’t want to do that.

So I decided to bet my future on Ruby and Rails. Working for smaller software houses, doing startups, in a quest to conquer the Internet. I couldn’t be happier with the results. Nowadays, I am working 7hrs a day remotely from my home. In a language that I love. In a cooperation with the amazing people from Arkency.

What I like about Rails is that simplicity it promotes. When there is a new language out there, you can be sure that very soon there will be a framework inspired by Rails written in that language as well. You can be very efficient in it and iterate quickly. And we know that iterating quickly, adapting is what makes it possible for startups to win.

But what if you’ve already won? If you look at 3-5 years old Rails codebase of a startup who is still in the game, will it be pretty? Not so much. Usually everything is tightly coupled with Active Record and the ecosystem of gems who plug directly into it. The JavaScript tests are usually very fragile. And the Asset Pipeline, so convenient at the beginning, is now dragging you down with lack of features. Validations contains a bunch of if-statements depending on which use-case is now using the models. There is no clear separation of modules and their responsibilities. And tests often rely on incorrect state created directly in the database so you can’t refactor things easily anyway.

So I think that the long-term maintenance and development is the Achilles heel of Rails.

Marcin: I like the speed of prototyping backend solutions in Rails. Even without using code generators, the main building blocks of Rails allow you to prototype the solution blazingly fast. It also reduces the boilerplate to a very reasonable level – a thing you can’t say about JavaScript libraries nowadays.

Robert is more experienced in Rails than me. He understands all the quirks, internals and cool features of Rails. But still I can work with the same velocity as him – and that’s the next big market advantage of Rails for me.

I totally disagree with Robert about Rails simplicity. Rails are not by any means simple – they are easy to use. This is a first weakness of Rails for me – if something goes haywire you often need to untangle all implicitness and layers of the framework – and there is quite a lot of them! This problem is partially mitigated by having really awesome community, so for the most problems someone already dug into the Rails and solved them, so you can just apply the solution someone else found.

The second problem and main weakness is that the programming model Rails encourages falls off when you start to work with a mid-sized or big-sized codebase. The implicitness that allowed you to kickstart your prototype and write it in a week will start to bite you then. In Arkency it is our main goal – we untangle all this implicitness and provide missing layers to the codebase, making it testable and maintainable. It is a common problem of frameworks, but since Rails encourages us to use _magic_ it is especially visible.

Some would say that Ruby on Rails is on the decline. Do you agree? What do you think about its future?

Marcin: The so-called “golden age” of Rails already passed, that’s true. But I would not be eager to call the situation a “decline.” Rails has matured. It is not as cool as other technologies like Phoenix/Elixir or Go. It is normal – people have written a lot of complex apps with Rails and they’ve seen that this is not a silver bullet for their problems. Voices of disappointment started to hit the mainstream. The same cycle is still before us for the next ‘big’ technology. Will it be Phoenix? Or maybe JavaScript solutions? I don’t know, but honestly I’m leaning towards the latter.

It is a natural cycle of technologies. DHH sold Rails perfectly – people tired with configuring their enterprise stacks saw that you could write a simple blog in 15 minutes. That was a tremendous wow factor attached to Rails from the start. Now, other technologies just followed the same path and are way better. It is not bad – we all benefit from such situation – we have better tools after all!

I believe Rails can’t ignore the trend of apps with rich user interfaces. People get accustomed to great, dynamic UIs like Facebook or Twitter. They use such technologies every day – and they’re our potential clients. It is no wonder they’ll demand the same level of interactivity from our applications sooner or later. The request-response cycle is not enough today and I think the path that Rails 5 is following is a great response to future market needs. Until Rails community involved in creating the framework will have the same level of market needs awareness, I believe the framework will live on for years from now.

Robert: There are two colliding trends in the programming world. One trend says “use the right tool for the job.” It’s the polyglot trend. Don’t reinvent the wheel. Use Ruby where Ruby fits, use Haskell where Haskell has most benefits. Know Scala, Clojure, R and tons of other things and navigate freely around them.

The other trend says “Write once, run everywhere.” We dream about cross-platform apps and business logic that we can use on server side, iOS, Android, web frontend, smart watches, cars, mirrors and who knows where else. Usually the language in this formula is JavaScript.

I think Rails is hit by both of those trends. People get to know Rails better and realize that it is not a perfect solution in every scenario. Other frameworks and languages might be faster, or can scale better or have existing tools and libraries for certain sets of problems which makes them better suit your needs sometimes. Even Rails companies know it and are interested in micro-services architecture, where some components with specific requirements can be developed using a better suited language.

On the other hand, if you have a very small team and a wide range of devices that you need to support, you probably don’t want them to learn all of the languages necessary to ship the product. Ideally you would like the developers to write code once and run it on any device. In that case JavaScript is winning because you can run it on the Web. And you can compile it or interpret on other devices as well. Of course you can try to compile Ruby to JS via Opal or run it on iOS by using RubyMotion. However, to benefit from it you need an architecture in which your business logic is clearly decoupled from the infrastructure, by using repositories, adapters, etc. Unfortunately, this is not what we teach in Rails community. We rather show people the opposite: How to make everything connected to ActiveRecord.

Also, Javascript wins simply by the size of its community. Every full stack developer knows a language for their backend and knows the JavaScript for the frontend. JS became the lowest common denominator in the programming language. And I think the situation won’t change until WebAssembly becomes production ready and used by the mainstream.

Do JavaScript frameworks successfully compete with Rails in web development? Are they going to substitute it?

Marcin: There are four stages of “thinking in views:” static pages, JS sprinkles, widget/page objects, and full SPA solutions. Rails provide facilities for satisfying the first two stages. No wonder people get interested in frameworks when they start doing more than small jQuery sprinkles to make static view a little more dynamic. Turbolinks also are designed to optimize those first two stages of “frontend complexity.” If your frontend starts to get more sophisticated, I believe JS frameworks do not compete, but clearly beat solutions that Rails can provide for you.

There is also another issue you should consider when your frontend needs start to grow. Sprockets is a mature solution which starts to limit your frontend code in Rails. Lack of proper modularity, no easy way to incorporate new JS standards, and no module-level processors to optimize your codebase – all that is a big deal. I believe it is the best way where JS-based solutions can cooperate with Rails. Use JS tools to build your JS assets, deliver built artifacts via the classic asset pipeline – that’s the way to go today in writing modern JS code served by Rails.

In terms of the backend, I believe that if you are not limited by performance and synchronicity of Rails, you can live with Rails. Node.js-based solutions are great substitute if you need to maintain great performance by sacrificing the elegance Ruby provides.

That being said, I believe we’ll see some movements which will substitute Rails with Node.js-based solutions. But there is a bigger opportunity for the community to learn how JS-based solutions can be used together with Rails to overcome issues Rails have today with modern JavaScript codebases.

Robert: In terms of dynamic frontend development, I think they already won. React, Angular and Ember took the biggest part and Rails Turbolinks does not look appealing to developers. Nor does it scale outside Rails. Using this solution is not a transferable skill that you can easily use in different languages and frameworks. And hopefully we are already past the render-HTML-and-stick-jQuery-on-it phase for anything serious.

In terms of backend development, I don’t think JavaScript frameworks offer substantially better experience compared to Rails. Unless you build isomorphic applications or you gain much by non-blocking code.

You wrote a book titled Rails meets React.js. Can you tell us who this book is for?

Marcin: I like to think that when you’re educating people, you need to make a real effort to understand the problems your students can experience when learning things. In case of React.js there were two problems when we were writing the book: most examples about React.js were written in JavaScript, which was not the way to go for most Rails developers. CoffeeScript is a local phenomenon of Rails, and I believe most developers I met then were way more used to Coffee than vanilla JavaScript. The second problem was that most examples were not close to the typical Rails developer work.

In Rails meets React.js we strove to help with those two problems. The problem we’re solving – writing a rather complicated form in React – is inspired by the real use case we had in one of the apps Arkency is maintaining. It is a ‘classical’ Rails problem that most developers probably needed to solve in their life. We wanted to stick to CoffeeScript just to make Rails developers more comfortable with the idea of React, without introducing a language unfamiliar to most Rails developers.

Limiting our audience to Rails developers allowed us to share the knowledge by finding analogies to Ruby and Rails. I believe that’s the biggest advantage of our book compared to competitors – it is not generic, but tailored to the needs of a typical Rails developer. Surprisingly the book was also bought by non-Rails people and we’ve had positive feedback from them – so I believe we succeeded with showing React.js in an easy way to people ;)

Robert: 2 years ago I was a backend developer who was too afraid (or rather too unskilled) of doing anything serious frontend-related. I was comfortable with static views. But complicated, dynamic forms? Not so much.

But Marcin joined the React.js bandwagon quite quickly, and he has been sharing the knowledge inside Arkency and via our blog. I decided to give React a try and it was love at first sight! It solved so many of my problems, eliminating an entire class of bugs related to rendering to DOM or inconsistent state between view and model. Building complex forms with React was pure joy compared to other solutions.

So I got involved in the process of writing this book because I felt that more people needed to know React and get the lovely results that I got with it as well.

From my point of view I tried to make the book give you the benefits that React gave me in my Rails codebase. Easiness of creating dynamic forms. Not necessarily making the entire app a Single Page Application. For me, it is a book for people who feel strong about their backend skills but now need a tool to get better with their frontend skills. React can make your forms rock. Our book tries to show how to achieve it.

But this book is not built on my knowledge. Marcin was the primary author. He is so much better than me at this. He’s more of a React guy in this book. I was the Rails guy ;)

Why React.js? What advantages does this framework offer over others? Why do Rails developers need it?

Marcin: Let’s start with the advantages. React.js has a very limited scope – it deals with the view part of your application, nothing more. It is un-opinionated about how you should structure your data flow. It is composable – it is both useful when you are rewriting the legacy codebase to React, and it provides a good thought model where you design your UI as a tree of smaller “widgets”. It has a young but powerful community around it, which is a big selling point for a technology. Think Rails – we’d be much less powerful without the awesome community we have. The ideas floating in this community are often well-founded in a classical software architecture or patterns sources. That means by reading about React.js you can improve as a backend developer too, which is a very cool side effect.

It has a very flat learning curve – you can start writing in React in a less than a day. I shipped my first React component to production on the same day I read about it for the first time. It can integrate with older solutions, like jQuery-based plugins in a very elegant way. It leverages the features of the language – compare it to Angular 1.x where you have a language inside a language to express things. It also makes it simpler to use. Last, but not least, Facebook, Airbnb, Netflix and a lot of other big companies use React, which makes it very unlikely to be abandoned in the near future.

That’s basically it. React.js is a solution you can learn fast, it scales well and you can introduce it in an easy way even in the most wild legacy codebases thanks to features like composability and easy third-party integrations.

Jumping to the second question – Rails developers need React.js if their frontend requirements gets more complicated than static views with JS sprinkles. It is a technology which has the lowest cost of introducing it in codebases. The programming model leverages static views so you can do a lot just by copying code with small modifications to the attribute names. It is easy to work with React.js in an iterative fashion, and it is easily testable.

Do you use RubyMine for everyday development? If yes, what do you like about it? If no, why not?

Marcin: I use it with Ruby-intensive work, but starting from 8.x releases it started to get along well with JavaScript and React codebases too. Navigation features are cool, as well as ESLint integration built-in – RubyMine has the most elegant solution of introducing ESLint I’ve seen so far. For me a replacement for RubyMine are text editors for simpler work. But on the level of IDEs, RubyMine is simply unrivaled and it is my IDE of choice.

Robert: I use RubyMine every day for our biggest project that we work on. I love how easily you can navigate around the codebase. Doesn’t matter if Ruby or Javascript or JSX. RM is great for both backend and frontend development for me. I even use it to write our blog-posts and books in Markdown.

Are you missing any features in RubyMine?

Marcin: There are some performance issues and visual glitches I’d like to be removed. ESLint highlighting is not as good as it could be – especially in terms of displaying linting messages in a more explicit way. Automatic code formatting is also suboptimal for me, but it is only because I have weird settings for indenting and symbol placements. Those things can be configured in RubyMine, but making the algorithm smarter by accustoming to your style automatically would be sweet.

Also more awareness about Webpack/Gulp in the RM would be great. An ability to start Webpack development server as well as Rails server together with proper transpilation error reporting would be optimal. But those are my wishes and minor inconveniences I can live with.

Robert: I experience occasional slowdowns of RubyMine, but nothing serious that would make me stop using it. The 8.0.2 release is the best so far for me. Much more stable and faster.

Rarely I have a little problem with namespaced classes, the “Go to declaration” function jumps to an un-namespaced version. But it is more of an annoying little bug then a missing feature.

Oh, there is one little thing :) I like to format my code like:

object.call({
key: value,
key2: value2,
})

and you can’t do it exactly this way in RubyMine :)

Tatiana: If you want to know more about Gulp support in RubyMine, please read this post from WebStorm blog keeping in mind all the same features are available in RubyMine. If you’re interested in more code styling options, please check this post.

You coach, blog, record podcast and do lots of talks, among other things. What inspires you on a daily basis? Any books, blogs? Hobbies?

Marcin: I love to gain knowledge by reading classical books about software architecture and design patterns. Domain-Driven Design and Implementing Domain-Driven Design by Evans and Vernon are a must for every developer interested in consulting work. It is the most eye-opening book about programming I’ve read in my life. There are also many other great resources – Fowler, Beck, c2 wiki, Robert C. Martin a.k.a. Uncle Bob…

The problem of these resources, signaled by their authors too, is that it is too easy to fall in love with, for example, CQRS/ES architecture and try to stick it literally everywhere. There are often fiery discussions in the Arkency team (which is also a great inspiration for me!) about topics around DDD, and it’s easy to follow the cargo cult. Fortunately we care about each other and can point to an exit if someone gets too excited about some ideas ;)

I also take A LOT of inspiration from functional paradigms of programming languages. Learning modern FP languages and reading resources about them can be a great source of top of the line solutions and inspirations you can follow. I greatly recommend taking some effort and learn a functional language – just to try to ‘think functionally’ It can be a very refreshing and inspiring journey!

From a more ‘computer science’ side of things, my interest is in supervised/unsupervised methods of learning and programming language theory. It is a great journey for everyone interested in cool applications of math, but still very practical for developers. You can be surprised how many proofs and/or models can be very similar or inspired by computer programs (or the other way around, of course)!

Robert: 

• Books:
  • Domain Driven Design by Evans
  • Implementing Domain Driven Design by Vernon
•  People:
  • Martin Fowler and Jay Fields – in terms of writing maintainable apps
  • Greg Young and Udi Dahan – for the CQRS/ES/DDD mix
  • Uncle Bob – design patterns that you should know about no matter what language you write in
  • Dan Abramov – structuring React.js and Redux apps
  • Amy Hoy – selling your knowledge for programmers
  • My entire Arkency team – in every aspect mentioned above

The wroc_love.rb conference has just finished in Wrocław, Poland. You were among the organizers and also held a workshop there. Did it bring you any interesting ideas or insight you can share with us?

Marcin: First of all, I’m very happy that so many people attended our workshop! I wanted people to learn something both useful and cool – and I believe most attendees made their very first steps with Redux + React.js, which was my personal goal. It was also a great example of how one technology can affect another – with Redux + React.js most components you’ll create (if not any component) will be pure – you can think of it as a function which takes properties and returns pieces of your interface. With such simple components many things like “what to keep in state” or “how to work with state” is not relevant at all – and that was the biggest problem with teaching React.js without Redux. In addition, it allows you to answer the next ‘big’ question that comes to you if you are learning React – so how to pass data around. Redux provides you with just that.

To cut a long story short, that was a great experience and I believe the approach with Redux scales pretty well and allows you to kickstart with React.js even faster. It was our first time, but many people approached me after and thanked me, so I believe it went quite well :) But without a great audience this workshop would be a catastrophe, so big thanks to everyone who attended – you were great!

Robert: This may sound controversial and a little harsh, but I want to express it anyway. I think both parts of the conference, attendees and speakers, are often wasting either their own or someone else’s time.

As a speaker, I have the ability to watch the audience and their engagement level from time to time. And the number of people who are not paying attention to the speech, not trying 100% to understand the message of the speaker, is quite high. I know that some of the speakers don’t have the skills yet, they are not as much entertaining as other speaker and so on. But as an attendee, you’ve already invested your time and money. You might as well invest the attention. I guarantee that this way you will gain much more from the speech. So turn off the computer, drop twitter, stop chatting and focus on the talk. Event if it is a bad talk. Especially if it is. Because the message behind it might be interesting, the code might be interesting, it’s just that the speaker is not so great. Accept it and take as much as possible out of the talk.

On the other hand, if you are a speaker and you have not spent at least 20 hours preparing for the talk, don’t be surprised if it doesn’t go well. There is a lot of stress and adrenaline on the stage. The only way to overcome it is to practice a lot before. Imagine the venue, visualize yourself on it. Where is your Macbook, where is the audience, how do they see your slides, how do you see them, how do you change them? These are simple questions and if you don’t know the venue, ask the organizers early enough. Otherwise you might be defeated by things you hadn’t anticipated during practice. Like the fact that you won’t see your own slides easily. You should know what to talk about even in such unfriendly situation.

Thank you again for your time, Marcin and Robert. Are there any more upcoming events or topics that you would like to ‘plug’?

Marcin: I’ll still educate people about React, modern frontend technologies in general and JavaScript – you won’t discourage me easily :) I can say that something great is coming in next months – so stay tuned!

—
Sincerely yours,
Robert Pankowecki, Marcin Grzywaczewski, and the RubyMine Team