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\u2019t, can you tell us a bit about yourselves?<\/strong><\/p>\n Marcin Grzywaczewski<\/p>\n<\/div>\n Marcin:<\/strong> Hello! I\u2019m a co-author of two books about React.js and my goal is to ease the pain of backend developers\u00a0 writing JavaScript. My primary interest right now is researching all potential educational opportunities Arkency<\/a> can provide to our awesome community.<\/p>\n Robert Pankowecki<\/p>\n<\/div>\n Robert:<\/strong> Yo! A few years ago I was disappointed by Rails speed in development mode so I wrote the active_reload<\/a> library. It was later incorporated in Rails 3.2 so everyone benefits from it every day. I blog<\/a> regularly about Ruby, Rails and React.js and some of those posts have thousands of readers every month :)<\/p>\n Robert:\u00a0<\/strong>Wow… I think I heard first time about Ruby and Rails in 2007 thanks to the amazing Beyond Java<\/a> 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.<\/p>\n As a Linux aficionado I wasn\u2019t going to bet my future on Microsoft technologies, so C# was not an option either.<\/p>\n 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.<\/p>\n Also, I rather prefer to work in smaller companies. Java and C# seemed so ‘enterprisey.’ I knew I didn\u2019t want to do that.<\/p>\n So I decided to bet my future on Ruby and Rails. Working for smaller software houses, doing startups<\/a>, in a quest to conquer the Internet. I couldn\u2019t 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.<\/p>\n 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.<\/p>\n But what if you\u2019ve 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\u2019t refactor things easily anyway.<\/p>\n So I think that the long-term maintenance and development is the Achilles heel of Rails.<\/p>\n Marcin:<\/strong>\u00a0I 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 \u2013 a thing you can\u2019t say about JavaScript libraries nowadays.<\/p>\n 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 \u2013 and that\u2019s the next big market advantage of Rails for me.<\/p>\n I totally disagree with Robert about Rails simplicity. Rails are not by any means simple \u2013 they are easy to use. This is a first weakness of Rails for me \u2013 if something goes haywire you often need to untangle all implicitness and layers of the framework \u2013 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.<\/p>\n 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.<\/p>\n Some would say that Ruby on Rails is on the decline. Do you agree? What do you think about its future?<\/strong><\/p>\n Marcin:\u00a0<\/strong>The so-called \u201cgolden age\u201d of Rails already passed, that\u2019s true. But I would not be eager to call the situation a \u201cdecline.\u201d Rails has matured. It is not as cool as other technologies like Phoenix\/Elixir or Go. It is normal \u2013 people have written a lot of complex apps with Rails and they\u2019ve 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 \u2018big\u2019 technology. Will it be Phoenix? Or maybe JavaScript solutions? I don\u2019t know, but honestly I\u2019m leaning towards the latter.<\/p>\n It is a natural cycle of technologies. DHH<\/a>\u00a0sold Rails perfectly \u2013 people tired with configuring their enterprise stacks saw that you could write a simple blog in 15 minutes. That was a tremendous wow factor<\/em>\u00a0attached to Rails from the start. Now, other technologies just followed the same path and are way better. It is not bad \u2013 we all benefit from such situation \u2013\u00a0we have better tools after all!<\/p>\n I believe Rails can\u2019t 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 \u2013\u00a0and they\u2019re our potential clients. It is no wonder they\u2019ll 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.<\/p>\n Robert:\u00a0<\/strong>There are two colliding trends in the programming world. One trend says \u201cuse the right tool for the job.\u201d It\u2019s the polyglot trend. Don\u2019t 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.<\/p>\n The other trend says \u201cWrite once, run everywhere.\u201d 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.<\/p>\n 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.<\/p>\n 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\u2019t 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.<\/p>\n 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\u2019t change until WebAssembly becomes production ready and used by the mainstream.<\/p>\n Do JavaScript frameworks successfully compete with Rails in web development? Are they going to substitute it?<\/strong><\/p>\n Marcin:<\/strong>\u00a0There are four stages of \u201cthinking in views:\u201d 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<\/em>\u00a0more dynamic. Turbolinks also are designed to optimize those first two stages of \u201cfrontend complexity.\u201d 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.<\/p>\n 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 \u2013<\/span> 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 \u2013 that\u2019s the way to go today in writing modern JS code served by Rails.<\/p>\n 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.<\/p>\n That being said, I believe we\u2019ll 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.<\/p>\n Robert:\u00a0<\/strong>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.<\/p>\n In terms of backend development, I don\u2019t think JavaScript frameworks offer substantially better experience compared to Rails. Unless you build isomorphic applications or you gain much by non-blocking code.<\/p>\n You wrote a book titled Rails meets React.js<\/em>. Can you tell us who this book is for?<\/strong><\/p>\n In Rails meets React.js<\/em> we strove to help with those two problems. The problem we\u2019re solving \u2013 writing a rather complicated form in React \u2013 is inspired by the real use case we had in one of the apps Arkency is maintaining. It is a \u2018classical\u2019 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.<\/p>\n Limiting our audience to Rails developers allowed us to share the knowledge by finding analogies to Ruby and Rails. I believe that\u2019s the biggest advantage of our book compared to competitors \u2013 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 \u2013 so I believe we succeeded with showing React.js in an easy way to people ;)<\/p>\n Robert:\u00a0<\/strong>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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n But this book is not built on my knowledge. Marcin was the primary author. He is so much better than me at this. He\u2019s more of a React guy in this book. I was the Rails guy ;)<\/p>\n Why React.js? What advantages does this framework offer over others? Why do Rails developers need it?<\/strong><\/p>\n Marcin:\u00a0<\/strong>Let\u2019s start with the advantages. React.js has a very limited scope \u2013 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 \u2013 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 \u201cwidgets\u201d. It has a young but powerful community around it, which is a big selling point for a technology. Think Rails \u2013 we\u2019d 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.<\/p>\n It has a very flat learning curve \u2013 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 \u2013 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.<\/p>\n That\u2019s 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.<\/p>\n Jumping to the second question \u2013 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.<\/p>\n Do you use RubyMine for everyday development? If yes, what do you like about it? If no, why not?<\/strong><\/p>\n Marcin:\u00a0<\/strong>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 \u2013 RubyMine has the most elegant solution of introducing ESLint I\u2019ve 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.<\/p>\n Robert:\u00a0<\/strong>I use RubyMine every day for our biggest project that we work on. I love how easily you can navigate around the codebase. Doesn\u2019t 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.<\/p>\n Are you missing any features in RubyMine?<\/strong><\/p>\n Marcin:<\/strong>\u00a0There are some performance issues and visual glitches I\u2019d like to be removed. ESLint highlighting is not as good as it could be \u2013 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.<\/p>\n 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.<\/p>\n Robert:<\/strong>\u00a0I 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.<\/p>\n Rarely I have a little problem with namespaced classes, the \u201cGo to declaration\u201d function jumps to an un-namespaced version. But it is more of an annoying little bug then a missing feature.<\/p>\n Oh, there is one little thing :) I like to format my code like:<\/p>\n object.call({ and you can\u2019t do it exactly this way in RubyMine :)<\/p>\n Tatiana:<\/strong> If you want to know more about Gulp support in RubyMine, please read this post<\/a> from WebStorm blog keeping in mind all the same features are available in RubyMine.\u00a0If you’re interested in more code styling options, please check this post<\/a>.<\/p>\n You coach, blog, record podcast and do lots of talks, among other things. What inspires you on a daily basis? Any books, blogs? Hobbies?<\/strong><\/p>\n Marcin:\u00a0<\/strong>I love to gain knowledge by reading classical books about software architecture and design patterns. Domain-Driven Design<\/a> and Implementing Domain-Driven Design<\/a> by Evans and Vernon are a must for every developer interested in consulting work. It is the most eye-opening book about programming I\u2019ve read in my life. There are also many other great resources \u2013 Fowler<\/a>, Beck<\/a>, c2 wiki<\/a>, Robert C. Martin a.k.a. Uncle Bob<\/a>\u2026<\/p>\n 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 ;)<\/p>\n 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 \u2013 just to try to \u2018think functionally\u2019 It can be a very refreshing and inspiring journey!<\/p>\n From a more \u2018computer science\u2019 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)!<\/p>\n Robert:\u00a0<\/strong><\/p>\n![\"Marcin](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2016\/03\/ruby-11406633_10153017193857862_367986883538216250_o.jpg\")
<\/p>\n
\n![\"Robert](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2016\/03\/ruby-rupert-metro.jpg\")
<\/p>\n
\n
\nWhen 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?<\/strong><\/p>\n![\"cover\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2016\/03\/ruby-cover.png\")
<\/a>Marcin:<\/strong>\u00a0I like to think that when you\u2019re 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.<\/p>\n
\nkey: value,
\nkey2: value2,
\n})<\/p>\n\n
\n
\n