Hacker News Reader

Comment by faizshah | Hacker News Reader

Yea it's really sad that at the hackathons I've been to you can hardly find one other rails developer. With rails you can build things fast and spend more time focusing on building cool unique features. But I go to hackathons and I can't collaborate with anyone using Rails or Ember.

Also google cloud has a ton of awesome integrations for ruby and rails so you can build lots of fancy features quickly as well.

The rails community needs to do more outreach to universities and students.

View on HN

Ten years ago, you'd find plenty of people using Rails at hackathons—back when it was the new hotness. Maybe hackathons tend attract people who are interested in building stuff with 'cool' technologies as opposed to building cool stuff.

We've had so many generations of Web frameworks, but presumably it's still not a solved problem, because we keep moving to new ones.

Of course, sometimes the latest thing has a useful mix of properties that is worth the move. Though many hottest ones turn out to be popular only for a year or so, and then people lose interest.

I wonder how much a factor in the churn is the individual engineer desire to have the newest framework keywords on our resume, even when we can tell it's mostly a gratuitous rehash, because a lot of hiring is for keywords.

Or maybe more often we're looking for the new tools to provide additional advantage for projects (not resumes), but it's difficult to assess the holistic net payout until we've invested heavily in it for a year, whereupon we repeat with the next tools that seem to promise advantage.

I'm all about trying new tools all the time, especially as little side/toy projects, but it's odd that we are often betting important projects on less-proven new tools, when you'd think by now we'd have figured out and proven tools that would be hard to beat. (And I say this as a fan of certain tools that aren't proven enough, but which I wish a few startups would use for getting to demo/launch, so I can humbly see one way this happens.)

If the average tenure at a company is less than two years, then why not bet your project on the new, hot technology? You get to put it on your resume, excite potential future colleagues with your buzzword compliance, and never have to worry about maintaining a project long term.

Good point. The current short-timer employee conventions (as well as startups that can just be serial-entrepreneur'd if they fizzle) might remove some of the traditional incentives to use proven methods (to manage near-term risk, and to build for long-term maintainability/growth).

> We've had so many generations of Web frameworks, but presumably it's still not a solved problem, because we keep moving to new ones

I do not think that it is not a solved problem. I think, in most cases, there is a propensity to wanting to believe it is not a solved problem, because building things from nothing is a lot of fun.

The cool thing about being a software engineer is that you can go back as far as 0 and 1 with comparably reasonable effort and tools that are at your disposal, for free. You get to build anything you want, exactly as you want. Of course mostly it will not go back as far as machine code, but hey look, there is a new js front-end framework.

And sure, in parts this is all part of the learning experience. But I the amount of productivity that has been lost and will be lost due to the technology being reinvented (or shall I say: rediscovered), has to be absolutely mind boggling.

We all like to play, but engineers are pretty fucking expensive and the number of web applications that could absolutely not have been build in good old Rails or PHP by people who know their tools inside out is probably approaching the low zeros.

I've been a mentor at a hackathon a few months ago. 90% of the participants were on their twenties. The chances they know Rails are lower than for the same demographic ten years ago.

Interesting. What server side tech stacks are often used by young developers in the recent hackathon? Are there a few dominant ones or many choices?

I'll second that question. I figured Rails would still be pretty popular, and now I'm wondering to what degree that is or isn't true these days.

My guess would be React/Angular or, if it's a particularly hip group, Next.js/Nuxt.js/Serverless with as little back-end as possible.

In my experience Angular is out and React is in with some vue people around as well.

For backend, graphql is in, expressjs is still in, firebase is in, flask and django are in.

Ruby on rails is unfortunately out among my peers: https://devpost.com/software/built-with/ruby-on-rails

Not a bad idea to do a blog post analyzing devpost trends, I might do that after exams.

React, vue, firebase, express, flask and django at mine.

and possibly just 'younger' folks who've only ever known or worked with whatever came out in the last 1-3 years?

the older people get, the less time and interest they're going to have in spending a long weekend with random people trying to work on something collaboratively.

i've done a few - my team (of 3) came in second place (against a team of 16!) with around 20 teams in total. Good feeling, but nothing ever came of it - protip, learn if your team members are actually at liberty to work on the project after that weekend. Mine were both barred from pursuing the project in any meaningful way (work visa for non-citizen, and non-compete with existing employer for the other).

Did a followup hackathon later - all teams seemed to self-organize before the event, which wasn't promoted/explained beforehand (but apparently about 80% of the people 'knew' already). Left with working with random people who didn't understand the idea that '48 hours' mean 'consecutive' hours. Two hours into the project, my one partner said "hey, i gotta leave to pick up my kids - i'll be back tomorrow around noon for a few hours"... and then left.

That was also my first taste of 'sponsored' hackathon - you had to use one of 4 sponsor-supplied APIs to qualify for anything.

Agreed that more hackathon participants should know Rails. Although I will say that 50% of hackathon backends are unnecessary as nobody will check if you're actually persisting data/doing user accounts. And the other 49% would be perfectly fine with Firebase. But for those 1% cases where you need a CRUD API stat, Rails is absolutely unbeatable.

100% agree, at hackathons I start off by telling my team that the backend doesn't really matter we should just focus on a good interactive demo at the end (which is usually met with major eye-rolls).

The only thing is that with Rails you can build the backend so fast and simply that it can be better to just use Rails if your team knows Rails.

But my new thing is onboarding teammates who know React or Vue into Ember quickly then using Emberfire to build SPAs fast. Then we use cloud functions and firebase to take care of everything else.

Reply on news.ycombinator.com