This article misses a big part of the Unix philosophy. Modularity and extensibility are just as important as do only one thing and do it well. Unix works because a lot of small programs can be chained (piped) together to interoperate. Apps often don't do this very well or at all.
> Underpinning it all is the 2nd Unix philosophy of text outputs, so the data one app exports can be imported by another. That’s how you can export your address book from Outlook and import it into Gmail, and it’s the same principle that lets web APIs connect software with built-in integrations and connection tools like Zapier, IFTTT, Segment, and more.
Looks like author mentioned that. I guess, the change is in the name - and perception.
Certainly in perception. In the Unix philosophy, interoperability is central to the function of the program. It seems to me that apps only have this added as a secondary function, if at all. You can't easily fork an email stream so that part of your incoming mail goes to Outlook and part to Gmail, say based on subject or sender.
Depending on what you consider "easy" that could be untrue. If you used your public email address as "ingress" you could auto-forward to zapier, which would in turn forward to a gmail only address or an outlook only address conditionally.
It's a little tedious to set up, but no code has to be written.
To be fair, I think the microservice architecture addresses this idea on the web. Moving towards smaller interoperable pieces is something that the internet has been doing for a bit Imo
I kind of, very minimally understand the comparison. But it doesn’t hold up on any dimension. As a thought experiment, could you write a script that tied together “web apps” that only invoked the apps through some kind of interface? No you can’t because they don’t have a uniform interface.
The fact that (some) web apps transmit data via an API, which is text, doesn’t mean that text is their primary interface.
Also, what web application does just one thing today? The most popular ones are absolute seas of features. Unix commands also became fairly poor at sticking to this, but nowhere near to the level of web apps.
That "web-apps built around collaboration" played a major role, is clearly wrong, web-apps have plenty of defensive mechanisms that prevent flexible use from within programs (i.e. bots) or reuse of the output (scraping).
The web was simply a working cross-platform and usable over the network environment despite the bad performance, additional hardware (connectivity) requirements and developers found these advantages significant enough to prefer building web-apps over desktop equivalents. Unfortunately, because major websites are still a PITA to use and [would] greatly benefit from native implementations (FB, Twitter, Youtube...).
Calling Unix philosophy a ״philosophy” is being overly generous. It’s a mindset shared by many early computing hackers, propagated through the times because it’s simple and easy enough to follow. See “worse is better” for why this has been a detriment for the software industry.
As for webapps, they have nothing to do with unix philosophy and much more to do with Steve Jobs, iphone apps and too many non technical product managers angling to push out “products” (also an aspect of the whole MVP and ship early mentality)
Why should it matter that much whether people search for "app" or "software"? There are different types of programs. There are big desktop programs. There are useful mobile device programs of all sizes and shapes. There are games that run on various devices.
The market shows that people like free stuff and cheap little programs ('exercise workout timer on your iphone') but will pay for a zillion features (AutoCAD, Lightroom, Tableau, the AWS ecosystem are examples).
Even the variants of Unix tools with a lot of features seem to have won in the marketplace of ideas.
