6 ms·

I would love to find an MVC framework with the extense library support of Rails but for Javascript. Being able to simply `gem 'devise'` and have full authentica

I would love to find an MVC framework with the extense library support of Rails but for Javascript. Being able to simply `gem 'devise'` and have full authentication at your hands (including views, email templates, etc) is a godsend. At many places where I've worked at this paradigm is exactly what is needed, but people know and want to use JS. If we choose to go that way then, we need to write a lot of glue code and think about setting up architecture standards, folder and naming conventions, ORM support, authentication, job queues, etc; all of this comes by default with Rails and makes life so much easier. Lately some options seem to be gaining steam: * RedwoodJS [1]: by Tom Preston-Werner (founder of Github), comes with React and GraphQL baked in, pretty new project though * Next.js [2]: brings a lot of nice conventions to the frontend, but still some things missing on the backend side * SailsJS [3]: similar to Rails, but small community * Strapi [4], hapi [5] et al: plenty of backend functionality, but frontend agnostic. Has anybody had experience with any of these (or others) and can report back? [1] - https://redwoodjs.com/ https://redwoodjs.com/ [2] - https://nextjs.org/ https://nextjs.org/ [3] - https://sailsjs.com/ https://sailsjs.com/ [4] - https://strapi.io/ https://strapi.io/ [5] - https://hapi.dev/ https://hapi.dev/

patates 6y ago
https://nestjs.com/ https://nestjs.com/ is nice, although I'm not sure about your front-end expectations.
gls2ro 6y ago
I don't have a recommendation, but here is a quick test I use when looking for a replacement for Rails: How quick can I create a minimum simple SaaS like application that has the following functionalities: - User management (Signup/Login/Reset password/Confirmation...) - Simple payment processing (like have on single plan, one time fee, and after paying the user will see some other default page then not paying) - Sending emails in HTML and plain text (for user management and after payment is processed) - Use slugged/permalink like URLs - Processing some task in async queue And so far there are a lot of alternatives out there but for me Rails provides the easiest experience to have this up and running quickly as there are already battle-tested gems for almost all these functionalities.
- andi999 6y ago
  Just wondering: is rails transactional? What I mean how are race conditions avoided if e. g. two requests are processed at the same time.
  - gls2ro 6y ago
    In case of DB: I think ActiveRecord has #lock (see https://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.html https://api.rubyonrails.org/classes/ActiveRecord/Locking/Opt...) and that together with #transaction (https://api.rubyonrails.org/classes/ActiveRecord/Transactions/ClassMethods.html https://api.rubyonrails.org/classes/ActiveRecord/Transaction...) are enough for my use cases. In case of file uploads to cloud providers: there I don't know for specific method to help with race conditions when transforming the resources.
  - ryanbrunner 6y ago
    Rails has support for database transactions, but depending on what you want to do, things won't be magically transactional all by themselves (that said, it's really just a matter of wrapping transactional code in a block). There are a couple of footguns in Rails involving transactions - by default, validating uniqueness of a column in Rails will be done at the app layer which is prone to race conditions, and with a typical CRUD model for an application, there's nothing in particular preventing overwrites of model data if say, a field was present on a form and two people were editing it, even if the "later" editor made no changes to that particular field. When multiple systems and things other than databases (or multiple databases) are involved, you're generally on your own as well.
    - pbowyer 6y ago
      It's important to say that these footguns are not exclusive to Rails. I don't know a single web framework which avoids them - if it exists I'd like to know so I can learn how they do it.
      - RickSullivan 6y ago
illiriath 6y ago
I've had good experience using Nest.JS [1] for the backend and next.js for the frontend. Nest has defaults for ORM, validation, task scheduling, authentication, etc, I find it a lot easier to work with when compared to plain express projects with tons of glue. Disclaimer: I have never tried Rails [1] https://nestjs.com/ https://nestjs.com/
busk07 6y ago
https://adonisjs.com https://adonisjs.com <- feels the closest to rails but with nodejs instead
claudiojulio 6y ago
https://adonisjs.com https://adonisjs.com
nickjj 6y ago
I think this is a very uphill battle because JS and most other languages are missing a key ingredient that Rails has had for 10+ years. It's having a long running large real world SAAS app that Rails is extracted from. That means every feature of Rails is derived from a practical use case, and then it's well tested in that app before it's pushed out to the community. That's tested from an API and functionality point of view. By the time end users start to use it, the feature has likely been running in production for 6+ months. Maybe even serving billions of page views through it if you factor in Shopify and GitHub also running off Rails master. It's all constantly in use, kept up to date and iterated on as a whole. Creating a starter kit / boiler plate of libraries and opinions in another language / web framework is not the same. I think this is why even after 10+ years there's only a handful of popular Rails alternatives in other languages.
- ivanhoe 6y ago
  There's plenty of JS code written out of the real needs and by teams running huge projects, take just Facebook as an example. Problem is that there are thousands of solutions for everything, and that saturation and bad signal to noise ratio makes it hard sometimes to pick the right lib (or even hear about it in the first place). Rails have a huge benefit of having a single team behind it, so you always have a recommended way of doing things, and the whole community is smaller, less libs to test, less rubbish to avoid, making the experience much more linear...
