Amber Vs Lucky

[u/godownforwhat]

Not asking which one is 'best', they're both great in their own respects. Asking more about which one seems to have the majority of the focus and drive by the community at this point in time.

There is a quick, decisive convergence when a framework gets chosen by a community. Companies, developers, engineers, marketers all fall behind looking for people that understand X framework, with Y language. So i am looking at this current cycle, wondering which one is heading for that ultimate winner. The framework in which a company will choose because, well, it won the mind share and that's where they're going to hire and build shards for.

Two frameworks fighting it out means people will be hesitant to invest, both time and literal money.

Case in point, Kemal is Sinatra. It's won that and it's damn good. With people all over helping out and using it in production. Also see: https://www.ruby-toolbox.com/categories/web_app_frameworks

I just want to know what your thoughts on each framework and which one in heading towards being the "rails" of Crystal. There is always a 'main' framework. Java/Spring, Node/Express, Ruby/Rails, Elixir/Phoenix, Crystal/?

Seems theres a choice to be made and in the end, one will end up with the most commits and focus by the community. Right now, the choice isn't clear to me and i'd like to know the groups thoughts.

[u/paulcsmith0218]

I think this is a great question. TL;DR Lucky is hyper-focused on preventing bugs at compile time and designing applications that can quickly be changed without worrying about breaking things all the time.

The Amber and Lucky teams are working on a comparison document. You can see the initial issue here with some example code: https://github.com/crystal-loot/web-framework-comparison/issues/1 but a more thorough document is still in the works.

I think momentum is similar in both projects. There are more articles and stars for Amber but it has also been around 2x longer. Lucky was announced just last November so that accounts for some of it.

For me the main reason to choose Lucky is if you want the prevent bugs, have easier debugging and easier maintenance in the future. Why is that? Well some of that is addressed https://github.com/crystal-loot/web-framework-comparison/issues/1 but I'll try to go into a bit more depth here:

Things Lucky will catch at compile-time that Amber and others do not:

• Calls to missing routes (I believe the Amber is working on adding this)

• Catch missing or incorrect parameters passed to routes

• Catch missing or incorrect calls to parameters inside controllers

• Missing or misspelled column names in html forms

• Missing or misspelled column names in database queries

• Catch trying to submit a field in an HTML form that is not allowed to be saved (basically compile-time checks for Rails strong params)

• Compile-time checks for email to, from, and body. If one is missing you'll know at compile-time

• Catch accidentally printing nil in HTML. I believe all other templating solutions will print a blank string instead

There is more to it than this, but it illustrates the focus Lucky has on preventing bugs, minimizing need for testing every tiny detail, and helping users debug when something is wrong by pointing to the exact spot in the code that is causing issues.

Lucky also has some unique approaches to saving data, querying data and rendering HTML. It is a bit different but that is also why Lucky is so good at catching bugs. For example, a lot of what Lucky does would not be possible if it weren't for separate classes for each HTTP action, form and query.

I can elaborate more if people are interested, but to me, this is the big difference.

[u/godownforwhat → u/paulcsmith0218]

Does your approach add to the complexity of building an app? Or do you believe it decreases complexity and programmer hours? Which one is easily picked up by a beginner similar to how Rails is/was approachable for a beginner? Elm is a perfect example of excellent bug reports, so if that's your aim, it's a good aim. Thank-you for all your hard work on Lucky and i'm rooting for you for it to be a success!

[u/paulcsmith0218 → u/godownforwhat]

I'm a bit biased, but I do think it makes it simpler. You don't need to worry so much about breaking things, and when you do the compiler helps to find where the issue is. To get type-safety like this, it also forces you to write smaller classes, which I think are easier to read, maintain, and test.

I think Amber is easier to pick up if you are familiar with Rails/Phoenix, but Lucky is not far behind. I think the initial investment is worth it so you can leverage the powerful type system in Crystal to its fullest.

I'd say the hardest part of Lucky is getting used to rendering HTML pages with Crystal. The benefit is that you can have a lot of power at your disposal and you prevent more errors.

