Switch from Slim to HAML

[freesteph]

In light of:

• https://github.com/slim-template/slim/issues/883
• https://github.com/slim-template/slim/issues/891
• https://github.com/slim-template/slim/issues/897

I'm not entirely confident Slim – despite how impressed I am with the actual language itself, beautiful – is going to remain active, so I'd rather we switched to HAML which has seen great performance benefits over the 6.x release.

I remember using HAML back in 2014, and Ruby-Toolbox seems to agree it's a safer choice for the moment being:

https://www.ruby-toolbox.com/compare/haml,slim?display=table&order=score

I've got a branch that enables HAML support in the guide (though it doesn't move the existing templates), so it doesn't seems to be such an effort but I wanted to run it past you @adipasquale, what do you think?

[adipasquale]

👍 yeah I think you're right we should switch to HAML ! let's do it progressively.

[minad]

@freesteph I wonder what you are expecting. Do you expect me to immediately pick up Slim again while sponsoring is tickling in slowly? So far we've reached 25% of the goal. This is a positive result, but still a little bit away from fair, sustainable funding. There have been a few one-time sponsors, which also helps but misses the difficult point of long term maintenance. The hard part of open source is not to create something once or release something once. The hard part is to keep a project alive for longer. Over the years a lot of time and effort went into Slim, this is what could give you confidence. Anyway, of course Haml has and always will be a good alternative.

[freesteph]

@minad I don't expect anything at all. As I said above Slim is an impressive project but open-source support comes and goes and we're just trying to pick something that will make our own project easier to use for a wider community. Please don't take this personally, I've browsed some of the Slim source code and it's absolutely beautiful :) And, looks like development has picked up again so good luck and looking forward to a new release.

[freesteph]

I'm sorry I linked to the issues though, the back-references aren't great. I don't seem to be able to remove them but I'll try and be more careful in the future.

[minad]

@freesteph It is not that I don't understand your doubts. One should always pick the underlying technology which seems most fitting for the purpose (technically well-made, well-maintained, etc). But your references essentially spread doubt before I even started picking it up again, which is not fair. It seems that your project is government funded, so you could have as well considered to allocate some small funding to help the projects your software is based upon.

Anyway I did some maintainance in the last few days and Slim is still in very good shape and was easy to pick up. I was a bit surprised myself to see this. I mean it is a bit odd to praise your own code. Every developer is probably familiar with the embaressement when coming back to older code. What was I thinking?! But actually, @judofyr and I did a good job with the architecture back then. Also note that Temple seems to be driving multiple template engines these days, including Haml.

[adipasquale]

👋 hi @minad thanks for your reply and this great OS library.

I'd just like to hop on and join @freesteph in saying that what we were concerned about was mostly the last release date of the library, and not at all its content, cleanliness or architecture - which are impressive.

We had no intention to belittle Slim in any way. This government funded project is indeed publicly funded and open source. Our internal issues are also public on GitHub, and this issue was mostly intended as a discussions means between me and @freesteph . The automatic inter-repos backlink on GitHub issues was quite unexpected and unintended.

We are also trying to promote Open Source usage and sponsorship in French public projects. However it can be quite a long administrative path. I did decide to sponsor with a (tiny) monthly personnal contribution on my initial discovery of slim's long-term support needs, about the same time we created this issue about switching to HAML.

wishing you the best of luck (and a happy new year!)

[minad]

@adipasquale

I'd just like to hop on and join @freesteph in saying that what we were concerned about was mostly the last release date of the library, and not at all its content, cleanliness or architecture - which are impressive.

Yes, that's understandable. However note that @freesteph also linked to the sponsoring issue. To me it seems that asking for sponsoring itself was causing concerns.

We are also trying to promote Open Source usage and sponsorship in French public projects. However it can be quite a long administrative path. I did decide to sponsor with a (tiny) monthly personnal contribution on my initial discovery of slim's long-term support needs, about the same time we created this issue about switching to HAML.

That's good. I am also a big proponent of open source for public projects. But it is a two sided medal. It is obviously good for the state and the public, since long term maintainance is possible due to the sources being open. Open source also helps in educating people. Furthermore I am convinced that it can help the public save money, which can be used better at other places (social services, education). On the other side are the developers which give away their work for free. In order to make this fair, public projects should ideally include some funds as part of its project planning.

[adipasquale]

done in 4e892319421415e054dcefef7bf03884d5233c84

[czj]

Thanks @minad for you work on slim-template/slim

After all, this issue made us aware of the donation available. We'll sponsor and try to maintain this alternative alive by contributing.

Things come and go in open source, and the "finny" thing is HAML looked like it was abandonned not so long ago !

[januszm]

SLIM, as a language, IMO has more elegant syntax than HAML (no %s) and, interestingly, it allows developers working in different languages to collaborate (eg pug.js has almost identical syntax). Anyways, in the long run, I don't think crowdsourcing will work best. In my opinion, a better way to keep the project alive is to add more maintainers and invite more PRs from the stakeholders themselves (direct contribution via coding).

[minad]

@januszm We tried adding more maintainers over the years and it did not work out. The problem is that you need someone who takes the responsibility and does the groundwork of the maintenance continuously. Therefore the attempt at crowd sourcing. We will see if it succeeds or not.

[minad]

Thanks for the support @czj!