Closed robacarp closed 6 years ago
@robacarp Thanks for opening this issue, I really like crystal but I think something strange is happening in the community. I feel devs enthusiasm is being lost. I tried to come back and use crystal in my daily tasks but I found some negative comments that make me sad, so I moved to other languages for a while :sweat:
I still have some projects built in Amber and I think the crystal tooling still needs some help, so I gonna try to return and fix some things in my spare time. :sweat_smile:
Cheers.
@robacarp I love Crystal and Amber, but currently out of free time.
Hope both projects will grow.
@robocarp I'm very sorry to hear about the situation. My free time is not much currently (at least until the end of September) and my knowledge of Amber and Crystal is quite limited, but I'd like to help as much as I can. I should probably mention though that I totally don't use (and don't plan to) Granite, which is probably main selling point of Amber ATM.
@robacarp I have been focused mainly on granite (which I think needs the most attention) but even there I haven't been able to contribute much. I do appreciate you taking up the mantel and I will try to carve out some time to help.
@robacarp I don't have much free time, but what can I do to help?
I seriously intend to come back in the next few days and at least get it to work well with the the latest crystal version. I love amber and put every weekend and night into it for 6 months which lead to me getting pretty burnt out.
@drujensen @astupidnerd @robacarp @faustinoaq I think one of the most important things would be to get it working with the latest version of crystal and release an update.
Lack of a free time is my biggest issue atm, but I'd love to contribute more and likely do so in upcoming weeks.
What I see is, that at this point in time Amber needs an overhaul - along with more-or-less detailed roadmap, which would IMO help in splitting work directly to the interested parties.
I seriously intend to come back in the next few days and at least get it to work well with the the latest crystal version.
@elorest That's been already done - master
is working fine with Crystal 0.26.0.
@elorest and @Sija - Can a release be cut? Anyone installing from homebrew (following the docs) will run into a show-stopping error until master is released and updated in the homebrew repo.
I'm not sure how much work it takes, but my understanding is that at this point it is all administrative - the code fixes are in.
@robacarp - Thanks for the reality check here. I started a new job in March and started rock climbing. The combination of the two have taken most of my time.
That said, I think I can find an hour or two per week to contribute. I know it isn't much, but at least it could cover communication and maybe some small bug fixes and enhancements.
@faustinoaq - What happened? Did you get negative comments here or from a crystal maintainer?
@marksiemers Good idea, there's a lot of lost momentum because of lack of compatible release atm. I can do it, if someone would add me to @amberframework team.
@robacarp Thanks for opening this issue, I really like crystal but I think something strange is happening in the community. I feel devs enthusiasm is being lost. I tried to come back and use crystal in my daily tasks but I found some negative comments that make me sad, so I moved to other languages for a while 😓
@faustinoaq - What happened? Did you get negative comments here or from a crystal maintainer?
I'm curious too, @faustinoaq could you point some concrete cases?
Let's release this afternoon then. I guess we'll have to build our own home brew tap again? Let's also try to meet and do a video call. Would 5 PDT work to meet?
@sija
What I see is, that at this point in time Amber needs an overhaul
Not quite sure what you mean by that. It was the constant rewriting of everything that already worked well combined with lack of time that burnt me out. Everyone in this thread has mentioned lack of time. Right now I just think we need to stay on top of bugs and a couple reasonable feature requests.
I'm using a 0.7.x version of amber right now in production at work and it works well.
The current code base represents 10s of thousands of hours and contains lots of well thought out and working code. Sometimes necessary changes make some of the existing code less solid and we'll have to rethink some of it. I think that if we were to attempt and sort of major refactor or rewrite right now though we'll probably never have a working release again with the time limitations of the team.
In order for an open source project to remain current it usually needs to be sponsored by a commercial organisation. I have been super busy with a new contract so I have had little time to work on my own amber based project never mind on amber itself. Also I have to admit to a little bit of disillusionment over the perception that the Rails way is the right way and Amber MUST conform to the Rails paradigm so developers coming from Rails feel at home. I feel that the Principle of Proximity has a lot of value and Rails effectively ignores this principle. MVC doesn't mean you have to lump all the models together and all the controllers together, it should just mean you have distinct units with a single responsibility.
From my experience modular and micro service is the right way and monolith is the wrong way, especially for larger projects. Since you never know how big your project will grow from the outset it makes sense to start with the right architecture from the beginning rather than constantly expand your monolith application and eventually end up with an unwieldy application. I am now on a contract that suffers immensely from exactly this problem. So rather than fight a modular versus monolith battle I decided to create my own modular framework based on most of the Amber code. I haven't had time to work on that either :)
@damianham re: microservices vs monolith architecture: I've recently came along this article from Segment, which discusses real world cases of cons and pros of both. Some food for thought FYI, cheers!
I'm pretty new to Crystal and the community. I like it a lot and I'm amazed by the amount of quality work that's been put into everything. Sad to hear that it leans so much on some people to the point of exhaustion. The least I can do is say "thanks" and that I'm very thankful for all the work you guys have put into it and I'm amazed on the quality of everything from examples, to docs and the webpage.
I will try to help if I see something i can help with.
Anyway, can I suggest to add a "Compatability" section or similar in the repo or webpage that gives users a hint that they need Crystal 0.25?
It's OK to lag a bit behind on releases in a new language, but a bit worse when things just don't work.
@cfsamson If i'm correct the latest stable amber is compatible with 0.26.0. It was released today
@Thellior I didn't catch that. Nice timing 👍
Please read about about Amber Development state https://github.com/amberframework/amber/issues/941
@Sija - I'm not sure that you are suggesting an actual re-write, but any time that temptation comes up for me, I re-read this article: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
TL;DR - Lots of software projects that attempt a full rewrite have died, while projects that focused on bug fixes and features survived.
Nope, I've been too toxic, as always. Sorry. Long live Amber!
@elorest @marksiemers Sorry for being vauge about before mentioned overhaul - what I had in mind is: refactoring the hotspots and overall internal cleaning, which I believe would reduce amount of bugs and soften the ground for future contributors. That, along with fixing remaining bugs and docs update I believe would present a solid foundation for newcomers and future feature-expansion. Full-rewrite is of course one of the common mistakes, which can seriously hurt (or kill) a project, especially of such scope.
Roadmap with detailed tasks along with personal assignments and responsibilites (for members and contributors) IMO would be of much help, #941 looks like a good starting point for that 👍
Now isn't the time to have the monolith vs "microlith" debate. Kemal is already a great framework to write micro services in. Amber on the other hand combines many things from elixir, rails and other frameworks. It isn't necessarily intended to be a monolith but like any framework you could write a monolith in it.
Amber is intended to allow building many common use cases very fast. It also pretty easy to just use parts of it.
@vladfaust Nope, I've been too toxic, as always. Sorry. Long live Amber!
WDYM? 😃
My contributions to this framework have usually come in when I am working with the project. I have been focused on a none web server system for a while but I am about to start a web server for something and expect to contribute more. Let me know if there is a core team meeting open to the public I would like to participate.
@vladfaust I know you deleted your feedback but I don't deem this as toxic at all. This is the type of feedback we need. I would love to hear your recommendations and contributions to make Amber better.
Building an app on a foreign foundation is always risky. Building an app on a gigantic foundation which follows Rails magic-blog-in-15-minutes concepts is even more risky because in case of its abandonment you don't really know what's inside and cannot fix it yourself. And oops, there are only a few Crystal developers to hire plus Crystal is not 1.0 yet and any update could destroy your app...
This is all true and exactly why I haven't recommended Amber (or any Crystal framework) for my own company projects. The goal is to have a fully functioning framework available when Crystal becomes 1.0. This project was started Feb 23, 2016 so it's been through a lot of waiting.
Crystal is not Rails, its type system and macros - they require knowledge and time debugging. Therefore I advice business owners to either avoid big Monolith frameworks and use modular and simple ones (which are a plenty at https://github.com/veelenga/awesome-crystal#web-frameworks cough prism cough), or stay with Rails.
I disagree with this. Crystal is actually easier than Ruby for the very reasons you state the opposite. Also, just like Rails, Amber is becoming more modular and we will eventually have some really clean well thought out design patterns. I think most of the code has been refactored many times over (thanks @eliasjpr!) and I find it pretty clean as is.
One of the things we should have done is avoided feature creep. We didn't do a good job avoiding features that would make Amber difficult to maintain going forward. I am hopeful we can rectify some of this and move these features into their own shards, but it will take time.
Big all-in-one frameworks are good when telling about Crystal features (we have Rails but faster), but in a longer perspective it damages the language's reputation just like in this issue.
I disagree again. I don't think this project damages the language's reputation. We do need to keep our spirits up and we have had some core members that have had health issues but Amber is still alive (unlike Amethyst). I am very grateful for the effort that @robacarp took and this Issue is his way of asking for help. It was very effective. ;-)
Also Lucky seems more reliable in that case because it's backed by @thoughtbot if I recall right.
We tried very hard to convince @paulsmith that it would be best to avoid duplicate work on another framework especially in such a small community, but he had a very specific set of goals that he wanted to accomplish and he felt starting from scratch was a better approach. We have been working with him to find components that both projects can leverage and will continue that effort. Paul works at @thoughtbot but I haven't seen Crystal or Lucky on their technical roadmap. I may be wrong about that.
Our goal when starting this was to provide developers an alternative using the Crystal language to Rails, Elixir or Node frameworks which are the dominant replacement for Rails. I think we have done just that and I am excited to see where this goes when Crystal goes 1.0.
Thanks for your feedback, really. Your thoughts and feelings are what we need to hear even if they are critical. I hope you consider helping making Amber lighter and more modular as we start moving to the next phase of improving compilation speeds and code maintainability.
Thanks for the thoughtful responses @drujensen and @vladfaust.
I agree that Crystal can work well with small frameworks like Prism (I’m a huge fan!) and bigger ones like Amber and Lucky. I personally prefer the batteries included approach, but smaller/modular is also great :+1:
Paul works at @thoughtbot but I haven't seen Crystal or Lucky on their technical roadmap. I may be wrong about that.
I work for thoughtbot and one of our benefits is that we get every Friday as an Investment Day. I use this day to build Lucky. I also use a lot of my free time. @edwardloveall has just joined thoughtbot and has also spent a good amount of time working on Lucky at thoughtbot. Over time more thoughtbotters are going to start to build projects and get involved so I imagine contributions will grow. This has been a huge help in getting Lucky off the ground and in continuing its consistent growth. We are also actively looking for a smaller client to use Crystal and Lucky with. I'm hoping that day will come soon :)
We tried very hard to convince @paulsmith that it would be best to avoid duplicate work on another framework especially in such a small community, but he had a very specific set of goals that he wanted to accomplish and he felt starting from scratch was a better approach.
As @drujensen mentioned, when Lucky was announced the Amber team did reach out to see if I’d like to team up with them. I 100% agreed that splitting the community is less than ideal, but I also had some goals I felt were non-negotiable. The main one was preventing errors at compile-time. Every feature in Lucky has been carefully planned to help prevent as many bugs as possible and a lot of the design choices in Amber make that very difficult to do. We didn’t quite align on how to combine efforts so it didn’t happen at the time, but I think this may be the perfect time to reevaluate!
I bring this up because things have changed over the last year or so. Lucky has continued growing in feature set and the team and momentum is strong in part due to the time me and others have at thoughtbot. A company is also using Lucky in production quite heavily (million of requests a month) and @jwoertink has contributed quite a bit due to that. Rather than spending time on Amber, how would you and the Amber team feel about working on Lucky instead? The code base has been carefully crafted, the feature set is focused, compile times are good, and the backing from thoughtbot is making it easier to maintain. Combining efforts might be a great way to use time and ensure Crystal has the best framework possible w/o splitting time and attention.
What do you think? Is this something the team would be interested in? What hesitations would you have about doing this? I think it could be pretty fantastic.
Also, I'm sure there will be questions about how Lucky is "prevent more bugs at compile-time". I've listed a few in the comments here https://github.com/crystal-loot/web-framework-comparison/issues/1
Last I looked lucky seemed to really on macros a lot. I was not confident it would be performance enough for the application size I was targeting. That being said I have not really figured out how much amber uses but it seems like less.
@paulcsmith Unfortunately, we do not have the same goals. But let me be clear, I think this is actually a good thing.
Back in the day, I discussed with @sdogruyol about Kemal at the first Crystal Conference. I let him know that I was working on Kemalyst. We talked about our goals and it was clear he wanted Sinatra and I wanted Rails. He wanted to build a super fast simple framework and I wanted to create a framework that included the kitchen sink.
@elorest started contributing heavily on Kemalyst and Amber. He told me about Amber and thought I should look at it closer. We met @eliasjpr and @fridgerator who were working on Amber. We discussed joining forces and after a couple discussions, we merged Kemalyst with Amber because we felt we had similar goals. Amber is using the best ideas from multiple frameworks. We also have a secondary goal to have a framework with the least amount of friction possible for a Rails developer. This is extremely important if we ever want to bring them over to Crystal.
Your goals for Lucky are different than Amber. As you stated, you want to make sure as many bugs as possible are caught at compile time. This is a fantastic goal but it has a cost. It means you will need to use the crystal language to generate all of your HTML, CSS, JS, SQL, XML, JSON or any other deliverable communication format.
This goes counter to Amber's secondary goal of creating the least amount of friction for a Rails developer as possible. Rails developers will be familiar with a templating language like ERB or Slang. They will feel right at home with the MVC file layout and design patterns. The Amber CLI is very similar to the Rails one and the generators are spot on. Even the migrations and configuration settings are similar.
I think the best we can do is continue to find ways of sharing work via shards. This is a good thing though. We do this with Kemal as well since we use the similar middleware. It will only make our solutions that much more modular and flexible.
Hi, so far I just used Amber in some small private project (which I'm too embarrassed about to link here for now :wink:) to explore Crystal and to see what it is all about and where the pain points are. I must say that Crystal and Amber both tick so many boxes for me personally when I think about the ideal language and framework that I can't help but get very enthusiastic about it.
I don't actually have a web developer background, I mainly work in Linux systems engineering but find myself more and more writing APIs and web frontends to wire stuff together and visualize aspects of the infrastructure. So far I use ruby with rails and it does a great job, but deployment is a pain. I'm really really looking forward to use Crystal in this projects once it is matured into a stable language. (Or before that if I hype the other guys enough WIP)
In my opinion Amber is already an awesome and completely usable project. I had absolutely no troubles getting into it and you can write an application just fine. There are no show stopper to create a production grade application today baring in mind that you have to stay on top of what's happening with Crystal and Amber and maybe reserve some additional time for unexpected maintenance to keep your stuff working with new releases.
We have an internal tech workshop in a couple of weeks where I will pitch the framework and the language to our Rails guys and hope to infect them with my euphoria. I think it is only a matter of time now until first paid exploratory projects get started and more developers flock to Crystal and it's frameworks, and Amber is in a really good position in my opinion.
Keep up the great work and don't let yourselves drag down by people who think you have to be the market dominating force to delver something awesome. I see those people in every project and they always say the same shite, just ignore them :smile:
Last I looked lucky seemed to really on macros a lot. I was not confident it would be performance enough for the application size I was targeting. @wontruefree
This is a great question! I don't know how macros in Lucky v. Amber compare. I would guess they are similar, but I do not know. Someone did a compilation test with a few hundred routes, pages, and models and it was around 30s so I think it is within normal range for Crystal apps :) I would like to see if I can keep the same API with smaller apps. Keep in mind also that any template language like ECR and slang use macros to compile the template, which may also be a cause of slower compile times, but I'm not really sure if it is significant or not.
Your goals for Lucky are different than Amber. As you stated, you want to make sure as many bugs as possible are caught at compile time. This is a fantastic goal but it has a cost. It means you will need to use the crystal language to generate all of your HTML, CSS, JS, SQL, XML, JSON or any other deliverable communication format.
That makes a lot of sense. It sounds like we want to build very different things so sharing code is the best bet 👍 . I do want to clarify that CSS and JS are not done in Crystal, and that using HTML templates in Lucky is super easy: https://gist.github.com/paulcsmith/7769e23902be739f63098bcaa50e40f6
XML, JSON and SQL are done in Crystal in most frameworks. With that said I agree we have different goals and it does affect how things are built. I'm happy to share code through shards. I think that will be a nice way to help out the Crystal community :D
Keep up the great work and don't let yourselves drag down by people who think you have to be the market dominating force to delver something awesome.
I totally agree! You don't have to take over the world to make something great. Good luck Amber team!
I have to say that this open letter was caused by the burnout of some of the contributors of the framework. Amber became a viable framework to be use in production in less than a year, this caused a lot burnout and frustrations etc. So we grew our team of core contributors so we can take a break and we did and now we are here again regrouping to continue to work on Amber.
And we are so thankful of the Amber and Crystal community to be so understanding that we have personal lives to take care of with full time jobs and families. I admire @robacarp for taking the task of keeping Amber up to date. The beauty of Amber is that it has enough of its own heartbeat. The upgrade to 0.26.0 work was done by a community contributor, this is something that we really are hoping for. The idea that the you do not need a core contributor hours to evolve the framework to do the work that you want to see in the framework.
I would like to address some of the comments above:
@wontruefree Last I looked lucky seemed to really on macros a lot. I was not confident it would be performance enough for the application size I was targeting. That being said I have not really figured out how much amber uses but it seems like less.
We stay away from macros as much as possible because this has been recommended by Crystal Core developers. If I speak for the Amber team we see macros as last resource to implement a feature.
@vladfaust Amber, on the other hand, has a goal to be very Rails-ish. It's about Conventions Over Configuration, Controllers, and other magic stuff I personally dislike (in fact, I had Rails -> Hanami -> Sinatra -> Roda path myself in Ruby). It also has it's own ecosystem (smaller though, which increases a probability of a failure in a certain aspect of an app). It has multiple core developers (web: @drujensen 19%, elorest 19%, eliasjpr 16%, faustinoaq 10%; orm: drujensen 33%, robacarp 9%).
There is no magic in Amber. Amber does not generate code in the background nor magically does things for for you, unlike Rails. Any developer that reads the source code gets a clear picture where things are and how they are interconnected. It does not have any fancy pattern, no layer of abstraction more than whats needed and all of this is intentional to enable people to make contributions.
Amber is a community project. The only investments it has is time spent by its contributors. They can go, just like @faustinoaq did. It doesn't have a website such fancy as Lucky's (subjectively) and it's not advertised as much on Reddit and dev.to and Medium. It's because its contributors are many, they don't have time and they might have a bystander apathy. As a result, Lucky has a better chance of acquiring a paying customer.
This is so true and this is the beauty about contributing to Amber you don't have to wait for anyone to open a PR with changes you would like to see. People can come and go as they want openly, only committed up to the bits of code and contributions they have made. This allows others to submit their vision and ideas and evolve Amber. Amber has had a lot of great contributions and @vladfaust you have some great ideas that you can contribute I know because I have seen the great work you have done with Prism and Amber can use some of your ideas to improve but instead you have decided to build your own framework with your own ideas, thats admirable and respectable. I personally wish you take some time to improve Amber params validation based on your work :)
All people to some extent have desires to be acknowledge, have recognition of their work and ideas, Amber is a great avenue for this recognition by promoting you as a core member based on the dedication and contributions you have made. We are true believer of teamwork.
I would like to conclude with the following:
The Amber team does not debate about which is best framework or who's doing it the correct way, we as a team have flaws, the framework can use some improvements and always will. We are doing what we and the Amber community think is best for the users of the framework. When we started Amber there was a fragmented community about 8 Crystal web frameworks existed, none with a finished, complete, working product. Amber brought together the Crystal community and with them it grew and and grew organically because we have supporters that believe in the work that we are doing and understand that this is a truly Open Source project where your ideas will be taken for strong consideration (Ask @damianham and @faustinoaq and @robacarp), we work as a team, we have disagreed, got upset at each other over the direction, but we have also have come together to fix issues, make releases, plan features, all in attempt to deliver to the Community the best work that we can.
Amber has contributed to Lucky, Kemal either patching, sharing code, opening PRs, etc. and has reached out to people in the community to work together, to avoid fragmentation. But it is hard to have everyone working on the same project and aligning ideas, visions and this is why other frameworks exists and I think is a good thing because this is how things evolve, we learn from others as others are learning from us.
We do not have the support of a company such as Thoughtbot, Pivotal or any other company but thats not because of Amber, I have spoken to CTOs of big startups in NYC and each and many of them concludes the same in regards to commiment and it goes something like this "Crystal is a language that has been out there for a long time now and yet I have to see a version 1" because of that people are hesitant to commit to Crystal and or Amber.
Well said.
@Sija I was primarily stating that modular applications and micro services are usually easier to develop and maintain than monoliths. Because 1 company has issues doesn't mean we should all abandon modular and micro service architectures. A monolith application can be modular - my beef is with the Rails way of doing things which becomes unwieldy with larger applications. In my Amber project I organise the code around features (modules) and everything specific to the feature is in the same folder, including all the javascript.
@damianham I'd be interested to see the code or even a sample of one of your feature folders. My main concern around doing something like that is that I feel requiring files could get a little crazy, but maybe that's not actually the case in practice!
@paulcsmith here is a listing of one of the feature folders
damian@:SmartBox$ find src/modules/ais
src/modules/ais
src/modules/ais/ais.cr
src/modules/ais/ais_controller.cr
src/modules/ais/style.scss
src/modules/ais/edit.slang
src/modules/ais/_form.slang
src/modules/ais/_ais_lib.cr
src/modules/ais/show.slang
src/modules/ais/js
src/modules/ais/js/readme.md
src/modules/ais/js/target_list.js
src/modules/ais/js/ais.js
src/modules/ais/js/ais_map.js
src/modules/ais/js/ais_options.js
src/modules/ais/index.ecr
src/modules/ais/index.slang
src/modules/ais/new.slang
What is missing is a file to define routes for this feature. I started this project before working on that PR.
I have a few questions, but I'll ask you on Gitter so I don't clog this up with a bunch of side conversation :) Thanks for sharing!
config/application.cr
require "amber_render_module"
require "../src/modules/**"
src/assets/javascripts/main.js
export * from '../../modules/ais/js/ais';
src/modules/ais/js/ais.js is a React component that gets loaded into a DOM element on 'DOMContentLoaded'
@damianham Both micro and monolith applications have pros and cons. Some use cases would work better with one than the other. In many cases I've seen people abandon a monolith and rewrite as micro services only to realize a couple years later that they have many of the exact same problems.
A poorly written set of micro services is no better than a poorly written monolith. You've essentially just traded function calls for network latency and longer dev setup time
Closing this issue in favor of https://github.com/amberframework/amber/issues/941
Problem:
The bulk of @amberframework/core-team has been offline and unresponsive to the Crystal community. At least one member is understandably busy and intends to contribute further, but the rest have been absent without communication for most of 2018 if not much longer.
The effort to update Amber and the various dependant shards to Crystal 0.25 compatibility was almost entirely me, and 0.26 was no different.
I have not published a release for Amber on 0.26 in an attempt to gauge the community awareness of and sensitivity too defunct maintainership. To raise awareness, if possible.
Risk:
Most significantly, Amber is the landing point for a lot of people evaluating Crystal for the first time. If Amber becomes stale, that diminishes the first time experience of a new Crystal user. This is what keeps me up at night.
A project of this scale cannot continue without active maintainership. Any Amber projects in the wild run significant risk of becoming non-upgrade-able down the line.
Crystal is a lovely language for many reasons, but it is young and work on the foundations means that releases are de-facto not backwards compatible. Every Crystal release runs the risk of crippling Amber significantly.
Future:
If you have work built on top of Amber, and you want Amber to continue, now is the time to speak up and get involved. Code needs refactoring, features need adding.
If this issue does not generate enough interest on some appropriate timeline, I'll do what I can to update the repositories and websites to recommend alternative projects and de-list Amber from the ranks of google, but I do not have admin access to all the various systems in place.
Reason:
The thing that makes me nervous about Amber falling stale isn't that the project is going to end, as all things must. Often this is the nature of open source.
I would like it to not fizzle, spit, and die slowly, taking down people and projects with it. So I'm proposing an active de-comissioning of the project to avoid unnecessary casualties to the Crystal ecosystem, and perhaps spur on interest in other, more viable projects.
Mentions:
In no particular order, these people have made >1 commit to Amber or one of the Amber shards in the last 8 months. I'm mentioning them here because they are most likely to have a vested interest in the continued success of Amber. If you're not interested in this discussion, my apologies for the spam.
@elorest @eliasjpr @faustinoaq @docelic @fridgerator @marksiemers @sija @drujensen @veelenga @damianham @epergo @gabrielengel @shobhitic @katafrakt @mofumofu3n @wontruefree @kevinsjoberg @infernalmaster @c910335 @blacksmoke16 @migeorge @maiha @thellior @adam-stomski