Rails is slow

Hack academy graduates are using Rails, devaluing it for senior engineers and diminishing its future prospects

A startup should use what a prospective engineer will want to hack on in the future and future proof their application

At Scribd, they've made the transition from Prototype, to jQuery, to Coffescript, to Angular, to React over the last few years

"Modern" Web Development

Choosing Tools

Debates about the best current frameworks or programming languages regularly happen in web development. In this vein, Jared Friedman, the co-founder of Scribd, wrote a post recommending Node.js over Rails for anyone starting a new company in 2015.He makes a few key points:Node is a great choice for startups, but two parts of his broader critique worry me. First, that a startup engineer should understand what technology will be popular in a few years and future-prooftheir stack. Second, that great software engineers will be attracted to a startup by the modern stack, rather than interesting technical problems. In the past, I've heard more pernicious forms of this from the startup developer who refused to take a job where ES5 Javascript was written (CoffeeScript had recently come out), to the engineer bent on ripping out Postgres for Mongo in production soon after Mongo was released,to the desire to continuously refactor into the latest frontend framework.I worry that some programmers (and their employers) have this attitude, namely a focus on transitioning stacks to the newest. They pick companies primarily based on the framework, aiming for the latest instead of the best tool for the job. They spend their time playing with new libraries and frameworks, instead of improving their core technical skills. Let's call them- those pushing for new technologies (or their own favorite technologies) in a startup's stack, with limited advantages for key outputs (software capabilities that users value, development team productivity).Pity the modern web or mobile app developer on Hacker News . As a full stack startup developer in 2012, you were building websites using Ruby/Rails on the backend, Backbone/Coffeescript/Underscore on the frontend, while deploying your app with Capistrano (or the relevant Python analog). By 2013, you'd transitioned to Node/Express/Mongo on the backend, Grunt/Ember on the frontend. In 2014, you'd switched whole hog over to the MEAN stack (now with promises), but experimented with Koa and considered a shift to Go (after the Express core contributor made the jump ). In 2015, you're using Gulp/ES2015/React on the front end, Express/Go on the backend, React Native over the native mobile languages, and slowly transitioning your system over to microservices with Docker. Soon, you'll be transitioning to Phoenix, figuring out if Angular 2 is the right choice - and maybe even plotting a world where Go can work on Android and where an open sourced Swift might fit into your stack. (I’m clearly exaggerating for effect, though this is a fair representation of what is popular in HN headlines)There are several reasons this can be rational. The modern web engineer is required be “current" to get a future job or contract; employers use a framework or language as a filter, rather than testing critical thinking and skills. Employers don't realize that strong developers can become experts in many languages or frameworks in weeks, often days, with the right support. Sometimes the writing is on the wall: Swift is replacing Objective C, the world is moving to thinner, less monolithic backends and heavier, more responsive frontends. And often times, there are huge advantages to a switch: productivity goes up substantially or new user features are suddenly possible. And yet, all changes are not do or die for an early to mid stage company, and learning something for fun or a side project is a far cry from arguing that it's critical for production.It's illustrative to compare a modern web or mobile developer in a startup to our other computer science brethren. A friend is a computational neuroscientist at a top tech firm - and like almost all people working in technology, his world has been reshaped every few months - with rapid advances in computing power, brain imaging, and deep learning algorithms. The basic programming tools have changed little though. To be fair, there was one C++ 11 to 14 transition which caused some angst. There are also distributed computation systems, key/value stores and other external services, but these are built with stable APIs. Most of his time is spent with architecture and algorithms in a single DSL, rather than rewriting functionally similar code or learning libraries that provide debatable benefits and change quickly.People may suggest that choosing a modern stack is a critical recruiting tool for great startup engineers.My own observation is that the greats look for other things. By far, the most important are interesting problems to work on - and interesting people to work with them on. Traction and a powerful mission are additional ways to attract great people (engineers or otherwise).This is hardly curmudgeonly whining on my part to say that tech moves too fast, and that we should all be writing in Assembly or C++ or Ruby. Software engineers know what they sign up for - our field moves at a dizzying pace, and it's all worth it for both the impact we can have as a billion people come online. I'll argue that you need the ability to pick up a new framework, language, or library lightning fast (an Ask HN on how to do this) - and with experienced engineers around you, you should aim to be productive quickly (days or weeks). Beyond that, you should typically have deep comfort with a diversity of languages, not simply one (but this same attitude, shouldn't be blindly extended to frameworks or lightweight DSLs).For startups, PG was asked in 2013 about ideal languages : "I mean, we have had startups writing their code in PHP – and that worries me a little bit. But not as much as other things worry me." Sam Lambert, Github’s Directory of Technology, in a recent interview speaks about his surprise at how much Github's stack is Rails, C, and Bash scripts when he initially interviewed with Github's CTO in 2013: "Then as the interview process went along, it was more revealed to me that this is actually a really pragmatic set of hackers that just hack on Ruby, hack on C and spend their time working on more interesting things using a more stable stack, rather than chasing after the latest and shiny tech." Github's approach strikes me as the right balance for web and mobile engineers (startup and otherwise): explore tools widely, but then pragmatically choose the tools that solve the problems you face ( YAGNI applies in a lot more places than just user facing feature development).What worries me is that certain developers, especially developers early in their career, may get the idea that a startup engineer is not a problem solver or computer scientist, but a glorified look up table - every few months their task is to memorize a new DSL - to get limitedbenefits. This devalues who we are as early stage engineers - building things that people want, working on interesting technical problems, and shipping code rapidly.By all means, experiment widely in your extra time. Switch out languages/frameworks in production if the benefits are overwhelming, but think about what the benefits are. Be critical of people who are cheerleaders for the new, without being thoughtful about the expected advantages for your team. Spend your time learning concepts and solving interesting technical or user problems. And if you have the right application boundaries and choose the framework you're productive in for now, you'll have some flexibility if your about tech choice,but persistent enough to get to product market fit and beyond.Open Hacker News on any given day, and there'll be posts beckoning you to contribute and build applications in a framework, language, library, or service of choice (including some companies like Mongo with serious cash, and therefore marketing budgets, behind their platforms). Some will have game changing capabilities, others a few critical differentiating features. But each will require timeto become an expert. Some will loudly proclaim how they're the future, and look derisively at what you've learnt - but they'll need your skills and mindshare to truly compete with existing technologies. How will you choose?