Feeling the heat
Over the last few years we’ve been working mainly on creating backoffice web applications, with rich UIs for our clients. This kind of applications are targeted mostly to desktop users and require more or less the same widgets and components. We often found existing tools to be suboptimal for this specific job, here’s why:
- on one extreme we have all-encompassing frameworks that force us to work “inside the box”, while at the other we spend a lot of time integrating and bolting together several individual small libraries each doing one specific thing in its own way.
- some solutions reinvent every possible wheel, needlessly adding complexity and requiring us to learn yet another tool.
- while trying to reach the widest possible audience is a laudable goal, having to support a wide number of browsers and use cases require extensive configuration and lots of maintenance. This in turn leads to …
- lack of reasonable defaults in widgets/components. When building backoffice apps, most of the time you require the same components working in a dependable manner.
We feel the need for something different.
- We are a very opinionated bunch and so is our software. We are not trying to please everyone: by reducing scope we can focus on the most valuable use cases for our target audience and create a better experience for both developers and end-users.
- We want a library, not a framework, something that you call into, not something that forces you to model your application after someone else’s idea. At the same time …
- We don’t want to reinvent the wheel: templating, charting, etc. can be handled by third party, well established libraries (handlebars.js, D3, …) that developers already know.
- Easy to hack. We know that even in well-thought, well-tested code (and that’s one of our primary concerns) there will always be things you’ll want to change (e.g. for bugs), so we will never remove your ability to poke at things.
Will it melt?
Being convinced of the lean principles to software development, on the other hand, we thought it would be prudent to validate our assumptions before committing to the significant effort of building such a beast. Do others have the same concerns as we do? Can we expect companies to mandate the use of modern, up-to-date web browsers for intranet applications? Can the project be self-sustaining?
Right now our MVP is a basic set of components and widgets to demonstrate the approach and to set up a presentation website: you can see it as it is here. Next step, gathering lots of feedback to see if there is interest in it. If we receive enough positive feedback we’ll move forward with this idea, otherwise we’ll pivot to something else.