[HN Gopher] Thin Platforms
___________________________________________________________________
Thin Platforms
Author : feross
Score : 78 points
Date : 2022-05-31 16:33 UTC (6 hours ago)
(HTM) web link (stratechery.com)
(TXT) w3m dump (stratechery.com)
| zmmmmm wrote:
| I don't think thin vs thick is really the right metaphor here.
| The core of the platform services are moving to hosted
| infrastructure that is true, but this is orthogonal to whether
| the client using those services is thick or thin. The main reason
| we see thin clients using them is just that in the short amount
| of time for adoption you can't really do much more than build
| thin wrappers around these things yet.
|
| But then, I have a more cynical take on the whole exercise. There
| isn't much more here than big tech trying to cannibalise /
| sabotage open protocols with proprietary ones, so that they can
| rent seek off the people who get trapped using them.
| mbesto wrote:
| _"Gentlemen, there's only two ways I know of to make money:
| bundling and unbundling."_ - Jim Barksdale
| baybal2 wrote:
| sirjaz wrote:
| The problem is that everything has gone to SaaS application.
| Salesforce is not any better than goldmine is. It is just better
| marketing spin. We need to get back to thick apps, and use
| decentralized methods of collaboration.
| smeagull wrote:
| The irony of course is that Browsers are actually quite
| heavyweight applications that don't run particularly well on thin
| clients.
| paulryanrogers wrote:
| Wait you run browsers _locally_?! All the cool kids subscribe
| to remote browser SAAS
| boringg wrote:
| Not sure what the take away is from reading that. Is it just a
| quick breakdown of strategy that is currently at play with Stripe
| / Teams MS?
|
| Also how has stratechery been doing its been awhile since I've
| read their content?
| nvrspyx wrote:
| Even as a relatively young person that has grown up with the
| internet, I'm not a fan of how much thin clients have eclipsed
| thick clients. I long for the days where offline, local-first was
| the norm. I long even more for when this (hopefully) loops back
| around while also including the advantages of (currently) online-
| only applications.
|
| I often fantasize about a set of standardized CRDTs using a
| relationship-based identity management system to connect people
| via a P2P mesh network, where applications are just "frontends"
| that simply organize and augment that underlying data. I dream of
| how the reliance on centralized servers can be reduced or even
| eliminated, depending on the circumstance.
|
| Perhaps I'm naive in this fantasy's feasibility in being
| implemented and/or in winning the uphill battle with the tech
| giant powers that be. A millennial can dream though.
| seibelj wrote:
| You are describing blockchain applications. "Dapps"
| (decentralized apps) provide frontends to data which is stored
| on-chain. The blockchains themselves are (ideally) run by
| neutral nodes that validate state transformations
| (transactions) and assemble them into blocks. The blockchain is
| a never ending series of state transitions.
|
| Many firms and projects are trying to build a new internet
| based on such principles. For example Verite is a protocol for
| decentralized identity which has very significant backers
| https://www.centre.io/verite
| pclmulqdq wrote:
| The problem is that these firms are trying to do inherently
| networked tasks with a framework that allows a lot of local-
| first computation. A local-first CRDT framework makes sense
| for document editing, and not really for social networking
| (mastodon), loans, or money transfers. Those really need to
| be networked.
| christophilus wrote:
| I'm torn on it, but I think I'm mostly in the thin-client camp.
| I don't have Slack or Zoom or just about anything other than my
| dev tools installed locally. I kind of view Zoom (and most
| opaque software blobs) as a bit sketchy / a virus waiting to
| happen if I install it. But I can use all of these just fine in
| my browser which has a much better (though not bulletproof)
| sandbox than my native apps get. Also, I can use them on Linux,
| which isn't always the case with native apps.
|
| So. In all, SPAs and thin clients for the win, in my book.
| theragra wrote:
| They win, but they are so slow in comparison to the native
| apps, it is a pity. Android-like sandbox + native apps is the
| best approach. Too bad Windows store failed. Also, Linux
| packages (Ubuntu) or even Snaps did not work too well for me
| when I tried last time
| couchand wrote:
| I don't trust Zoom, but that doesn't mean I wouldn't trust
| any video client. Zoom is uniquely untrustworthy in the wide
| world of software.
| ricopags wrote:
| I believe you're describing something quite similar to Tim
| Berners-Lee's work on Solid[0].
|
| [0]https://solid.mit.edu/
| shadowgovt wrote:
| What you seek certainly isn't impossible (it exists!), but
| given the ecosystem we find ourselves in it ramps up the
| challenge by orders of magnitude.
|
| Where you see an architecture like the one you're describing is
| multiplayer videogames. Take Minecraft as example. Every client
| has a relatively full copy of the state of the universe, but
| they also synchronize that state against a server image.
| Problem is, to do that, you need to (naively) write the program
| twice: once as a server with rules (and protocol for
| prioritizing message passing), and again as a client with rules
| (and rendering and I/O). And you need a method for dealing with
| desync where the clients and servers don't agree on history,
| and you have also jacked up the price-point on your client
| hardware.
|
| Let's compare this to the web ecosystem. Here, the goal is to
| get as many users as possible, regardless of where they're
| coming from. How do we achieve? Well, if we use a thick client,
| we'll need to write a server, write a client that can act like
| a local server, and do that over again _per device that will
| act as a client._ And the platforms are heterogeneous and some
| of them (the mobile devices) are dirt-potato-power level (even
| the expensive ones, relative to the performance of a mid-tier
| desktop or laptop machine).
|
| The tools to wrangle the complexity of writing the program
| repeatedly have grown (if you use Node, for instance, your
| client and server can share library code... that seems like
| such a nice-to-have until you find yourself wanting to run a
| regex client-side and discover your server and client libraries
| have different regex dialects!). But the cost of maintaining a
| service structured like what you want is still exorbitant; each
| change requires an update to the server and a parallel update
| to the client application, all the client applications, testing
| on all of them. And you either embrace the complexity and
| maintain different clients for different platforms or you
| lowest-common-denominator it and the client running on the
| beefy PC has the same feature-set as the phone client.
|
| So instead, the model that has won out so far is one where the
| server is thick and the client just handles sending commands to
| mutate server state as it can. Beefy clients might have access
| to more features, but the stronger you make the client the
| harder you make it to get everyone on-board.
| Tangurena4 wrote:
| > _And you need a method for dealing with desync where the
| clients and servers don 't agree on history_
|
| In MMORPGs, the desync frequently occurred from hackers. The
| end result was that all of the processing ended up on the
| server, with the client only rendering what was delivered
| from the server and sending movement/keystrokes to the server
| for processing.
|
| > _the model that has won out so far is one where the server
| is thick and the client just handles sending commands to
| mutate server state as it can_
|
| This is the natural result of having to deal with hackers and
| cheaters. Everybody running online games (re)discovers this.
___________________________________________________________________
(page generated 2022-05-31 23:00 UTC)