Live data from Hacker News

Existential crisis at Railsconf

railsbird.tumblr.com

31–40 of 168 posts

Re: Existential crisis at Railsconf

#31
post #21

> Unfortunately, we don’t have better options in Ruby for working with websockets. We do! Celluloid (the actor model) is vastly superior to EventMachine in my opinion. It fits much better to Ruby's OOP style and I suspect would integrate into Rails very cleanly. I am positive that bringing any EventMachine technology into the Rails stack would be a mistake. I am saying that with a bit of a bias as I have written my o…

Do you have experience with https://github.com/ngauthier/tubesock? In a very small project of mine I used https://github.com/minoritea/sinatra-hijacker which I found very nice to program with.

Re: Existential crisis at Railsconf

#32

In web framework terms, Rails is old. When it was created single-page applications weren't on anyone's radar, APIs were extremely uncommon, and websockets hadn't been invented. It's natural to expect some pain try to adapt new paradigms into the old model. Whether this pain is worth it is up to the individual to decide. My web applications are almost always pure client-side these days, so Rails is not something I oft…

Re "In web framework terms, Rails is old" Oh how I love that! I would rather build my business on something old and well testet then something new and shiny.

would you move to java? that's older and even less shiny.

Re: Existential crisis at Railsconf

#33
post #16

Websockets isn't really HTTP and so it doesn't really conform to the request/response model in HTTP that is centered around retrieving document objects. Most web service implementations, including Rails, are built around that paradigm - they get a request for a document, they return it, then they can forget about it (stateless) and move on to serving subsequent document requests, which are likely to be entirely unrel…

You don't need to go as far as websocket to leave the stateless world: Server-Sent Events and all its cousings (Comet, chunked transfer encoding, even long polling ...) all need to keep a connection open for an unknown amount of time and then send data back to the client. Is Rails discouraged for such use cases ?

If you could run Rails in an event-driven webserver, it might be usable with persistent connections. Otherwise you'll need a whole lotta memory for all those workers that'll be sitting around doing nothing most of the time.

Re: Existential crisis at Railsconf

#34

In web framework terms, Rails is old. When it was created single-page applications weren't on anyone's radar, APIs were extremely uncommon, and websockets hadn't been invented. It's natural to expect some pain try to adapt new paradigms into the old model. Whether this pain is worth it is up to the individual to decide. My web applications are almost always pure client-side these days, so Rails is not something I oft…

Re "In web framework terms, Rails is old" Oh how I love that! I would rather build my business on something old and well testet then something new and shiny.

This. We didn't feel comfortable moving my company to Rails until it hit version 3. Maturity is a good thing.

Re: Existential crisis at Railsconf

#35
post #3

No, Rails isn't great for web socket kinds of things, but if it were me, I'd just use something else for that, and Rails for the main site. It's still one of the best things out there for quickly iterating, and yet still maintaining some structure and discipline, from what I've seen.

You could also use hosted solutions such as Pusher, Pubnub or Fanout which plays really well with frameworks

Re: Existential crisis at Railsconf

#36
Is this just a really polite, introspective take on (Rails|Ruby) is a Ghetto? I can't point out one really valid critique in this entire rant. While I imagine that you've had enough kool-aid to actually believe the things you said, I think you should probably do a few google searches to find out how many shops are hiring Rails devs versus Clojure or Elixir. You can do more experimenting by seeing who else is actually working those jobs, what kind of professional experience they have, and if you're really lucky figure out what they get paid.

Rails needs websockets, just like years ago when it needed a better way to handle organizing and deploying assets. The modern application demands it, and if you've ever had the pleasure of trying to build a websocket application in Ruby you'd understand why it's actually really exciting that we're going to get the Rails community to build this for all of us.

If you want to be disenchanted about some aspect of Rails then pick the fact that the need for diversity at RailsConf this year has yielded some of the worst presentations I've ever seen (like, literally, the presenter spoke poor/broken english and the Docker oriented talks were about 6 months behind).

Rails moves the way it does and absorbs the ideas it does because they become popular. It's much easier to add a feature that everyone wants, instead of inventing a feature that makes a solved problem that much easier/faster/what-have-you. DHH seems to have to explain this every few years, but go back in time when Rails adopted sprockets and you'll see posts not unlike the one you just wrote.

Realistically, Ruby and Rails jobs are still among the highest paying in the industry. Startups and other more established companies still choose Rails as their platform, and not just for bullshit brochure sites. Certainly there remains a "best tool for the job" mentality but, right now, the alternatives are to: build it yourself, hop on a less "mature" framework -- Pheonix? I don't even know what you pick when you adopt Elixir as your platform language and need to build an API or front end apps but Pheonix won the google -- or choose from one of the popular technologies like Express.js, Laravel(?), or Django. That part of building technology (and business) didn't change, and there are still hundreds of thousands of Ruby and Rails engineers out there.

Re: Existential crisis at Railsconf

#37

Rails was always crappy, it just took you a while to realise what we already knew. A framework so full of security fails it made PHP look secure. My main concern though is all the rails rats jumping ship and sinking the promising good ship phoenix and elixir.

I love it when debate gets reduced to someone creating a troll account ( 'railsbadruby' account is 48 min old as I write this ) and badmouthing.

Is this what HN discourse has come to?

Re: Existential crisis at Railsconf

#38
The Rails team, including DHH, owes us nothing. They aren't required to give us a framework of our choosing, they're the ones building it! Just like we don't owe anything to Rails!

DHH uses Rails for Basecamp, so it makes sense that he'll lead the project towards the goals of BC.

Re: Existential crisis at Railsconf

#39
To those unsure about Eventmachine

https://github.com/eventmachine/eventmachine/blob/master/CHA...

IT seems to have much more fix and features in recent months then its entire life span.

And as DHH pointed out on twitter

Clearing up misconception re: Action Cable: EventMachine only used for connection handling, threads for channel code. No block restrictions.

Re: Existential crisis at Railsconf

#40
I understand that there's not quite the same consistent 'theme' this year, but I'm not sure that's concordant with developers who are using Rails 'abandoning' it or anything like that.

It's true that real-time operations like websockets are a total pain in the arse with Rails. Nobody's yet figured out an optimal solution for that sort of thing, and maybe ActionCable is a good solution.

The thing is that while some demands on the web stack have changed, a lot of it is still pretty similar. We have HTTP requests, and HTML, and assets, and databases. It might turn out that Rails can also perform some other tasks that require realtime operation. Or maybe it won't be able to, and we'll be able to use some other tools.

Ultimately, we're still using Rails for all of our new web apps. We've tried loads of different toolsets, but haven't found an alternative that's compelling enough to bother. So YMMV, but the fact that Rails is maybe a bit less exciting that newer frameworks doesn't mean it's not great to use any more.

Post reply on HN