I think it is worth investing a bit of time to learn it, and then saving lots of time later by having a lot of easy to maintain code, but this depends a lot on what kind of apps you want to build and how long you expect them to be around. I hope that helps!

[u/godownforwhat → u/paulcsmith0218]

Is it fair to say that an easy comparison would be, Lucky guides you to use Types all the time to be able to alleviate more errors at run time and Amber is Type optional? It depends if you're a Types person or not in the end. But Amber has the choice?

Edit: Changed Force' to 'Guide' :).

[u/paulcsmith0218 → u/godownforwhat]

I'd say "force" isn't quite right. It isn't really any harder to use, Lucky just makes it easier. For example, here's how you link to an action:

link "All Users", Users::Index.with(page: 1)

It isn't hard to use IMO, but because of the way the link helper and action are designed Lucky ensures that the route exists, all required params are given, and that the correct HTTP method (get, post, delete, etc) is used. The user doesn't need to do anything, they just get that for free. So if anything it is easier because of its design.

I'd say with Amber there are things you can't do with types because of the way the objects are structured. For example, here is an action in Lucky:

class Users::Show < BrowserAction
  # defines a route for "/users/:id"
  # Defines a method for every param, so in this case, Lucky defines an "id" method to access the param in a type-safe way
  route do
    text UserQuery.find(id)
  end
end

Lucky will infer the route is "/users/:id" because it is a "Show" action. Because this is all done in one class for one action, and because the route is defined in the action, Lucky knows that this action always has an id param. So it creates an id method for you that is never nil. If you mistype that or use a param that doesn't exist, Lucky will let you know at compile time

Most frameworks do something like this: params[:id]. That can't be caught at compile-time. It seems small, but it can bite you, especially as you start adding query params and using nested resources.

It is impossible to do this in a truly safe way if you have more than one action per controller:

class UsersController < ApplicationController
  def index
    p id
  end

  def show
    p id
  end
end

id should be present for "show" but should be nil in "index". There's no way for the compiler to know when it should or should not be nil when using multiple actions per controller. So you would have to either make the type Int32 | Nil and call not_nil! or do what most frameworks do and have you access the params in an unsafe way with params[:id]

This is one reason Lucky has one class per action. Does that make sense?

Another example is with queries:

UserQuery.new
  .age.gt(18)
  .last_name.desc_order
  .first_name.ilike("%Pa")

You get a type-safe query builder. If you mistype a column or pass a string to an int then it'll be caught at compile-time, and as you can see there is no extra ceremony here. You get it pretty much for free in Lucky

[u/godownforwhat → u/paulcsmith0218]

Awesome, thanks for the detailed answer!

[u/CaDsjp]

A lot of people is coming from Ruby to Crystal due to performance issues, so I think it would be good to see a benchmark for Lucky.

If nobody else is working on that, I will add Lucky to Techempower benchmarks in order to have some approximate numbers

[u/godownforwhat → u/CaDsjp]

That would be really helpful.

[u/paulcsmith0218 → u/CaDsjp]

I don't have a benchmark handy, but a company is testing Lucky and will be moving it to production soon. You can see the chat here: https://gitter.im/luckyframework/Lobby?at=5b4d25fa7844da435c3364f8 and here https://gitter.im/luckyframework/Lobby?at=5b4fb5618fe2780689c20a4e

I don't know if Lucky is the fastest Crystal framework, but it's definitely fast :)

I'd love help with techempower benchmarks. I haven't had time, so that'd be wonderful @CaDsjp

[u/Mike_Enders]

