

Ask HN: Pragmatic Web Framework for a Mobile Startup - bribri

What is the best choice of web framework for a startup where the primary responsibility will be serving RESTful json to native clients with real time components. In the future we may develop an SPA as well (but nothing super complicated). My top three choices so far are Node+Express, Ruby (Rails or Grape + ActiveRecord), or the Java Play! framework<p>My primary considerations are being able to easily hire for it, a strong ecosystem that won&#x27;t be past its prime in a few years,  have good code maintainability, and being reasonably fast to market. Performance is somewhat of an issue, but i&#x27;m comfortable using job queues and scaling horizontally with elastic beanstalk, which I feel mitigate some of the performance problems of the frameworks&#x2F;languages themselves<p>I love the large, growing, ecosystem of Node, the performance, and I like the idea the idea of eventually moving engineers between backend&#x2F;frontend, but I fear lack of code maintainability will slow us down in the long run. Loopback.io (built on express) seems like a good potential choice.<p>Ruby (I&#x27;ve been suggested Grape+ActiveRecord) seems to be the absolute fastest to market solution and offers pretty good maintainability, but I fear that the Rails ecosystem is waning and it may not be the best choice for websockets. Should I worry about Rails being eclipsed by node and losing relevancy over the next 3-5 years? Is the performance and real time support so much better in node that its worth it to take the code maintainability hit? Is the ecosystem and maturity of Rails alone make it worth it?<p>The Java Play! framework looks amazing due to its maintainability and performance (with web socket support). I think  detecting errors at compile time makes up for its extra verbosity. Is it not mainstream enough? Is it fast to develop in? Is it easy to hire Java web developers with web applications experience? How its its ecosystem vs rails for web apps?
======
jefflinwood
Why don't you take some time and do a quick and dirty prototype with all three
of those solutions, and see which ones you like working with?

I'd also say that you should probably be willing to take your first few
software developer hires into acconut - if you find the right developer, but
they are a Python/Flask developer, that doesn't mean you should rule them out.

