Ask HN: Starting a web project in 2015. What stack to use? | Hacker News Reader

Ask HN: Starting a web project in 2015. What stack to use?

39 pointsiagooar56 comments

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.

View on HN

I'm probably going to get downvoted for this, but whatever. This is a very easy decision.

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.

Counterpoint: the stack you choose initially will often follow you for years because switching costs are rising with every line of code and every developer on the payroll.

Personally I often go for a less familiar but more appropriate stack.

I agree. I'd also like to add that as long as architectural best practices are followed, the switching costs and risk can be minimised.

You can write bad code with a good stack, and you can write good code with a bad 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.

Absolutely, but for non-experimental stacks good practices are well understood and are easy to pick up, especially if you don't focus your career on the one true stack.

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.

That's a valid way to look at things, but I take a different approach. I try to avoid easy projects as much as I can with my preferred tech, because it forces me to grow as a developer. I have a relatively diverse skillset which I can grow outward or upward if I need to, but I also have deep knowledge of 2-3 technologies that really pay the bills.

This is correct in general, but there is some detail missing. I wouldn't call myself an experienced Python developer, but it's my most comfortable language so I'll use that to illustrate.

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...

At least you'd have the knowledge to make that decision intelligently and only have a few choices to make, rather than having the burden of learning an entirely new tech stack on the fly and likely make decisions that may not be the "right" way to do things with that stack.

The question usually is: Business or leisure? If it's for fun trying out something that's as different from the stack you're used to as possible (like Haskell or Lisp, for instance) will allow you to get the most out of the experience like learning new paradigms and gaining a different perspective on your favourite stack as well.

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.

This is a great way to think about the problem. Find the answer to what you are trying to deliver, and then that will define your constraints on which stack you can choose.

I think there can be a few avenues, each worthwhile:

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.

Meteor has been a disaster in production for a couple of projects I've seen, and for reasons that would apply to any meteor project.

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.

I thoroughly disagree with point 2.

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.

Thanks for the feedback! It sounds like you know the ecosystem more than I do, so it's good to get this point of view.

+1 Currently developing a Node.js / Express application. The choice of platform was a huge mistake. The brittleness of many of the libraries is indeed amazing.

First, I don't think that Rails (and similar) will become obsolete in a few years. Personally, if it's a serious project, I would go with the stack you know the best.

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/

+1 vote for Elixir.

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

Elixir seems like a great language, but its library story is still lacking a lot of things to make for a fast web development. This will probably change in the next couple years, however.

Think about the following factors when choosing a stack:

- 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

Since I started dabbling in recruiting, I've been doing rough tracking of job data for a number of technologies/stacks, broken down by region (LA, OC, and SV). When I checked outstanding jobs earlier this month, these were the rankings (most to least jobs):

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.

Considering all the bad mouthing that goes on, I'm surprised to see PHP at #1 in SV and LA.

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.

I should probably narrow the query a bit (I'm using a job board aggregator), but there are a number of startups built on PHP, most notably Facebook. Yahoo uses it in places, and don't forget all the companies who need a WordPress, Magento, Drupal, etc. developer. These technologies run multi-million dollar businesses. And after years of consulting, I can tell you business owners don't care what's under the hood if it solves their problem with good ROI.

Where you checked the outstanding jobs matters as well - something like Monster.com likely has a different group of companies using it that other sources.

Also, don't FB and Google (and other firms) mostly have their own recruiters?

I search job board aggregators and do my level best to filter out agency recruiters. I don't trust the exact job numbers, of course, but I trust the rankings because the deltas are large enough.

    <?php include("https://news.ycombinator.com/item?id=9009740"); ?>

Do you have any insights what languages have the best jobs to number of developers ratio?

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?)

Getting the ratio of developers to jobs is tricky. I could check LinkedIn or a resume database, but they lag a bit since most only update them before job hunting. Still, probably not a horrible metric.

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.

Why don't you try out Meteor? I found it really easy to work with. You could probably go through the whole book tutorial (discovermeteor.com) in 20 hours. If you don't end up using it on production; it might help you with faster prototyping.

