Have you read our previous posts about Vojta, our QA & Scrum Master and Ondra, our new QA? Do you want to meet another team member? In the blog post we introduce Jiri, our Technical Team Lead & Software Architect!
Q1: Jirka, could you say a few words about yourself, please?
I come from Ostrava, where I also graduated from university.
I started programming on the PMD-85 8-bit computer when I was 13. I tried to make games, of course.
Professionally I have been into programming since 2001. I have worked with ANSI C in UNIX, C++ in Windows, Objective-C in iOS, and Java almost everywhere – from Java EE on backend to UI in Eclipse RCP.
I did not know too much about web frontend development in JavaScript so I was very curious what kind of adventures would be in store for me there.
Q2: We decided to use quite modern technology – Elm – for implementing Newired Journeys; can you say what the selection process was and why we eventually chose it?
When we started looking into it to find the right technology, none of the team members had a deeper personal experience with any of the JavaScript frameworks. I mean long-term experience in a real-life project.
This may seem like a handicap, but it actually gives us useful perspective.
We knew that we needed technology for a clean SPA (Single Page Application). So nothing that would require content generation on the server.
We were looking for something to provide us:
- Easy and safe refactoring
- Easy testing
- Good interoperability with pure JavaScript
It did not take too long, and there were only three options left on our list:
- React.js (+ Redux)
- Angular2
- Elm
React.js is mainstream these days. A king. But we did not stop there.
Angular2 is alpha now.
And Elm looks simply too cool for a real business project.
When we were collecting information about React.js, an interesting aspect repeatedly came to the fore.
If we chose React.js, it would still be necessary to decide about other issues.
For instance:
- Should we use pure JavaScript (ES5 or ES6), or a type system? Flow, or TypeScript?
- Should we write UI in JSX?
- How should we use Redux (which is directly inspired by Elm)?
- Should we use some of additional tools like Immutable.js?
None of these decisions is plain sailing, and – what is worse – it is not easy to reverse any of them. What if we realized that Flow had been a poor decision, and should be replaced by TypeScript? How easy and safe would it be to rewrite our code? Additionally, with each of the above-mentioned tools, the complexity of the project build/setup is growing.
If we chose Elm, we would get all-in-one.
So then we came to the conclusion that Elm is a real alternative. It remained to proof maturity of Elm.
Elm was initially designed in 2012 and when we started playing with it, there was version 0.17 with a quite stabilized API available. We already experienced moving to next version (0.18), and it was a one-day task.
The Elm community is just stunning. Any of our questions on Elm Slack was answered in full detail and kindly at that – the atmosphere is very friendly.
Q3: Did everyone in the team liked it from Day 1? How did the adoption proceed?
It will not be an understatement when I say that all team members loved Elm from very first day (there were four of us at that time).
Q4: How would you evaluate it now, after 10 months? What benefits or drawbacks can you see in practical use? Would you reverse the decision?
The 10-month experience with Elm has confirmed all the hopes and expectations we originally had:
- Easy and safe refactoring
- Quick adoption; new developers are able to write Elm in 2–3 weeks
- Reliability: If it compiles, it works (without runtime exceptions)
- Great testability
As for refactoring:
We have experienced the following scenario several times.
We started new part of our application with a proof-of-concept. Then we took this concept and gradually improved, extended, and refactored the code to final shape. All team members are used to refactoring Java or C# so it is not a whole new world for us. I can even see refactoring in Elm as much easier and safer. Maybe it is just because of the pure-functional nature of Elm. Pure functions, immutability and application state stored in one place are most probably the actual reasons why it is so easy to refactor. It’s simply great.
Q5: Do you have any vision of the further technological development?
Elm seems to me as ideal entry language for functional programming. Past experience gives us enough self-confidence to use Elm for more and more parts of our application. I would not even be afraid to go into proof-of-concept to try a functional language on backend where we are happy with Java today.
—
Do you want to know more about Elm or meet Jiri in person? Feel free to join us on our next JS MeetUP, Newired led community in Ostrava. You can watch recent presentation by Jiri (Czech only): https://youtu.be/ANjTGRodz4I?t=23m20s