Hacker News new | past | comments | ask | show | jobs | submit login

I used to write Rails professionally for many years

This comparison isn't a good one. Rails is an all-encompasing framework.

If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have.

---

EDIT: To clarify (because it is confusingly named), NestJS is a framework modeled after Spring Boot for TypeScript + Node:

https://nestjs.com/

Not to be confused with Next.js, which is a framework for building SSR React apps.




I should've been more clearer. This post isn't comparing Rails to any framework out there.

What I was trying to say is that Rails got a lot of things right and it's making me productive, because I don't have to make the same decisions over and over again when making a JS app. Rails made those decisions for me and the only thing left for me is to build my app.

I myself like Next.js and Remix a lot, but they still leave you to spend time making basic decisions, like how to organize your project or how to implement background jobs.

That's why I'd love to see more conventions and less configuration in the JS land.


> I'd love to see more conventions and less configuration in the JS land.

Which is what the parent post is saying NestJS offers. I'm not familiar with it, so can't comment on the veracity of that claim, but I think you might have missed their point, perhaps because they confusingly called it "Nest.js" which could be mistaken for "Next.js".


You could compare Red Delicious to Granny Smith and a programmer will come along and say it's an unrelated variety. The problem is even if you want to use a larger library/framework, there are over ten thousand to choose from. The JS ecosystem is built upon the Unix philosophy of "Do one thing and do it well." So there is a reason React is not a framework and that is not your fault. If you do not use a Rails copycat, you are left with many decisions for packages. Nobody has time for that so everyone just uses what is most popular. So the comparison is fair, it's just a comparison between philosophies.


I think the main Thing here is that Rails is the de facto standard, the 'golden hammer' of Ruby based apps, and there is no space - or developers - for alternatives.

