After spending the last week immersed in Witty and re-writing our application from scratch, twice, I have come to appreciate the capabilities of the tool-kit in helping to develop web applications. It has certainly been both a good and bad experience.
Let’s talk about the bad first.
The documentation does not serve newbies very well. Yes, the entire API is documented but it assumes that you already have a big picture grasp of the entire tool-kit. Now, I can say that I do have the big picture in my head as I know exactly where to go look into the API for the solution that I need. However, there are still swaths of API that I have not toyed around with, yet, but will have to use them at some point.
The examples are limited. While there are some genuinely complex examples such as the wt-homepage and widgetgallery examples, these are too difficult for the beginner to grasp. The rest of the simple examples are too simple to be useful. There is a lack of intermediate examples that are small enough to understand and solve complicated enough problems to be useful. There is also a lack of consistency in the techniques used in the examples. I guess that it’s because the examples were created at different times.
Debugging is difficult. Unlike a pure C++ application, GDB is pretty much useless when things go wrong at the browser end. Also, since it’s not a typical web framework, problems at the browser end are also difficult to track down as the user doesn’t write a single line of HTML, CSS, nor Javascript. It’s all generated by the tool-kit. I’m not looking forward to writing unit tests for the modules later.
Now for the good.
We can start building complex web applications that run fast. The tool-kit is only used to write web-applications that are able to exploit modern web technologies. Therefore, it does not need to request a page load each time and the DOM tree can be updated on-the-fly using generated HTML, CSS and Javascript. All these things are generated using C++ and developers do not need to learn any of these things at all.
The application can be properly written to exploit in-memory database objects that sit in the heap instead of having to hit the database for every request and storing the data in the stack. This is definitely a plus and we have exploited this to try to minimise the amount of database queries with objects having a long life-span. I foresee this as a big benefit if the application has to be deployed to handle huge loads.
The built-in web-sockets and HTTP server is also extremely useful as it does not require any setup. The developer does not need to learn how to set up any web nor database server. It also comes with SQLite built in and can be easily switched to either MySQL, PostgreSQL or FirebirdSQL at any point, with minimal change in coding. It even handles DB connection pools and threads automatically.
The built-in ORM is also quite useful to get things started. However, it soon becomes clear that we need to use the ORM intelligently and not rely on it completely. However, with a little tweaking here and there, the ORM works quite well. We can also choose not to map the entire object to the database and leave some object properties as in-memory transient values. This is very useful.
After this, I intend to see if there are others interested in learning the benefits of using the tool-kit to develop web applications. There should be an interest from embedded developers who may want to integrate it into their resource constrained devices.
0 Comments