twic 6y ago
It's crazy to me that every other language doesn't have a Rails, literally just a clone. It has been so obviously valuable, and is now so well understood.
- pjmlp 6y ago
  We were using AOLServer and its clones, Vignette, Zope before Rails was invented. Most of the Java and .NET world eventually moved into full blown CMS, with component frameworks, graphical layout editors, user management and third party connectors to distributed platforms. For me, Rails just feels too little, with a quite slow language.
alejandro_del 6y ago
Check https://blitzjs.com/ https://blitzjs.com/
AlphaWeaver 6y ago
I've used 1, 2, and 4. Strapi [4] is much less stable than it looks. It's pretty buggy, isn't designed very well, and is just all around messy. I used it in production once and never will again. Next.js [2] is well designed and well maintained, but is totally a frontend framework. It's not just "missing a few things" on the backend side, there is no backend side. Works great if you already have an API (JAMStack) but can't stand alone in the way that Rails or Laravel might be able to. Despite being the youngest, RedwoodJS [1] is the best option here. I was actually involved pretty early on as a contributor on the project before I had to step away (unrelated, personal reasons) and was seriously impressed by their progress. TPW runs a tight ship, and all of the devs that work on the project are smart and amazing. They ship very quickly and it's rapidly growing into the closest thing to a Rails competitor in Javascript. I wouldn't be surprised if it takes the JS world by storm in a year or two.
cjohnson318 6y ago
I like using Django [0] with django-rest-framework [1] and dj-rest-auth [2]. This gets you Rails-inspired organization, with a nice abstraction for REST endpoints in general, and a login/logout/registration/email verification/social auth in particular. Everything is built on the very well maintained allauth [3] module. Here's a good quickstart [4]. I've used Ruby in production, but I like Python's "one way of doing things" approach. [0] - https://www.djangoproject.com/ https://www.djangoproject.com/ [1] - https://www.django-rest-framework.org/ https://www.django-rest-framework.org/ [2] - https://dj-rest-auth.readthedocs.io/en/latest/index.html https://dj-rest-auth.readthedocs.io/en/latest/index.html [3] - https://django-allauth.readthedocs.io/en/latest/overview.html https://django-allauth.readthedocs.io/en/latest/overview.htm... [4] - https://www.rootstrap.com/blog/registration-and-authentication-in-django-apps-with-dj-rest-auth/ https://www.rootstrap.com/blog/registration-and-authenticati...
berkes 6y ago
> Being able to simply `gem 'devise'` and have full authentication at your hands (including views, email templates, etc) is a godsend. I'm on the other end of the spectrum. I mean, I see the benefit of such "roll X quick by adding a gem" for a proof of concept, a demo or even an MVC. But even for the latter, it breaks down rapidly. Such gems bring their own libraries. They force you to "do it their way". A gem like devise comes with its own addons (omniauth) that paint you even quicker into a corner. I've consulted and developed at many Rails codebase where most of the problems were caused by years of development on top of such gems. A weak, wobbly base, and the entire castle built on top of that. Where 90% of the devise features were unused or worked around. Where more code was present to customise and work around devise-isms, AASM-weirdness, CanCan-troubles, than a complete "roll your own from scratch" would have ever caused. So, my "devise advise" always is: sure, use it to get your product to market rapidly. But be sure to pull it out and replace it with a focused, fitting architecture, sooner rather than later. Such gems fit very well in the problematic development-workflow where one "searches for an existing gem which offers some version of Foo" rather than "figuring out how we want to do Foo, then look for a gem that does it our way".
- mparramon 6y ago
  I think this is due to the extent of the maintenance efforts by the team that develops the app, not due to the gems themselves. A monolithic app means that no code is legacy code: a conscious, gardening-like effort needs to be continuously done to keep interfaces standardised, modules documented, code clean, and critical components (like user management) top-notch with focused testing and code quality metrics. I've worked in different teams on 5+ year codebases that hold up to this day by being disciplined on this terms and never buckling down on complexity. What I've also seen is that a team with plenty of churn or no time for maintenance will have exactly the problems you describe. As knowledgeable people leave the team, the old code becomes "legacy", new people come and partially refactor it, maybe adding some new gem and planning to migrate the entire codebase later on to it (which is very hard to make it happen). Stakeholders' pressure will force the team to focus on delivering features and only tackling debt when it gets to an unattainable state, and then is when consultants are called. I think this is why many freelancers suffer the worst of Rails (or any other framework) if they don't usually work with greenfield projects.

