Net Minds Tech Stack (Part 1)
by Alan Baker
The world of application development changes rapidly. If there’s one thing I’ve learned it’s that there’s never just one way to solve a problem.
Take technology and programming: non-programmers don’t usually understand this, but programming has soul. Application design has so many possibilities; even programming simple functions can be done in many ways depending on the personality of the programmer. Just as in art and writing, we transfer our philosophy and personality into the code we write.
Programmers and application designers have the added challenge in that code can do nearly anything; it just comes down to time and money. And making it easier but also harder is the amount of choices we have to write applications, including the massively growing choice in technology.
I want to look at the choices we’ve made at Net Minds and why. I’m breaking this post up into parts so it’s more manageable to read, so for this post, I’m covering the core language we’ve chosen to develop in. Later, I’ll cover our API, database, and front-end.
Just to get it out of the way, we’re a JavaScript shop, from front-end to back-end. This decision was relatively easy.
First, JavaScript is absolutely ubiquitous. JavaScript is the language of the browser, and it controls everything interactive to provide the kind of experience customers expect in a modern web application. This was important for us because we wanted to design our application around the user experience and we felt that the browser as our platform is a legitimate choice, albeit a controversial one.
And then there’s the huge uptick in developer activity in the JavaScript world – compared to other languages we’ve all used, it’s much more expressive to develop with and a lot of fun… yes, fun.
When you look at the activity on GitHub above, which did surprise us, you really can see the excitement surrounding the language. All this activity shows there are fast cycles of continual improvements and tons of examples of different ways of programming.
Where I get excited in the overall application design, we have less likelihood of investing gobs of time and resources into eventually-abandoned codebases.
JavaScript had everything we needed. Not only that, but all the Net Minds developers know JavaScript very well vs. only two of us who know PHP very well. While PHP has been good to the two of us, the math seemed clear.
This isn’t to say that this is the end all be all for everyone, but for our use case, this logic and our development needs fit perfectly. As we’ve been developing, we are finding that our logic is cleaner; we have a better ability to mix asynchronous and synchronous actions without crazy nested loops and callback hell. So we’re clear, I’m not saying that JavaScript actually solves this particular problem, but we’re better able to see it and manage it.
But most importantly, we’re able to iterate our application design and feature list with far less pain. We’re able to maintain consistent logic and portable code from the front-end to the back-end because we have one unifying language.
For me, this is extremely critical. I think a lot of our user experience and assumptions are really very solid, but like anyone, we’re not perfect and we won’t always be right. But being right all the time isn’t important, instead what is important is to recognize when you’re wrong and quickly iterate.
For our team, JavaScript allows us to do just that. Not bad for a language that was originally written in ten days; not to mention the impressive pace at which improvements to the language are happening. The future just looks extremely bright for JavaScript, especially when you look at the draft proposal for ECMAScript 6.
Well, that’s all for now. Stay tuned for part two when we discuss our front-end, Ember.js.
Source: netminds.com