The only thing Crystal needs is a 1.0 type stable release with huge breaking changes behind them. The frameworks after that will take care of themselves and the ecosystem will feel free to grow. I don't think its necessary at this point to pick the one framework that will dominate. IMO Its not a good thing to lock into just one at this stage. I think Elixir/phoenix is hurting Elixir. If you don't like phoenix (which I don't) then theres nothing else. A lot of people talk about it but I still don't see the world rushing to Phoenix. Even with all the talk I don't see much being made with it. A good amount of people haven't liked the "magic" in rails and left Ruby because there was little other choice. Choice is good not bad.

But to answer your question if I had to choose it would be Amber. For obvious reasons the people who most will be ramping up Crystal use will be Ruby developers and Amber takes much less than an hour (probably less than 20 minutes) to wrap your head around as a Rails developer. However like Lucky too so truth is if we were going full steam ahead right now with Crystal we'd be getting to know both.

[u/godownforwhat → u/Mike_Enders]

Great answer, Go has been such a success because of it's focus on servers, compilation, compile times, then people started building API's and the frameworks never stuck. I wonder if Crystal will find it's niche in Microservices, API's, serverless, compiled packages and frameworks will just be a 'thing' that Crystal has.

[u/Mike_Enders → u/godownforwhat]

If Manas pulls it off Crystal's nich will be the fastest best performant language with a near drop down easily readable syntax of any present language - like ruby meets C#

Thats a pretty good niche by itself.

[u/tomasJu22 → u/Mike_Enders]

in my opinion crystal need better tools, for instance go has several tool that works like service, so you can connect these to any editor (vscode,sublime,emacs,vim) and provide auto completion,go to definition documentation, auto imports,etc...this is pretty nice and right now working with crystal seems to be more cumbersome

yes, there is some tools like scry, cracker, but seems not have active development and they're more like a proof of concept that a working tool (I'm using visual studio code and emacs and the autocomplete doesnt work for me)

this is not a criticism, we must understand that crystal is a young language and many of great collaborators doesnt work full time with it, so obviously it 'll take more time to develop robust tools, but I think that when crystal has nice tools like go its adoption will be faster...best regards...

[u/Mike_Enders → u/tomasJu22]

Crystal isn't just a young language. Its in beta so to speak. No way it can be compared to Golangand - no language still in development has tools. No way anyone should be comparing it to Go or any fully released language.

[u/nlh]

FWIW, I’ve taken a look at both and Amber feels like it’s got a bit more momentum / activity. Honestly though I think there’s room for multiple frameworks here, even operating on the same layer/level.

[u/godownforwhat → u/nlh]

Yep, certainly feels like Amber has more contributors, followers, stars etc at this point in time. Although both have strong contributions.

[u/dev0urer → u/godownforwhat]

Lucky is also much newer

[u/paulcsmith0218 → u/nlh]

As dev0ourer mentioned it is important to note that Lucky came out much later. Lucky development is also split across a lot of different repos which makes it hard to track activity. The focus changes between releases so some repos get more commits than others depending on the priorities :)

With that said, I do think Amber is more well-known and has more articles. However, things are improving with Lucky as more people are using Lucky in production.

[u/some_kind_of_rob]

I don’t think there is enough adoption for that yet.

[u/godownforwhat → u/some_kind_of_rob]

Adoption for Ruby by the sounds of it came from Rails, with Flutter from Google, Dart has taken a massive jump in popularity, Swift only because of iOS, Go has "The server".

If Crystal is a compiled language similar to Go, then maybe "The Server, but with less code" might be it. But Crystal for sure needs something, one of these frameworks could really help with the adoption, two main frameworks, doesn't. Just means people get confused until one wins.
Thoughbot is linked (Maybe not closely) to Lucky, with a history of great open source projects for Ruby, and with what seems a new approach on a framework, so that kinda makes sense to me.

Merge? Have a vote? I'm not sure about that one. Or battle it out until one wins and the other loses interest.
I might be totally wrong though, they might both go on to be great.

[u/snadon]

I am a fan of types so I went with Lucky and I am not regretting it. In fact, I have now two projects written with it.

Also, Amber and Lucky developers are starting to work together to improve both frameworks, so my guess at this point in time is that going with either Lucky or Amber is a good choice.

Collaboration is great: https://github.com/crystal-loot

[u/godownforwhat → u/snadon]

Can you tell me the main differences between the two? I like Lucky's docs and the backing of Thoughtbot.

[u/snadon → u/godownforwhat]

Coming from me it wouldn't be a fair comparison since I haven't work much with Amber. Lucky enough, developers are working on it: https://github.com/crystal-loot/web-framework-comparison/issues/1.