patates 6y ago

https://nestjs.com/ https://nestjs.com/ is nice, although I'm not sure about your front-end expectations.

gls2ro 6y ago

I don't have a recommendation, but here is a quick test I use when looking for a replacement for Rails: How quick can I create a minimum simple SaaS like application that has the following functionalities: - User management (Signup/Login/Reset password/Confirmation...) - Simple payment processing (like have on single plan, one time fee, and after paying the user will see some other default page then not paying) - Sending emails in HTML and plain text (for user management and after payment is processed) - Use slugged/permalink like URLs - Processing some task in async queue And so far there are a lot of alternatives out there but for me Rails provides the easiest experience to have this up and running quickly as there are already battle-tested gems for almost all these functionalities.

andi999 6y ago
Just wondering: is rails transactional? What I mean how are race conditions avoided if e. g. two requests are processed at the same time.
- gls2ro 6y ago
  In case of DB: I think ActiveRecord has #lock (see https://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.html https://api.rubyonrails.org/classes/ActiveRecord/Locking/Opt...) and that together with #transaction (https://api.rubyonrails.org/classes/ActiveRecord/Transactions/ClassMethods.html https://api.rubyonrails.org/classes/ActiveRecord/Transaction...) are enough for my use cases. In case of file uploads to cloud providers: there I don't know for specific method to help with race conditions when transforming the resources.
- ryanbrunner 6y ago
  Rails has support for database transactions, but depending on what you want to do, things won't be magically transactional all by themselves (that said, it's really just a matter of wrapping transactional code in a block). There are a couple of footguns in Rails involving transactions - by default, validating uniqueness of a column in Rails will be done at the app layer which is prone to race conditions, and with a typical CRUD model for an application, there's nothing in particular preventing overwrites of model data if say, a field was present on a form and two people were editing it, even if the "later" editor made no changes to that particular field. When multiple systems and things other than databases (or multiple databases) are involved, you're generally on your own as well.
  - pbowyer 6y ago
    It's important to say that these footguns are not exclusive to Rails. I don't know a single web framework which avoids them - if it exists I'd like to know so I can learn how they do it.
    - RickSullivan 6y ago

illiriath 6y ago

I've had good experience using Nest.JS [1] for the backend and next.js for the frontend. Nest has defaults for ORM, validation, task scheduling, authentication, etc, I find it a lot easier to work with when compared to plain express projects with tons of glue. Disclaimer: I have never tried Rails [1] https://nestjs.com/ https://nestjs.com/

busk07 6y ago

https://adonisjs.com https://adonisjs.com <- feels the closest to rails but with nodejs instead

claudiojulio 6y ago

https://adonisjs.com https://adonisjs.com

nickjj 6y ago

I think this is a very uphill battle because JS and most other languages are missing a key ingredient that Rails has had for 10+ years. It's having a long running large real world SAAS app that Rails is extracted from. That means every feature of Rails is derived from a practical use case, and then it's well tested in that app before it's pushed out to the community. That's tested from an API and functionality point of view. By the time end users start to use it, the feature has likely been running in production for 6+ months. Maybe even serving billions of page views through it if you factor in Shopify and GitHub also running off Rails master. It's all constantly in use, kept up to date and iterated on as a whole. Creating a starter kit / boiler plate of libraries and opinions in another language / web framework is not the same. I think this is why even after 10+ years there's only a handful of popular Rails alternatives in other languages.

ivanhoe 6y ago
There's plenty of JS code written out of the real needs and by teams running huge projects, take just Facebook as an example. Problem is that there are thousands of solutions for everything, and that saturation and bad signal to noise ratio makes it hard sometimes to pick the right lib (or even hear about it in the first place). Rails have a huge benefit of having a single team behind it, so you always have a recommended way of doing things, and the whole community is smaller, less libs to test, less rubbish to avoid, making the experience much more linear...

