After reading “Rails is yesterday’s software”, I need to reply • Hacker News Board

Re: After reading “Rails is yesterday’s software”, I need to reply

#171

Post by lobster_johnson » Wed, May 11, 2016, 6:07 PM UTC

throwanem wrote: post #162

lobster_johnson wrote: post #107

Earlier quoted context omitted.

These things depends a lot on how you build an app, too. All our webapps these days are thin React apps (with server-side rendering) that don't have a dedicated backend. Instead, they talk to a group of generic microservices. We've been doing this style of development since around 2010. With this methodology, a lot of Rails' ergonomic concerns (templating, the split between rendering HTML vs. data, etc.) just melt aw…

Not OP, but my guess is that would count as "in the weeds right off the bat"; the impression I get is that a lot of Rails's value proposition revolves around being able to start using it without actually needing to know or understand very much. (Which is not a bad thing, exactly! Its power as a rapid prototyping tool comes in large part from this trait. Unfortunately, so does its strong tendency to produce unmaintain…

Each approach comes with its benefits and challenges. I would never suggest anyone jump right to a microservice architecture if they haven't come to appreciate the problems posed by a Rails-type design.

One aspect I keep hammering on about with regard to microservices is reusability. If you're developing just one user-facing product, nevermind. But if you have a bunch of products, reusability across microservices is a huge boon compared to monoliths. Reuse all your job processing, notifications, data storage, login/auth/group/role/permission management, identity verification, image processing, NLP processing, feed processing, etc. etc. etc. across your entire stack.

With monoliths, the only other option is to build these as libraries, and unless you want to write bindings or write code more than once, you're now chaining yourself to a specific language.

Re: After reading “Rails is yesterday’s software”, I need to reply

#172

Post by padseeker » Wed, May 11, 2016, 6:09 PM UTC

I have to say I'm loving reading the thoughtful and insightful comments on this thread.

With any programming language and/or framework you have to pick your poison. Rails backloads a lot of big development obstacles that ultimately you may never actually encounter in the life of your app. The issue regarding gems can be aggravating. But the speed in which you can get your app built cannot be understated. Rails is not a one size fits all, and you might eventually outgrow rails (i.e. Twitter). Be grateful the framework got you to the point you could outgrow it, rails helped you get there.

Re: After reading “Rails is yesterday’s software”, I need to reply

#173

Post by tetha » Wed, May 11, 2016, 6:09 PM UTC

danenania wrote: post #64

Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory. 'Tomorrow's' languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and…

> With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter.

As one of our product managers put it: Often, you want something you can sell well fast enough to buy time to make it good.

Overall, in this tool/framework/language debate, I'm growing more and more convinced two things matter the most:

- Pick something the weakest 40% of your team are comfortable using. Especially with support, I'd trust myself to figure out enough of Elixir/React/Whatever to be decently productive within a week or two on the go. But that's the thing - that's why I advocate to pick something the weaker team members are fine with. They will struggle, not the stronger team members.

- Smash problems with standard solutions. Don't be smart. Pick the right tools, throw hardware at them. A decent combination of load balancing, language+ORM, an SQL persistence layer and possibly a message queue can handle _a lot_ of traffic. And it's easy to hire for and to get new people on board because there are no smart things going on.

Note that the language and web framework are not part of this consideration at all. My approach would prefer more established frameworks like rails or something in java though.

Re: After reading “Rails is yesterday’s software”, I need to reply

#174

Post by askyourmother » Wed, May 11, 2016, 6:11 PM UTC

btdiehr wrote: post #166

askyourmother wrote: post #160

Earlier quoted context omitted.

WordPress is a pretty crazy codebase, yet, it seems sane compared to Rails. Interesting that WordPress as a service are moving to a node.js backend from PHP - even they chase shiny too

Is it not an advantage for average users to be able to do both the front end and back end knowing only a single language?