The JS ecosystem as we know it today started years after Rails (Rails was 2004, Node's oldest version on their releases page is from 2011), and only really took off after NodeJS came to prominence with frameworks like BackboneJS, Angular, then React and the rest in the early 2010's, and it went along with Github and the emergence of everyone and their dog building libraries and frameworks.

The attitude was different; instead of big opinionated but inflexible frameworks, people wanted to pick and choose. This was exacerbated by React that emphasized NOT being a framework but just a rendering layer.

Pick ANY one-size-fits-all framework in the JS space and you will see "bad" decisions that people don't like.

The closest thing to a full JS framework at the moment is probably Angular, which feels bloated and overly complicated (annotations, component / folder structure / file naming) or Express (stringly typed? I haven't looked at it in forever).


The dominance of Rails for its use case within the field of Ruby is is only one half of the equation. The other half is that Ruby has mostly collapsed into Rails, there's not much Ruby happening outside of Rails. This could never happen with a js framework of similarly scope, because all the other js use cases won't go away. One example of such a thing that won't go away is doing client-side stuff in the scope of a Rails protect. JS would have to lose a lot before it could achieve similar focus.


Ruby is a wonderful language for other things outside of Rails. I'm old. I've done csh, bash, perl, tcl, and python for scripting and miscellaneous programs. Since discovering Rails, I use Ruby for basically everything now. The only miss I've had in recent memory has been needing to do heavy statistical work with R for speed reasons, but, then, you're not going to do that in JS (or anything else) either.


As someone who has used Ruby as my main language at a number of companies for the last 17 years and deeply dislike Rails and rarely use it, I couldn't disagree more.

Rails draws the attention, but there's plenty other uses.


That's interesting to hear, I would have guessed that Python had long won everything that could be ruby but isn't rails. Clearly, nothing will stop the inertia of someone who just happens to be productive through experience (you can probably find works-for-me wizards for almost anything, perhaps not for vba or ada but I wouldn't bet on it).

Is there much happening in terms of libraries outside the rails scope or is it more a case of one less thing to worry about once you've become good with the batteries included?


Thor is gorgeous for command line apps. http://whatisthor.com/

Capybara is fantastic for automated testing

https://github.com/teamcapybara/capybara.

Gosu for 2d Games:

https://www.libgosu.org/

Example 2d game with Gosu:

https://github.com/victords/super-bombinhas

CRuby will be in browsers!

https://bugs.ruby-lang.org/issues/18462


Thor looks great! I'd be surprised if something similar didn't exist for most languages, but with many of them living in obscurity because discovery is so hard without a well-established name for that class of tool. Some googling for "CLI framework" led me to oclif ("Thor for js"?) and to https://www.nexmo.com/legacy-blog/2020/06/12/comparing-cli-b... , but that can't be everything.

PS: https://github.com/shadawck/awesome-cli-frameworks also lists some for go and rust, getting there! (though most probably not half as complete as Thor, self-documentation should definitely be a first-class citizen!)


I rarely find an area where I've needed libraries and there haven't been decent stuff available in Ruby other than when doing quite esotheric stuff (e.g. there's no good low level X11 client implementation for doing raw X11 stuff). Often multiple competing projects.

E.g. for ORMs ActiveRecord which is Rails default is in my opinions nowhere near good enough compared to e.g. Sequel, and there are several others.

Sometimes those projects involve wrapping stuff - including Python - or porting Python, but most of what I use is pure Ruby.

With respect to Python, to a lot of the Ruby community Python is in many ways the antithesis of what we want in a language. Python looks horrendous to me. It matters - I stare at code most of my day. If I were to switch languages, Python wouldn't make the shortlist even. It's not that I think Python is objectively worse, but subjectively to me it's unreadable and messy and I can afford to avoid using it most of the time.

EDIT: To expand on some of what I use or have used Ruby for: web dev with Sinatra and Padrino (my main reason for avoiding Rails here is that most of what I do is mostly API driven, and because I prefer Sequel as the ORM), financial modelling (I work for a VC), my text editor of the last few years is written in Ruby (but not packaged up to be useful for others yet - I'm gradually splitting parts of it out into gems, though), DevOps by generating terraform, service orchestration (proprietary pre-Kubernetes orchestration of containers and vms across on-prem, colocated, managed servers and VPSs split between openvz, docker and KVM), system to auto-deploy replicated sets of Postgres servers with logs and backup dumps automatically distributed to a Ruby storage service (pre-RDS, and running on the aforementioned orchestrator), PDF generation, messaging middleware, scraping, large scale crawlers, trading bots. And many more.


I think this is "the" correct analysis.

Rails has a clear one way to do things because there are no/few other options because everything else has withered away.

To put this another way: to have a convention in JS, just pick a convention, and now at least you have a convention, even if everyone else has their own.


It’s not really true that there are no other options for web development in ruby.

Roda[1], for instance, has a strong following for API work.

It’s just that Rails is a safe choice. It’ll will work fine for small teams and it will scale to the size of github when/if you need it.

1. http://roda.jeremyevans.net/index.html


When I develop web apps for Ruby, I use Sinatra or pick and choose parts of Padrino. There's a dozen other alternatives to Rails.

There's plenty of space.for alternatives. But Rails is good enough for those who are happy with a hammer, and so it's what gets talked about the most.


The default Angular structure is pretty verbose, but it's just TS, you can put the files anywhere. Also it seems many people prefer the Vue-style single-file components: https://muhimasri.com/blogs/how-to-create-a-single-file-comp...


It always gets me abit, angular is called bloated however all the react/vue applications i have worked with have been bloated by shitty packages left and right to fix problems that never existed in angular, im probably just to old or what not but i dont find the configuration bad since you can always figure out what went wrong, that is not the case on react/vue unfortuenately, it ends up being very opinionated by the last dev that took charge, and the endless refactors of architecture because now there is a new way of doing it..


> The attitude was different; instead of big opinionated but inflexible frameworks, people wanted to pick and choose.

I enjoy working with Node and JS, but this IMO is what contributed to the fragmented node ecosystem where you have 100 different npm libraries that do the same thing and reinventing the wheel is rampant


I can't help but think it is a reflection of the JS ecosystem that I assumed you had misspelled Next.js


This is a good point, updated parent post


I guess Nest.js is actually right: https://nestjs.com/ A TypeScript framework like Rails is a framework for Ruby.


I'm lolling because their first code block next to a live preview shows "500 internal server error"


> I guess Nest.js is actually right

Not quite. "NestJS" is actually right. :)


The point here is that you do not have to think about choices, there is a "rails way" for every problem. There is no such thing as "the node way". They are hundreds of ways, some of them are dead ends.


> There is no such thing as "the node way".

And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals.

If it turns out your goals are a very simple crud app for a team of under 5 - Rails is probably a great choice.

For most everything else, you should probably understand why Rails made the choices they did, and what the trade-offs are. (ex: I would argue that the author is making a HUGE mistake by not just immediately outsourcing auth to something like a self-hosted Keycloak instance, or Okta/Auth0 - but my needs require enterprise auth support (SAML, OIDC, Provider support, etc) and maybe his don't)

But the thing is... there are TONS of simple CRUD app frameworks out there. Rails is a good one, but so is NestJS, or ASP.net Core. There's at least one "Opinionated" CRUD framework for almost every language.

Rails is still good, but I find it has a distinct "ASP.net classic" feel to it now - Too many versions, too much change, too many contradicting "opinions" between major versions.


> And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals.

That comes with a downside though, which is that for any given problem there won’t necessarily be an ultra-well-supported “happy path” where every conceivable problem has long been documented along with a solution.

To me the lack of happy paths can be a problem. It’s something that is often encountered with Android development because Google can’t make up its mind and it’s very frustrating — usually your choices are between 5 different APIs that suck in different ways, meaning you have to pick the one that sucks in a way you think you can deal with best. It’s a significant damper on both velocity and motivation.


If you're just doing something so simple that "every conceivable problem has long been documented along with a solution." then you're using the wrong tool if you're programming anything at all.

Problems that fall into that space are usually better served by simple site builders (Wix/Square/Shopify/Wordpress/etc).


It also comes with more debugging in the node world. Since everybody is doing things differently and the packages you install are usually poorly tested (or not at all), you very encounter shortcomings.


> Too many versions, too much change, too many contradicting "opinions" between major versions

Tell us you haven't used Rails much without telling us you haven't used Rails much. There's been precious little I've needed to change in my approach since the 3.x days. The new TurboJS world they're baking into 7 sounds significant though.


> Rails is still good, but I find it has a distinct "ASP.net classic" feel to it now - Too many versions, too much change,

Well Rails is gonna celebrate 20 in 2 years, so yes there's quite a lot of versions and changes over the years, that's inevitable for every long running project I think.


Is there a such thing as "the ruby way"?



Arrghh... This week was the first in years where I didn't FOMO. And here comes Nest.js. I desperately need an ad blocker though for shiny new tech thingies.


Well, adding

  0.0.0.0 news.ycombinator.com lobste.rs dev.to 
to your hosts file would go a long way but I am not sure I would recommend it. I've decided to not do it.


Interesting, why is Nestjs used by so many online casinos? Is that random or is there some specific feature or approach used that is particularly valuable for that use case?


Online casinos have usually been very aggressively sponsoring anything and anyone willing to take their money (and the usual reputation hit that can come with the perceived shadiness of gambling). That's especially true for newcomers who just burn as much money as they can, trying to establish a foothold. I'd say, being on the front page of a popular, credible project like that is probably sought after, hence the unusual amount of casino sponsorships




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: