EnglishRecently, through various discussions about the nature of the web and web applications I came up with an intriguing (to me at least …) idea: Web apps should behave like UNIX command-line tools.
Please hear me out and let me elaborate.
Probably the most widespread pattern in modern web app development is that of single-page applications (SPAs). Though that particular term isn’t used as abundantly anymore as it used to be a few years ago the design pattern it promoted still persists:
Web apps that look and behave more like native desktop or mobile phone apps rather than traditional websites. SPAs load all of the required HTML, CSS and JavaScript once on application start and then switch instantly between different views rather than initiate new page loads for different aspects and features of the application.
While there are obvious benefits to this idea, particularly in enterprise / B2B software contexts (users get the user experience they’re used to from desktop applications combined with the rapid, iterative software deployment that comes with delivering software via web browsers) perhaps ultimately the concept is still flawed in that it tries to emulate obsolete paradigms and patterns from the desktop era on the web thereby foregoing the actual advantages of websites and web applications.
The unique characteristics of the web – its USP if you will – are these:
- its openness
- the ability to easily participate
- the ability to connect, mix and aggregate data
- in one word: The link
So maybe, foisting desktop paradigms on web applications – while understandable because somewhat useful – curtails the true potential of the web. Rather than blindly continuing practices and patterns from bygone times we should be contemplating if these patterns and practices really make sense for what we’re trying to achieve or if they’re just cargo cult and there might be a better, more conducive solution.
This is where in my opinion the also time-honoured but still surprisingly fresh Unix philosophy of building applications comes into play. Formulated by Doug McIlroy it specifically states:
- Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
- Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
This got me thinking that this might just be the way how modern web applications should be designed: Rather than the monolithic, megabyte- and feature-rich behemoths we commonly see today web applications should be small tools, each with a specific focus that does one job well but is both open to connect and to being connected to.
Just like a UNIX shell allows you to connect programs and filter their outputs using the pipe (|) mechanism (e.g. ‘ps ax | grep java’ for displaying all Java processes running on a system) web applications should by default provide API endpoints and webhooks that allow you to access their data and act on events, respectively. Perhaps CRUD applications could even provide standard “connect this dataset” buttons to search results, lists and detail views. This button would allow you to have the selected dataset sent automatically to another applications API endpoint when a condition is met (specific time, recurring CRON-like job, dataset contains an entry matching search criteria etc.).
This certainly isn’t a fully-fledged concept yet that can be used right away but I think it’s very much worth pursuing.
There’s an interesting discussion here that delves more into the Unix philosophy and the web and specifically why this idea perhaps has yet to gain ground.