I think it depends on what your goals are. So far I've built simple apps in Node.JS (Express, Sails, vanilla JS), Spring Boot (Java), Grails, Django, ASP.NET, PHP, Spring MVC (Java), Perl CGI, C++

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

Did you mean ASP.net MVC? MVC is great, and I'd recommend it if you want to go the Windows route, "legacy" ASP.net? Not so much. Razr puts the old rendering engine to shame, and MVC has received a lot more Microsoft and community love than ASP.net did.

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.

I don't see a typo, nor do I see mention of ASP.NET MVC anywhere. "Spring MVC" is an extremely popular web framework on the Java Virtual Machine: http://docs.spring.io/spring/docs/current/spring-framework-r...

I don't remember many specifics about that to be honest. When I built things in ASP.NET, it was for a Fortune 500 and the deployment environment was primarily windows, so I just remember using C# and remembered the name (ASP), as well as getting introduced to Scott Hanselman's blog, but that was about 4-ish years ago (2011).

> hiring is a factor to consider when choosing the stack

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.

Depends what you are doing and where you are going.

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.

Yeah but programming languages are an abstraction layer on top of already existing architectures which are not going away any time soon. X86, ARM, etc. So as long as code can talk to low level hardware and get executed, it doesn't really matter what you language you're using.

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).

Unless there are any unusual requirements, if I were starting a web project today I would use these technologies:

   - Angular/Bootstrap on the front end
   - Java/Spring Boot on the server
   - PostgreSQL on the data tier
   - deploy on AWS

All of these are distinctly conservative choices at this point, but using tried-and-true technologies has real advantages. They raise no red flags with bosses or prospective investors. They are well supported and will be for a long time. And it is easy to find knowledgeable people if you need to scale up staff.

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.

I would really hold off on Angular.

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!

Dead end? What makes you say that?

The fact that the very developers of Angular have stated that Angular 2.0 will not be backward-compatible with Angular 1.0, and the reason why Angular 2.0 is being made is because the operating assumptions of browser capabilities when Ng 1 was made have changed radically.

If I were in your shoes I would be reaching for Django/Flask (depending on how complex of an app I was making) for the backend and either server rendered pages or Ember.JS on the front end.

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.

Use RoR, it's not going anywhere.

I am going out on a limb and say for all things backend use C#. Mainly because in general the language, IDE, community support is by far the best. Yeah said it - and it's true so if you think Java or PHP or anything else is overall better your way wrong so fuck you. Oh and it's now open source and runs on Linux.

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.

C# + ASP.NET is great, but have you considered ServiceStack? It is not free, but I think it's a much better option than Web API for RESTful services.

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.

As a Django user, I have noticed a few comments on here and elsewhere where people have switched away from ASP and moved to Django, and seemed pleased with that choice.

http://kurtgrandis.com/blog/2010/02/24/python-django-vs-c-as...

I would ask myself "what in this project would rails fall short on? or what language has been known to do a better job, and don't think Ruby/Rails can do it?"

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.

If you're comfortable or want to learn a new stack, there are plenty to choose from.

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/

I had the privilege of meeting the Director of Technology of github the other week in Newcastle and he kept getting asked a similar question and his response every time was to use tried and tested tools, languages and frameworks. Not the latest flashy things.

From my experience use the things that have been around for a while and have a good community / documentation around them.

Depends on what the project is for.

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.

Look at Pylons Pyramid powered by Python, you can serve it with uWsgi and NginX. http://docs.pylonsproject.org/projects/pyramid/en/latest/

Use Rails as your API layer and pick a front end framework. That way you get to expand into a new stack while keeping one foot in Rails. I think in the rails community, Rails + Ember is a common combo, followed by Angular, though React has more momentum right now.

You can try

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.

There is no reason to use a NoSQL database on a new project (especially one as hideous as Mongo) unless the problem space is so domain-specific that it merits it.

Look at the job ads in your area. Take that into consideration when choosing your stack. If you're looking for an enterprise job I think Java would be a safe bet.

Depends on your requirements. For all the hate RoR gets it's still the fastest way to write a complex application no question.

Reply on news.ycombinator.com