Yes the view layer will be introduced in 2.1. We have hanami-view ready but we need to build hanami-assets and hanami-helpers + add integration code to the main hanami gem.
Hanami is not a micro-framework, it is composed of multiple gems though, so if you remove them all you're left with a core of the framework that doesn't do anything except providing an API for plugging in components, configuring them and managing their state.
When it comes to differences - Sinatra is not as feature rich and it's got a less powerful plugin system. Roda has a completely different router using so called Routing Tree, which Hanami doesn't have (it's got something more akin to what Rails has) but it's also highly extendible through plugins, so there is similarity there. A huge difference is that Hanami ships with a very powerful code loading system that supports automatic dependency injection mechanism.
You missed the context of this example - it's just there to show that IF you don't want to use constructor DI, you can put things in lib and they won't become part of the automatic DI system
No good production code allows such things to accidentially happen, so to me, it's the error from framework. What's the point of using a framework if it couldn't help me do silly things then ?
You're right in principle but not in this case. Zeitwerk is not a regular dependency, it's stable and the risk it will change in an incompatible way is very minimal (reminder - it's used by Rails too). When it comes to dry-rb as deps - dry-rb core team == hanami core team. This means we are on top of the things and we'll ensure that things are evolving together w/o breaking anything.
What you're describing should've been reported as a bug because we do use metaprogramming for DSLs but the "runtime" objects are actually designed to have very minimalistic public API. I can assure you we do not put clean syntax above all else but we do like clean DSLs that reduce boilerplate
Haha no it's just an example of a custom directory that you can place under app dir We're still thinking about an abstraction for operation-like objects (I actually started experimenting with this a couple of months ago) but I don't think it will become part of the main Hanami stack.
welp :( I'm very sorry about this. I didn't manage to pay for my old domain because I was recovering after an accident (true story, not making any silly excuses). I was aware that it's about to expire but wasn't in a good physical and mental shape and I just forgot to do it. People keep reporting it to me and we're updating URLs every time somebody finds an old link somewhere. I should probably just search through GitHub and send some PRs...
What makes you think I have negative agendas? My "agenda" is quite positive, I want a Ruby ecosystem where we play by the same rules and Rails is no longer a special snowflake. This way we can evolve faster.
Your articles are very negative. Basically everything involving Rails is bad and wrong by them. That's what i mean.
I want Ruby ecosystem, where everybody is free to do their things the way they want, by the rules they want, for whatever motivations they have. I want to have my special Rails snowflake and i don't want it to ever change because it constantly enables me to build amazing things AND enjoy the process also. And i'm willing to let you have your way and i will respect it but only if you can do the same without being negative about it in every other statement.
If somebody chooses to support Rails and Rails only in their library i think it's very fine and i think the same if there is a library doing the same thing for only Hanami. Or a library supporting both. Or a library not really supporting anything in a special way. I also think it's fine when there is a library which sole function is to monkey patch Object with #forty_two method. And fine it is because there are no rules from you or anybody else forcing me to actually use this thing. So, i will just not use it, right?
So for me this open and free "we" is the only "we" there is and also the only one i want to evolve anyhow.
> Your articles are very negative. Basically everything involving Rails is bad and wrong by them. That's what i mean.
I provide critique that some (probably many) Ruby developers don't like and disagree with but my intention isn't to bash something and make it "all bad". I don't recall saying that everything involving Rails is bad and wrong. I had conference talks sharing my appreciation for Rails and various parts of its philosophy that I agree with and try to incorporate in my own projects. There are also things I don't like that are very problematic and I share this with the community as well.
> I want Ruby ecosystem, where everybody is free to do their things the way they want, by the rules they want, for whatever motivations they have.
Imagine a ruby gem that becomes super popular because it provides some neat features that plenty of companies can benefit from. Then, for whatever reason, this project introduces some great performance optimizations but they are achieved through monkeypatches. Unfortunately it turns out it breaks Rails in some weird, subtle ways, that are hard to debug. Rails core teams starts getting lots of bug reports about some seemingly unrelated problems, just to realize that it's not a problem in Rails, it's a problem in another library.
Does this make any sense? Nope. That's why people don't monkeypatch in their libraries.
From what I gathered, there's some initiative to move Rails to use Refinements via ActiveSupport, if this happens, then the problem is solved.
> And i'm willing to let you have your way and i will respect it but only if you can do the same without being negative about it in every other statement.
It's interesting that you mention respect here - ActiveSupport doesn't respect the rest of the ecosystem. By simply adding new methods to Kernel, Object, NilClass, it reserves them and you really want to avoid having same methods in your library. If you want to tell me "but nothing prevents you from doing this" then you're right, except that I have to think about this because if my lib doesn't work with Rails well, I might as well not build it in the first place because adoption would be non-existant.
> I provide critique that some (probably many) Ruby developers don't like
Yes, maybe that is the thing, i don't like critics. The approach i prefer is to put your money where your mouth is. Why don't you to build this version of ActiveRecord using refinements? Then let others see how good it is
> Imagine a ruby gem that ... Does this make any sense? Nope. That's why people don't monkeypatch in their libraries.
This can happen any day because of infinite types of mistakes a programmer can make. Monkey patching is just one technique you have at your disposal and as with everything else, you have to know when to use it, how and why.
> It's interesting that you mention respect here - ActiveSupport doesn't respect ...
What do you mean doesn't respect? ActiveSupport is a tool without feelings and stances and believes. You can either use it or not use it. And actually i want ActiveSupport to do exactly what it does, patch all the things and give me tons of nice methods i need.
Yeah, so if you want your library to work with Rails, because *you want* Rails users adopt your lib, you have to make some effort right? Well that's how it works with anything. If you don't like it for whatever reason why don't you find some place where they do it exactly your way, or why don't you build it? I mean i like the way how Rails and the other things around work and that's why i use it. So if you want adoptions for your library from me, you have to kind of a do it the same way.
