Afterthoughts - Battle of Web Frameworks


Yup, it's Haskell alright
So we had a nice little battle on Tuesday. Around ten people showed up, a few new faces even. This time we covered two Haskell frameworks, Go, Perl and MoonScript. Overall it was a nice session and it might be fun to arrange something like this again. There are still frameworks to discuss.

I've listed some of the entries below:


The sources of Dancer (Perl) and Lapis (MoonScript) entries are not available yet.

Thoughts on the Contestants

Go doesn't count as a framework but it was nice to have it covered still. At least it provided some contrast to the other entries. That said you probably don't want to implement aspects related to web with Go. It excels at data processing, though, and works as an excellent replacement for C.

Perl and MoonScript based solutions were quite "standard" at least from my point of view. It would have been more or less structurally the same using some other scripting language such as Python, Ruby or JavaScript. I think the real differences can be found on the ecosystem level. Traditionally Perl excels at this department.

The interesting thing about MoonScript is that it compiles to Lua. If you have ever used Lua you know it is quite verbose. It is a very simple language, though, and I suspect this is one of the reasons why LuaJIT is so fast. This also helps with that ecosystem part as you can use Lua libraries with it.

Lapis takes quite different approach than most web frameworks. It has been built directly on top of OpenResty. That in turn bundles Nginx core and 3rd party modules related to it. Let's just say speed isn't an issue when using these sort of tools. The primary disadvantage of Lapis at the moment is the fact that it is still at very early stages of development and relies on the benevolence of its author. Despite this its documentation is on impressive level.

The Haskell solutions were on a league of their own. The Warp based one operated on a lower level of abstraction. Snap based one actually seemed like something I might find fun to develop and maintain. I am not sure if it would be easy develop a service with it from scratch. It is so easy to get lost in the maze of abstraction. This doesn't mean Haskell based solution aren't worth studying. Some of the ideas transfer to more "traditional" environments quite well.

Conclusion

It was very nice to see so varied contestants. Even though the format was new and we have not tried something like this before the event went fine. This provided a way to get exposure to tools you would never study yourself.

As I stated in the introduction there are still frameworks to discuss. Perhaps we should arrange another session later. The concept seems cool. Thanks to all contestants and participants for making this happen!

0 comments:

Post a Comment

 
Copyright © Geek Collision