The framework wall
When creating a website, it is often tempting to use a so-called web framework. For the website of a friend, I opted for Django, as I had already some experience with it through the second version of my blog. This version, the third one, is a return to the web pre like button fueled by databases, as too much frustration grew out of the previous one.
Just to be clear: I like Django. I’ll just use it as the example, the point I try to make applies to most of the frameowrks. It’s a nice framework, I can get a simple website running quickly, and smoothly. I am sure it is far more advanced than I can imagine. And using Python is always a pleasure. Yet, when comes the need to customize something that was not intended by the framework, it requires quite a time investment to make it happen: re-read the docs in case I didn’t see it before, google with appropriate keywords, dive into the results to see if someone hasn’t solved it already - and if so what is the quality of the solution, try to get that solution working and then… face a wall.
It is possible to climb the wall. It is sometimes well worth the investment if you develop websites for a living for example; knowing Django better - or your framework of choice - is definitively a plus. Yet I am an amateur and I chose to use a framework to get something simple running with not too much effort. The structure of the framework, its paradigm, turn the work into interest and fun. Which was the case until I wanted to have HTML formatting in the text areas in the admin interface, as my friend is not familiar with HTML tags and should not be concerned about it by the way. There are solutions unsing TinyMCE or similar libraries. But to apply them, I have ot climb the wall, and the fun disappears bits by bits. Framework is the right name: you work in a frame. Adapting the frame is not a meagre enterprise; it may well be jeopardizing the whole as the solution is a fix. I will end explaining my friend some html tags.
I could use another framework as well. It is a good excuse to learn a new language, discover another way of looking at the problem, at how it is solved with that tool. But what tells me I won’t face the wall again? By its very nature, a framework has to make decisions to be efficient. Within the frame, erverything is fine. Outside it, it is more complicated.
I would not be against diving in more depth into a framework as long as I would learn reusable things, and not only the framework. Things that are more general than the framework itself. But at this point, since I am going to spend some time, why wouldn’t I be using this time to learn directly the general things? It will be much easier afterwards to look into Django and see how to fix my original issue.
To phrase it differently, I am looking for a library, not a framework. Something lower level but more rewarding considering the general outcome. I am not sure this exists. Just look for the results when looking for ‘web library’. I might end up writing mine, at least I will learn the bare metal of the web. It can be the pet project I am looking for, as long as I develop it for me and keep the flexibility of libraries.