The same advantage as just using a screwdriver to handle nails and screws? No. Right tool on the server (hint: it's not JS nor node), right tool on the client (JS if needs must)

Re: After reading “Rails is yesterday’s software”, I need to reply

#175

Post by akmiller » Wed, May 11, 2016, 6:17 PM UTC

Bluestrike2 wrote: post #148

akmiller wrote: post #132

Earlier quoted context omitted.

I've been doing Clojure for the better part of 3 years now and I'm not sure I get why people feel doing web development in Clojure is hard. Our first foray in Clojure was/is an API to manage our users that was built by 2 developers who were new to the language and has been running largely unmodified since being released. I actually believe the opposite. Jumping into and doing Clojure web development is extremely simp…

Is it fair to ding Rails for that, though? Regardless of what framework you're working with, eventually you're going to be peeking under the hood. Of either the framework, the language, or both. Whether that's front-loaded or not, it's still there. So the question becomes which framework eases you into the deep end of the pool, rather than which is the least complex. I've seen plenty of Rails apps that could have wri…

I'm not dinging Rails for that. Like I said I've done some successful applications with Rails.

The difference I'd say between Clojure is you learn those from the bottom up, whereas with Rails you learn from the top down. Either way, you are going to have to learn them!

Re: After reading “Rails is yesterday’s software”, I need to reply

#176

Post by akmiller » Wed, May 11, 2016, 6:24 PM UTC

s_kilk wrote: post #150

akmiller wrote: post #132

Earlier quoted context omitted.

I've been doing Clojure for the better part of 3 years now and I'm not sure I get why people feel doing web development in Clojure is hard. Our first foray in Clojure was/is an API to manage our users that was built by 2 developers who were new to the language and has been running largely unmodified since being released. I actually believe the opposite. Jumping into and doing Clojure web development is extremely simp…

> The issue with frameworks like Rails is that you get so much for free and don't have to understand how all the pieces fit and work together Having used both Ruby/Rails and Clojure, I think Clojure swings too far in the opposite direction, where absolutely everything is foisted on the developer and they must hold the entire codebase in their head at once or drown. We even see this in luminus, the closest thing Cloju…

> where absolutely everything is foisted on the developer and they must hold the entire codebase in their head at once or drown.

I don't get that, and if that's how you feel I'd say you are doing functional programming wrong!

That being said, I do agree about Luminous and I think it's a terrible way for a new web developer to Clojure to get started. Instead build your way up for what your app needs pulling in the libs as you need them and understanding how they fit and work together. Chances are you don't need that many at all.

Re: After reading “Rails is yesterday’s software”, I need to reply

#177

Post by lo_fye » Wed, May 11, 2016, 6:24 PM UTC

PHP is the day before yesterday's software, but it still gets a shitload of profitable work done.

Re: After reading “Rails is yesterday’s software”, I need to reply

#178

Post by brightball » Wed, May 11, 2016, 6:25 PM UTC

DevinTheDude wrote: post #167

brightball wrote: post #97

At the moment, the alternatives mentioned to Rails aren't actually alternatives. You are still going to make major trade offs in productivity compared to Rails... Unless he's talking about Elixir and Phoenix, which IMHO is the future of web development.

As someone who has never heard of Elixir/Phoenix, why do you think it's the future. What does it do better than Rails? I'm looking to start a new web application, and I'm open to new technologies.

Elixir is a nicer to work with language that Erlang that compiles down to the Erlang VM. That gives it a better concurrency model and fault tolerance than Go.

Rails core team members have been building Phoenix. It's syntax is built to be extremely familiar to Rails but it's been built from the ground up to correct a lot of core issues that come up long term with Rails. It's basically fast Rails.

You get a very equivalent level of productivity with performance and fault tolerance of Erlang. Benchmarks show performance on par with Go.

It's really fascinating. I've been programming professionally for about 17 years now and it's the first time I've been truly excited about a language for a long time.

Re: After reading “Rails is yesterday’s software”, I need to reply

#179

Post by colinramsay » Wed, May 11, 2016, 6:27 PM UTC

lobster_johnson wrote: post #107

danenania wrote: post #64

Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory. 'Tomorrow's' languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and…

These things depends a lot on how you build an app, too. All our webapps these days are thin React apps (with server-side rendering) that don't have a dedicated backend. Instead, they talk to a group of generic microservices. We've been doing this style of development since around 2010. With this methodology, a lot of Rails' ergonomic concerns (templating, the split between rendering HTML vs. data, etc.) just melt aw…

I'd love to know more about your webapp methodology. It sounds wonderful.

Re: After reading “Rails is yesterday’s software”, I need to reply

#180

Post by mmedley » Wed, May 11, 2016, 6:35 PM UTC

It simply boils down to what you're most proficient with. Depending on the problem, you're likely to encounter some technologies are better suited than others. That to me is where you'll get the most bang for the buck, being able to decide on the right tool for the problem.