Software development can be as much about choosing the right technology as it is building it. Decisions like which front end JavaScript frameworks to tie your application's future to are difficult because there is so much to consider about the present and future of needs. The landscape has been in shift for quite some time and you might find wholly different outlooks depending on who you talk to. There are a lot of considerations in choosing a JavaScript framework, ranging from the technical minutia of message passing and data flow, the supporting built tools and module ecosystems and various learning curves.
At the core, though, the decision might be less about the API details and more about the outlook for the project, getting a sense for how the team operates and thinks about software. The success and failure of open source web projects like Node, Rails, etc. depend on a lot of factors in teamwork, leadership and vision. Extremely well-funded projects like Famous.js have failed and projects maintained by a few people in their spare time sometimes thrive.
I will be attending Reactive Conference next month, where Igor Minar is going to discuss how the web ecosystem shaped its application framework. Igor is the leader of the Angular project, the popular JavaScript framework developed by Google. I reached out to him to ask some question I had about how the Angular team operates, from his perspective. With Angular 2.0 having been recently released, it's worth getting a feel for how the project lead treats development strategy and community, for your consideration when mapping your own application's future.
Igor is a busy individual, so I am grateful that he was able to answer a few questions.
Questions for Igor Minar
How does the team make decisions and weigh input from the greater community?
There are two primary ways this is done. First, all of the development is done in the open and we make all of our design docs and meeting notes public. This allows the community to weigh in and point out missing requirements or overlooked designed flaws. Second, we are in daily contact with many members of our community that provide valuable feedback and highlight issues that we might have missed.
How do you balance thinking about short term needs and future-proofing the project?
It depends on if we are talking about public API or internal implementation. With the public API, we tend to be conservative because mistakes here could be very costly to fix, often it makes more sense to provide a workaround for a short term need then change the framework. When talking about the internals of the framework, the focus is on maintainability and malleability because that's what allows us to evolve the framework.
How does the team deal with any technical debt that may accrue, or deal with conflicts of design?
In the ideal world all technical debt could be avoided, but that's not possible in a world with deadlines. The most important thing for me is that everyone contributing to the code-base feels a sense of ownership and responsibility for it. This combined with various checks during our CI testing helps to decrease but not prevent the amount of technical debt. When the accrued debt starts to interfere with our ability to get stuff done or when we have a bit of down time, we go back and clean things up.
How do you approach coding for a framework or library differently than coding for an application?
The biggest difference between building an application and building a framework is that applications interface with people that (relatively) easily adjust to changes. If you move a button by a few pixels or change its color, people will most likely be able to use your application just as before. If you make a minor change to a frequently used api of a framework all the applications that use that api will stop working. This makes it much easier to iterate on an application compared to a framework.
Advice for someone interested in contributing to the project.
Start small and be persistent. We review lots of community contributions and only very few can be merged as is. Many people want to contribute to Angular and make big changes, but these are often the changes that get turned down. Not because they didn't originate in the core team, but because of how the change was implemented and how it integrates with the rest of code base. By starting small, for example with documentation changes and bug fixes, you get to learn about our testing, documentation and other requirements.
Top comments (1)
Hi,
I'm David, a Catalan Informatic Engineer.
My domain have a lot of examples and projects for Angular Developers davidmartinezros.com
Try it and have fun!