Ask HN: Starting a web project in 2015. What stack to use?
I know these kinds of questions might sound silly to ask, but I really love the diversity of opinions that HN provides and the discussions
To give a bit of context: I am an experienced Ruby on Rails engineer. I really enjoy doing RoR and feel more than comfortable using it.
In the next weeks, I'll be starting a web project (mostly a web app, with some public facing pages, imagine a typical SaaS application). There will be some APIs, an on-premise version might also make it into the roadmap.
The logical and pragmatic choice would be to go with Ruby on Rails but I don't want to get stuck forever with a stack that might become obsolete in the coming years (or not). Also, I live in an area where getting good engineers is VERY difficult and hiring is a factor to consider when choosing the stack.
57 comments
[ 3.2 ms ] story [ 118 ms ] thread- How mature is it ? Is it a latest new cool thing or does it have a proven track record?
- What is the purpose of your project ? Is it just to learn new things or you actually building a real world busines ? How quickly can you time to market ? This is critical.
- What kind of support ecosystem exists for this stack ? Can you easily debug, ask other people and get answers quickly ?
I don't think RoR will become obsolete in the world of web in the next few years. If you really love it as you say, then go use it specially if you are building something important to do as a business. But by all means go try something new if you want to learn or try as a hobby.
while we are discussing, some of the stuff that I have come across while building a web project in 2015:
### Front End
Angular, React, Meteor, Knockout and of course Jquery.
### Back End
Laravel/Lumen (for php), Django/Flask (Python), Rails/Sinatra (Ruby), Nodejs
As this is for business I'd say stick to what you know. Creating a useful software product that can be marketed successfully is difficult enough as it is. There's no need to complicate the process any further.
Regarding hiring: First things first. You won't hire people in the beginning anyway I suppose. So, that's a problem you should consider later on. Besides, development lends itself to working remotely so area isn't really an issue anyway.
If you want to quickly build a web project, hire some engineers, charge for your service - why not build it in RoR? This will save you time troubleshooting and learning the ropes of a new web development framework.
Also, you could always hire remote workers if it is difficult to hire locally. See: https://weworkremotely.com/
1. Use Rails as a back-end only and commit to a front-end stack like Angular or React+Flux. Rails will continue to be viable for a long time, but even longer as just an easy API server.
2. If you don't know the Node ecosystem, it might be time to dive in. I haven't really enjoyed Express.js, the Sinatra-esque framework for Node, but it can be a good excuse to learn NoSQL db's (though you can use them in Rails as you know) and just increase JS chops. Also if you hire a front-end dev I think it's a tad more likely they'll know Node than Rails.
3. If this is really just to learn, I'd suggest trying other languages, Clojure seems like a great mix of mind-expanding programming along with web ready usage.
4. Meteor.js is a project I'm really interested in. It's 'Rails but for Javascript'. They have funding to stick around for a while, and they have a vision of pushing the web away from stateless API's to an always connected client. This is my answer of what I'd start a new web app in if I had to begin one today.
Basically, atmosphere is pretty but the packages are outdated, broken, or both; the only solution to this is to roll your own packages for every library you use.
WRT NoSQL, very few people need the performance benefit(for specific types of applications, specifically ones with non-relational data) of a document or pure KV store; whereas many can benefit from good old tables and joins. Though SQL as a language in my opinion is not pretty: the utility of SQL databases(my favourite being Postgres) is undeniable.
I've seen POs choose MongoDB because it's "webscale"(believe me when I say we don't need it), and often enough we end up with a situation where with joins our queries would be trivial, but with MongoDB, the queries are often only feasible at all with aggressive denormalization. Such denormalization is typically error prone, complex, and slow to insert.
Node itself is pretty spectacular, if for nothing but the ease with which you can take a synchronous single-node system, and factor it into a distributed system. In most environments this is infeasibly difficult, Rails seems to me like one such environment.
Clojure is an interesting and pragmatic language with a whole lot of cutting-edge work in datastructures having leading implementations there. LISPs also have inherent magical powers which I'm sure you've heard explained ad nauseam by a little-known chap called Paul Graham or something, maybe his website Hacker News is written in one.
Having tracked the development of the Node ecosystem since its beginning, the amount of unstable libraries and endless churn continues to amaze me, and the tooling solutions still seem very immature for what should be a "serious" development platform.
Honestly, for 99% of things a plain old Rails or Django stack will be fine. Development will be rapid, the devs behind both frameworks seem to care about stability while keeping options open to making your own thing, and you have access to both language's more ample library story, which goes beyond simply making web pages.
If it's just about the concurrency story, there's async frameworks on Ruby and Python. If it's about the performance, V8 eventually ends up hitting the same walls the other languages do, albeit much slower, but with a whole bunch of language and library deficits that are best avoided altogether.
It's amazing to say it, but nowadays even the current story with some PHP frameworks is not bad, ever since some people decided to standardize more parts of their packages and make the language actually suck less.
The perspective I've come away with is.....MVC is MVC. So far I haven't seen anything from any of these frameworks that is completely different when building a webapp (they're of course different when you're building different types of applications, such as Batch, Three Tier, etc).
I found myself worrying about the same things (Input Validation, internal state, database management, Object mapping to the database, and Output serialization) in each case. The optimal choices depended heavily on the characteristics of the input domain and the problem domain.
Meaning, for a simple CRUD app, I'd probably use Rails (mainly for their scaffolding), for something that was more event based (like transactions/financial), I'd probably use Java/Spring, for something that was more system level or batch, I'd probably use C/C++ or Perl depending on how numerical/stringy the data is. I'd probably use PHP if I didn't want a bunch of startup time (i.e. if I just wanted to prototype something really quickly), ASP.NET if it was going to be Windows.
After picking up a couple of these, I stopped thinking about the solution in terms of the language, but more in terms of the Paradigm.
Sorry I couldn't be of more help
But I'm pretty sure it was a typo anyway since you talk about MVC (in general) in the very next paragraph, so I assume you were listing off a lot of MVC frameworks including ASP.net MVC.
Is it a personal hobby project? Then maybe it is a chance to try a new stack. I'd recommend something with a more statically typed language than Ruby so you can get some experience in that. Java and C# are your mild choices. Haskell would be more hardcore.
If it is for money or there is a deadline then stick to what you know.
Now, if you're willing to learn something new, I would recommend that you try Phoenix http://phoenixframework.org/. It similar to Rails in structure, and Elixir (built on top of Erlang VM) is also similar to Ruby (syntax-wise).
Some helpful resources:
https://github.com/h4cc/awesome-elixir
http://elixirsips.com/
I am learning it at the moment. Enjoyed the Ruby (syntax) with some functional programming capability, but the biggest selling point for me was the fact that it runs on the Erlang VM.
PS. Don't forget: http://exercism.io/languages/elixir
SV: PHP, Java EE, Node.js, RoR, Spring/Hibernate, C#/.NET, Python/Django, Scala/Play, Groovy/Grails
LA: PHP, C#/.NET, Java EE, RoR, Spring/Hibernate, Node.js, Python/Django, Scala/Play, Groovy/Grails
OC: C#/.NET, PHP, Java EE, Spring/Hibernate, Node.js, RoR, Groovy/Grails, Python/Django, Scala/Play
And numbers show that SV has 4-5x jobs of LA, which has 2x jobs of OC. This is all to say that research is critical if you're choosing a technology based on getting a job locally.
Just proves that you need to ignore the haters and go with the language that works for you/your situation.
*have used PHP for the last 7 years but now switching over to Python/Flask.
Also, don't FB and Google (and other firms) mostly have their own recruiters?
I always see lots of Java or PHP jobs, but I know there are tons of devs in those languages as well.
(And what / where is OC? I assume SV is Silicon Valley, LA - is Los Angles, is that a tech hub in the US?)
Another metric is salary. Also imperfect data, but right now the stand out is Java/Spring/Hibernate. Not too surprising as an "enterprise" technology, and probably also includes more people with degrees than frequently self-taught language like (say) PHP.
It's important to note that it's not the technology that gets you the job, but how well you stand out from the other candidates.
Sorry, it's California-centric since I'm in LA; OC is Orange County, one county south. OC is not a tech hub, per se, but has a lot of industry, and is home to Blizzard, Oculus, and a number billion dollar companies that naturally write a lot of software. If you were asking if LA is a tech hub, I'll say yes. It's growing, and Southern California graduates more engineers than any other metro area in the US, so it's attracting more tech companies. Google has offices in LA and OC, and just bought 12 acres for a new campus.
If you're an experienced Rails developer, use Rails.
If you're an experienced Perl developer, use Perl.
If you're an experienced PHP developer, use PHP.
etc.
The tools don't matter so much. Your experience level with them does. Don't use something you're unfamiliar with in production just for the sake of using the new hotness. That's dumb.
That's not to say, of course, that you should never use anything new. Learn new things, and learn often. Play with new technologies and languages on your own time and get some proficiency with them before using them for a client in a production setting.
Personally I often go for a less familiar but more appropriate stack.
Put another way, a pro football player will be pretty good with whatever he uses, but even if I had the exact same gear, I'd never get picked for even a high school team.
It's about the person, not the tools.
For 99% of the projects you don't need to know any stack at level 80. You're much better off having a more diverse experience. Most skills beyond intermediate level – defensive coding, good architecture, managing complexity, etc. – translate very well to other stacks.
1) I'm comfortable with Python, and have some understanding of web frameworks. Should I use Django or Flask or Pyramid? Which ones have a shallower on-ramp, or will help me make my project more modular?
2) It's 2015, should all web apps consist of a clean RESTful API, decoupled from the front-end? Or is it OK to have all server-rendered pages?
3) If I should separated as per point (2), then does that mean I should stick to a lighter web framework, instead of using Django+DRF to provide the API? How should I build the front-end? Backbone? React?
4) If I don't separate front and back-end, what do I do about the little things that need some Ajax magic? Just write some 'onlick=...' stuff in my templates? Or should I be keeping my JS modular and using gulp or something to collect stuff up?
Even if the answers is 'just use Django' or 'just use Rails', there are lots of specific things to decide, and it's annoying to have to do so. If I were a Ruby expert starting a web app tomorrow, at a minimum I'd have to decide between Rails and Sinatra, and between rbenv and RVM...
Personally I would not let hiring determine what stack you use. In the end if it gets the job done, is tested, commented, and can be proudly passed on to other engineers, then it is suitable.
One more thing I found with 'stacks' is they are not as solid as they seem, and can be swapped out with other ones, but only as needed. It is common to switch between multiple stacks throught the day. "Doing everything one step at a time, in parallel" as they say.
A friend of mine had a startup company a couple of years ago. He chose the language - Python, next choice was Java, and next was C I think (to me the differences his choice of languages shows a lack of understanding in the trade offs between each). As he was non technical, I assume he just listened to other bioinformaticans telling him what was great.
Anyway, he got a product produced (Python and Django / JavaScript front end) and had the option of a German grant to keep the project going. The amount of money offered was fine for someone out of University, but wasn't enough for an experienced dev.
Anyway, despite using a solid choice of language / framework, he couldn't find a dev to continue the project. My guess is that if he had chosen PHP, he the project would have continued.
I can understand the need to have others pick up from where you left off, but that's introducing politics into programming, and more oft than not, it confuses what you're trying to achieve (which is converting some form of input to output I hope)
As a first port of call, it would be preferable to know one low level language like C, and a scripting / CRUD language like PHP/JS, as a lot of application development now is web based. Bonus points for learning ASM as that's as low level as we can get. (Unless you work in an Intel chip facility and are not allowed tell people what you're working on).
Unfortunately its not a as cool as ROR, LAMP etc. It's simply better, more mature more stable, quicker etc.
There is a major subtle war going on where asp.net mvc and c# are just not included in the start up tech stack discussions which is ridiculous. asp mvc has the best Web API infrastructure supporting RESTful / hypermedia API's. It has amazing WebSockets support. I could go on but who is even reading this far? Perhaps just me.
However, that being said, I still prefer the JVM ecosystem over .NET. You're simply spoiled for choice.
I've been working on a Scala (Play! Framework) web app and I thoroughly enjoy the flexibility of the Scala language.
http://kurtgrandis.com/blog/2010/02/24/python-django-vs-c-as...
Since you are a Rails guy, you might want to substitute Rails for Spring Boot. It's a respected system, and you already know it. Win.
If I had the latitude to take one risk in choosing the tech stack, I would swap out the Java/Spring Boot for Haskell/Yesod, since I grow increasingly frustrated with Java's verbosity. But this choice definitely has downsides: I know Java _much_ better than Haskell, and Haskell is rare enough that if I needed more than a couple of developers, I'd need to either hire them remotely or develop them from scratch.
Similarly, you might want to take a chance on one off-beat component if it catches your eye. But just one.
The development path of that project seems to indicate a dead end. And as far as technologies go for a new project that's supposed to start quickly, it has some tremendously complex abstractions while having issues with debugging.
This is all a pet peeve of mine, but I think the kind of two-way data binding that Angular proposes will be seen in the long run as a mistake. The fact that you can't just understand what's going on behind the hood without reading tons of documentation in the middle is very troublesome.
I'd run away from Angular, into Ember-land!
Bootstrap and Reactjs for the frontend. And for the backend - express and node. For database try nosql like mongodb.
It will be altogether a different stack from what you are working now. But it will be a good learning experience.
YMMV of course but you get a lot out of the box with Django and if you don't need everything Django comes with (A user system, A large ORM, authentication etc) Flask is a more lightweight solution that can be extended pretty easily. There is a large community for both and any Python dev will know at least one of them at least fairly well.
That being, the main reason I would go with that stack is because that is what I know. If you are doing something that entail some "real time"-iness or push notifications that's not really one of Python's strong points. So ultimately you should choose the best tool for the job. The "best" tool should be a workable combination of what you are able to use easily and will get what you want done without having to write a ton of supporting code.
TL;DR: Choose the best tool. The best tool will be something you can already use or learn in a fairly easy manner and also lends itself well to the task you are trying to accomplish.
From my experience use the things that have been around for a while and have a good community / documentation around them.
If there’s nothing compelling you to use something else, its up to you. but if you see something that Language Y could do over language X for this project, then that might be the indicator of which way to go.
I do PHP work, currently I don’t feel I'm limited with the tools I've chosen for what I have in mind. If I did I'd certainly look to see where I've heard there is more opportunity.
If you have the opportunity, pick the tools that would work for you and learn how to use them well.