twic 6y ago

It's crazy to me that every other language doesn't have a Rails, literally just a clone. It has been so obviously valuable, and is now so well understood.

pjmlp 6y ago
We were using AOLServer and its clones, Vignette, Zope before Rails was invented. Most of the Java and .NET world eventually moved into full blown CMS, with component frameworks, graphical layout editors, user management and third party connectors to distributed platforms. For me, Rails just feels too little, with a quite slow language.

alejandro_del 6y ago

Check https://blitzjs.com/ https://blitzjs.com/

AlphaWeaver 6y ago

I've used 1, 2, and 4. Strapi [4] is much less stable than it looks. It's pretty buggy, isn't designed very well, and is just all around messy. I used it in production once and never will again. Next.js [2] is well designed and well maintained, but is totally a frontend framework. It's not just "missing a few things" on the backend side, there is no backend side. Works great if you already have an API (JAMStack) but can't stand alone in the way that Rails or Laravel might be able to. Despite being the youngest, RedwoodJS [1] is the best option here. I was actually involved pretty early on as a contributor on the project before I had to step away (unrelated, personal reasons) and was seriously impressed by their progress. TPW runs a tight ship, and all of the devs that work on the project are smart and amazing. They ship very quickly and it's rapidly growing into the closest thing to a Rails competitor in Javascript. I wouldn't be surprised if it takes the JS world by storm in a year or two.

cjohnson318 6y ago

I like using Django [0] with django-rest-framework [1] and dj-rest-auth [2]. This gets you Rails-inspired organization, with a nice abstraction for REST endpoints in general, and a login/logout/registration/email verification/social auth in particular. Everything is built on the very well maintained allauth [3] module. Here's a good quickstart [4]. I've used Ruby in production, but I like Python's "one way of doing things" approach. [0] - https://www.djangoproject.com/ https://www.djangoproject.com/ [1] - https://www.django-rest-framework.org/ https://www.django-rest-framework.org/ [2] - https://dj-rest-auth.readthedocs.io/en/latest/index.html https://dj-rest-auth.readthedocs.io/en/latest/index.html [3] - https://django-allauth.readthedocs.io/en/latest/overview.html https://django-allauth.readthedocs.io/en/latest/overview.htm... [4] - https://www.rootstrap.com/blog/registration-and-authentication-in-django-apps-with-dj-rest-auth/ https://www.rootstrap.com/blog/registration-and-authenticati...

berkes 6y ago

> Being able to simply `gem 'devise'` and have full authentication at your hands (including views, email templates, etc) is a godsend. I'm on the other end of the spectrum. I mean, I see the benefit of such "roll X quick by adding a gem" for a proof of concept, a demo or even an MVC. But even for the latter, it breaks down rapidly. Such gems bring their own libraries. They force you to "do it their way". A gem like devise comes with its own addons (omniauth) that paint you even quicker into a corner. I've consulted and developed at many Rails codebase where most of the problems were caused by years of development on top of such gems. A weak, wobbly base, and the entire castle built on top of that. Where 90% of the devise features were unused or worked around. Where more code was present to customise and work around devise-isms, AASM-weirdness, CanCan-troubles, than a complete "roll your own from scratch" would have ever caused. So, my "devise advise" always is: sure, use it to get your product to market rapidly. But be sure to pull it out and replace it with a focused, fitting architecture, sooner rather than later. Such gems fit very well in the problematic development-workflow where one "searches for an existing gem which offers some version of Foo" rather than "figuring out how we want to do Foo, then look for a gem that does it our way".

mparramon 6y ago
I think this is due to the extent of the maintenance efforts by the team that develops the app, not due to the gems themselves. A monolithic app means that no code is legacy code: a conscious, gardening-like effort needs to be continuously done to keep interfaces standardised, modules documented, code clean, and critical components (like user management) top-notch with focused testing and code quality metrics. I've worked in different teams on 5+ year codebases that hold up to this day by being disciplined on this terms and never buckling down on complexity. What I've also seen is that a team with plenty of churn or no time for maintenance will have exactly the problems you describe. As knowledgeable people leave the team, the old code becomes "legacy", new people come and partially refactor it, maybe adding some new gem and planning to migrate the entire codebase later on to it (which is very hard to make it happen). Stakeholders' pressure will force the team to focus on delivering features and only tackling debt when it gets to an unattainable state, and then is when consultants are called. I think this is why many freelancers suffer the worst of Rails (or any other framework) if they don't usually work with greenfield projects.