TL;DR Popsicle is our latest experiment. Please check it out at http://popsicle.io to give us feedback! Read along to find out about reasons and approach.
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.
Enter Popsicle
We are thinking of a compact library for building single-page, backoffice web applications. It would be small and provide easy-to-use components with batteries included, covering the most common use cases as a default (think of an infinite scrolling grid with remote pagination and filtering, that should be easily doable in a few lines of javascript). What would make this tool different from what is already out there?
- 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.
- We aim for a lean, functional look designed using HTML5 and CSS3, without any images, for fast and reactive interfaces. No custom javascript layout engine, instead leveraging modern browsers capabilities for laying out stuff.
- 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?
Tasting time
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.