Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Today I accept that Rails is yesterday’s software

medium.com

Post reply on HN
Print view View original

51–60 of 166 posts

Re: Today I accept that Rails is yesterday’s software

#51

Post by icpmacdo »

elliotec wrote: post #36
scj wrote: post #32

Earlier quoted context omitted.

Wouldn't you rather be told upfront what a tool's flaws are before you invest years of effort into them? Even if you decide to embrace a tool despite flaws, isn't it best to recognize / minimize them? For example, C is a great tool. But heaven help someone if they ignore its' sharp edges. There is no silver bullet. So the best you can do is find something that suits you, and the task(s) you are trying to accomplish.

I completely agree with you. But when it comes to developing web apps rapidly, Rails is about as close a silver bullet as you can get. If your entire purpose is to ship a product quick, you should be ignoring the "too much magic, too many dependencies" narrative and building something, which Rails is wonderful at.

With Rails 5 just coming out now does it make sense to just start learning there. Is the material like the "Ruby on Rails Tutorial" book that uses 4.2 still worth reading or is it a large change, something like the python 2.7 to 3 where tutorials and reference material are largely dependent on the software version you use.

Re: Today I accept that Rails is yesterday’s software

#52

Post by disease »

zippergz wrote: post #21

Honest question. What technology are people enjoying on the server-side with sites built in React or Angular? I've seen some of these done with Rails, and some done with Node, neither of which I personally enjoy a whole lot. (Note, I'm not making an argument that either are BAD - just that I don't really like working with them). I'm curious to hear what other people are having success with in production.

Scala and c#. Great tooling, static typing, functional and OO paradigms covered, fast (Scala runs fast once complied), flexible with tons of existing code already out there to be used or learned from.

Re: Today I accept that Rails is yesterday’s software

#54

Post by tra3 »

calcsam wrote: post #5

Being "yesterday's software" is a necessary step. It's the final part of the Gartner hype cycle: maturity. https://speakerdeck.com/tehviking/surviving-the-framework-hy...

Here's the video: https://www.youtube.com/watch?v=0MojR1XUEc0

As an aside, how do people consume slide decks? It doesn't seem as interesting without the associated lecture...

Re: Today I accept that Rails is yesterday’s software

#55

Post by aaronwidd »

It's not Rails. Web software development in general has simply plateaued across the board.

We're out of new frontiers to innovate around and the work from now on is about playing custodian to the innovations of the past.

Unless something spectacularly interesting comes along, the priorities of the web are now all about supporting what's already been built. Either by maintaining something hastily built and cracking at the seams with patches and fresh coats of paint - or replacing it with something more stable for the long haul. Rails was designed around rapid innovation, not the long haul. So it's in maintenance mode.

Re: Today I accept that Rails is yesterday’s software

#56

Post by emodendroket »

zippergz wrote: post #21

Honest question. What technology are people enjoying on the server-side with sites built in React or Angular? I've seen some of these done with Rails, and some done with Node, neither of which I personally enjoy a whole lot. (Note, I'm not making an argument that either are BAD - just that I don't really like working with them). I'm curious to hear what other people are having success with in production.

I have no complaints about C# and Webapi. Well, "no complaints" isn't exactly right but I like it.

Re: Today I accept that Rails is yesterday’s software

#57

Post by hardwaresofton »

For those that are feeling fatigued from working with and around the magic of Rails, Sinatra is a great choice (in python land Django has an alternative called Flask).

http://www.sinatrarb.com/

That said, you will have to re-implement machinery that rails gave you for free. If you're building a simple API, there will be obvious simplicity benefits. If you're trying to build a server-side rendered web application, you may long for some things that rails provided (of course, you can use libraries and create simpler patterns than rails provided).

Note that going the sinatra+libs (or any "micro" framework for that matter) route places a higher burden on the development team when it comes to documentation. If you implement a scheme for server side templating/rendering outside of what is provided, you will be in a world of pain in a relatively short time if you do not maintain good documentation.

Re: Today I accept that Rails is yesterday’s software

#58

Post by spinlock »

zippergz wrote: post #21

Honest question. What technology are people enjoying on the server-side with sites built in React or Angular? I've seen some of these done with Rails, and some done with Node, neither of which I personally enjoy a whole lot. (Note, I'm not making an argument that either are BAD - just that I don't really like working with them). I'm curious to hear what other people are having success with in production.

Pheonix looks promising. It's basically Erlang on Rails.

Re: Today I accept that Rails is yesterday’s software

#59

Post by kazinator »

elcapitan wrote: post #16
vosper wrote: post #11

Earlier quoted context omitted.

> The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running I think this is where the lack of strict typing can make things harder to figure out. Especially if you're trying to understand middleware functions with opaque s…

But is that really a problem of non-strict typing, or rather a problem of metaprogramming? I could imagine even a very strongly typed system in Haskell or Scala would probably be hard for an IDE to support if it uses a lot of complex abstractions to create internal DSLs (like Rails and I guess Django as well do).

It sounds to me like a complaint about stupid metaprogramming. Every kind of programming can be done badly: there is stupid imperative, stupid OOP, stupid functional, stupid declarative, stupid pattern matching, stupid reactive, stupid aspect-oriented, ...

I'm not saying that Rails is stupid anything (I'm not familiar with it), but maybe that's the way it is in the blog author's view.

Here is an example of stupid: someone writes some class framework or whatever. It's open-source. Yet, the next someone wants to extend it---but instead of a proper source code patch, they implement some monkey patch which relies on mutating things in the original framework after it's loaded. Then the next someone after that does the same thing to the second someone's customizations, and so on. Then to find out what is being called you have to trace through to understand the side effects of several run-time patches.

Let's not dump dynamic because of stupid dynamic.

Re: Today I accept that Rails is yesterday’s software

#60

Post by carsonreinke »

askyourmother wrote: post #39
astrodust wrote: post #31

Earlier quoted context omitted.

That's a pretty shitty attitude to have. What framework is sufficiently irrelevant that Pragmatic Press or O'Reilly can't be bothered to write a book about it?

Actually O'Reilly published a good book on Rails in the early days 'enterprise rails', which was a very well written book. The pragprog web books seem to be a bell weather, the shiny web crowd flowed into Rails, node and soon probably phoenix. The early start and promise and phoenix will soon sink under the weight once hex packages bloat in number like the festering turds within ruby gems.

You are really pushing the turd argument [https://news.ycombinator.com/item?id=11661834]
Post reply on HN