6 ms·

So many frameworks in other languages are trying to get to the productivity of Rails but they just don't have the same spark imo. There is no Rails equivalent

So many frameworks in other languages are trying to get to the productivity of Rails but they just don't have the same spark imo. There is no Rails equivalent in JS, theres lots of competitors that feel years away like SailsJS, the new Deno Fresh one etc, Adonisjs... Is NextJS/SvelteKit/RemixRun considered also? I don't even know if they have a standardised background job processor in JS land. Java's solutions are dreadful imo for if you want to compare to Rails. Quarkus/SpringBoot/Micronaut are nowhere near productivity levels for a fullstack app. They lean heavily on the API only side of things. (I do like Java oddly enough) PHP is the main competitor to Rails oddly enough, Laravel seems brilliant. Go is just starting up in this space it looks like, Bud is another attempt at Rails in another language https://github.com/livebud/bud https://github.com/livebud/bud. However the Go ecosystem is heavily API only side of things instead of SSR. Go's templating libs suck imo. Elixir of course has Phoneix which is apparently great, purely functional langs unfortunately dont fit my head and feel to abstract for myself (don't hate me) Its no wonder we have the backend / frontend developer split nowadays.

tusharsoni 4y ago
This is a good observation. One trend I'm noticing is that the "old way" (PHP, Rails, etc.) of doing things is making a comeback. Go is very well positioned for this but lacks the frameworks. I'm hoping to add something like Phoenix to Copper. It should help with the "heavily API only side" problem. I've already added integrations for Tailwind and added some utilities on top of the templating (going to add more) to fix the lack of good templating.
- melony 4y ago
  Go and Java can never use the same framework patterns as Python/Php/Elixir/Ruby/JS because they are not dynamic enough. The Rails-style request mapped dispatching into active record ORM pattern requires a lot of flexibility on the host language side. For Go and Java, you basically end up with code generation or reflection, and the latter is a killer for performance. On the other hand, the performance of Go and Java is better by several orders of magnitude.
  - treis 4y ago
    They need to solve the same problems. They don't have to solve them in the same way.
  - jitl 4y ago
    Models change pretty slowly, so codegen is a good solution! Ent uses codegen for its query API which looks pretty nice: https://entgo.io/docs/tutorial-todo-crud https://entgo.io/docs/tutorial-todo-crud I’m considering writing a Typescript clone of Ent with codegen powered by Typescript types. I like codegen over dynamic magic because the runtime behavior is often easier to understand. In Rails, I need to traverse a lot of space in Pry’s debugger mode to figure out WTF is happening. I would much rather have codegen.
  - morelisp 4y ago
    Reflection is killer for performance because it brings Java/Go down to the level of a JIT-less language like Python (and ORMs aren't too kind to JITs in e.g. Ruby/JS either). The problem with reflection in Go/Java is mostly that it's hard to read, since the reflection-ful APIs are hosted rather than native syntax.
    - hrgiger 4y ago
      Agree reflection has (often big) trade offs but its not as bad as it was years ago, especially if its used during construct time rather than runtime, if you combine it with runtime caches you still get the benefits imo
swagonomixxx 4y ago
Building a "Rails-like" framework in Go is honestly totally antithetical to the "Go way" of doing things. Rails has a ton of magic, implicit behaviours, monkey patching, ERB, and so on. Go is a touch below Java verbose, explicit, no magic, every function call can be very easily traced without having to do meta programming and code generation in your head to understand what's going on. In my 8 years of writing Go, I would liken it the most to C, where you had to spell everything out, except without the manual memory management and the macro preprocessor. Doing magic with Go via reflection or other implicit behaviours is generally annoying to deal with. One example is some libraries using struct tags, most of the time they work as expected, but sometimes you get some weird failure and these kinds of implicit behaviours are the culprit. Overall, I don't rate these "all in one" frameworks highly in Go. The standard library is excellent for most applications, you only need to add some code to remove some boilerplate. For most apps that I have worked on in Go that involved web components, we maybe had to import e.g a websockets library or a more elegant routing library, but that's pretty much it.
- melony 4y ago
  Go needs a better ORM story, it is unfortunate Prisma abandoned their Go port.
  - lordofgibbons 4y ago
    What about the Ent ORM library? https://entgo.io/ https://entgo.io/
    - morelisp 4y ago
      Ent can replace an ORM in your architecture, and it's easiest to explain in two seconds as "an ORM for Go", but it's not really that. It's a way to describe a persistent object graph, without any reference to persistence or mapping details. When your chosen persistence layer is an RDBMS, as it often is, then it uses an ORM - but you rarely interact with it at that level even when specify your entity schemas. You can back it with an object DB or REST API instead and then it wouldn't need the RM part at all.
matthewmueller 4y ago
Bud author here, thanks for including Bud on your list. That's a really good overview of the landscape! My take is that Remix + Next.js + SvelteKit are going to continue to innovate fast in the Frontend and "Backend for Frontend" space. Rails and Laravel don't hold a candle to the experience you get in that ecosystem. But the JS ecosystem is massive and, as a result, fragmented. As you mentioned, there's no consensus on ORMs, mailers, queues, etc. I don't see those frameworks trying to push too far in that direction, they'll remain "UI focused". This is nice for their focus, but not great for someone who wants to launch a web app and doesn't want to figure out all the surrounding ecosystem tooling. This is where Laravel, Rails (and soon Bud) (and I assume Copper) will shine. They provide more tools and interfaces out of the box for building full-featured backends. These frameworks definitely need to keep an eye on the best ideas coming out of the JS framework ecosystem though!
rubyist5eva 4y ago
A rails-like framework will never happen in a language that doesn’t have the same meta programming capabilities as Ruby. Rails exists because Ruby exists not because DHH just happened to be a Ruby programmer. There is a reason people have tried to recreate it in other languages and it always feels jank - because Rails is designed specifically and enabled by the Ruby language.
- matthewmueller 4y ago
  Code generation provides the same kind of flexibility you get with meta programming, you just need to do more work to keep generated code in sync and out of the way.
  - rubyist5eva 4y ago
    Like I said: jank.

tusharsoni 4y ago

This is a good observation. One trend I'm noticing is that the "old way" (PHP, Rails, etc.) of doing things is making a comeback. Go is very well positioned for this but lacks the frameworks. I'm hoping to add something like Phoenix to Copper. It should help with the "heavily API only side" problem. I've already added integrations for Tailwind and added some utilities on top of the templating (going to add more) to fix the lack of good templating.

melony 4y ago
Go and Java can never use the same framework patterns as Python/Php/Elixir/Ruby/JS because they are not dynamic enough. The Rails-style request mapped dispatching into active record ORM pattern requires a lot of flexibility on the host language side. For Go and Java, you basically end up with code generation or reflection, and the latter is a killer for performance. On the other hand, the performance of Go and Java is better by several orders of magnitude.
- treis 4y ago
  They need to solve the same problems. They don't have to solve them in the same way.
- jitl 4y ago
  Models change pretty slowly, so codegen is a good solution! Ent uses codegen for its query API which looks pretty nice: https://entgo.io/docs/tutorial-todo-crud https://entgo.io/docs/tutorial-todo-crud I’m considering writing a Typescript clone of Ent with codegen powered by Typescript types. I like codegen over dynamic magic because the runtime behavior is often easier to understand. In Rails, I need to traverse a lot of space in Pry’s debugger mode to figure out WTF is happening. I would much rather have codegen.
- morelisp 4y ago
  Reflection is killer for performance because it brings Java/Go down to the level of a JIT-less language like Python (and ORMs aren't too kind to JITs in e.g. Ruby/JS either). The problem with reflection in Go/Java is mostly that it's hard to read, since the reflection-ful APIs are hosted rather than native syntax.
  - hrgiger 4y ago
    Agree reflection has (often big) trade offs but its not as bad as it was years ago, especially if its used during construct time rather than runtime, if you combine it with runtime caches you still get the benefits imo

swagonomixxx 4y ago

Building a "Rails-like" framework in Go is honestly totally antithetical to the "Go way" of doing things. Rails has a ton of magic, implicit behaviours, monkey patching, ERB, and so on. Go is a touch below Java verbose, explicit, no magic, every function call can be very easily traced without having to do meta programming and code generation in your head to understand what's going on. In my 8 years of writing Go, I would liken it the most to C, where you had to spell everything out, except without the manual memory management and the macro preprocessor. Doing magic with Go via reflection or other implicit behaviours is generally annoying to deal with. One example is some libraries using struct tags, most of the time they work as expected, but sometimes you get some weird failure and these kinds of implicit behaviours are the culprit. Overall, I don't rate these "all in one" frameworks highly in Go. The standard library is excellent for most applications, you only need to add some code to remove some boilerplate. For most apps that I have worked on in Go that involved web components, we maybe had to import e.g a websockets library or a more elegant routing library, but that's pretty much it.

melony 4y ago
Go needs a better ORM story, it is unfortunate Prisma abandoned their Go port.
- lordofgibbons 4y ago
  What about the Ent ORM library? https://entgo.io/ https://entgo.io/
  - morelisp 4y ago
    Ent can replace an ORM in your architecture, and it's easiest to explain in two seconds as "an ORM for Go", but it's not really that. It's a way to describe a persistent object graph, without any reference to persistence or mapping details. When your chosen persistence layer is an RDBMS, as it often is, then it uses an ORM - but you rarely interact with it at that level even when specify your entity schemas. You can back it with an object DB or REST API instead and then it wouldn't need the RM part at all.

matthewmueller 4y ago

Bud author here, thanks for including Bud on your list. That's a really good overview of the landscape! My take is that Remix + Next.js + SvelteKit are going to continue to innovate fast in the Frontend and "Backend for Frontend" space. Rails and Laravel don't hold a candle to the experience you get in that ecosystem. But the JS ecosystem is massive and, as a result, fragmented. As you mentioned, there's no consensus on ORMs, mailers, queues, etc. I don't see those frameworks trying to push too far in that direction, they'll remain "UI focused". This is nice for their focus, but not great for someone who wants to launch a web app and doesn't want to figure out all the surrounding ecosystem tooling. This is where Laravel, Rails (and soon Bud) (and I assume Copper) will shine. They provide more tools and interfaces out of the box for building full-featured backends. These frameworks definitely need to keep an eye on the best ideas coming out of the JS framework ecosystem though!

rubyist5eva 4y ago

A rails-like framework will never happen in a language that doesn’t have the same meta programming capabilities as Ruby. Rails exists because Ruby exists not because DHH just happened to be a Ruby programmer. There is a reason people have tried to recreate it in other languages and it always feels jank - because Rails is designed specifically and enabled by the Ruby language.

matthewmueller 4y ago
Code generation provides the same kind of flexibility you get with meta programming, you just need to do more work to keep generated code in sync and out of the way.
- rubyist5eva 4y ago
  Like I said: jank.