6 ms·

I'm on the fat client train with my company and I nudge my clients that way if they're open. It's just a great way to build a system.

cratermoon 3y ago
Great until you have to support n versions on m platforms and half your customers are enterprisey and stay on a 6-year-old version from before your last LTS version on a now-unsupported platform because they built a core part of their business processes on a a misfeature.
- sp332 3y ago
  Yes but targeting WASM and SQLite minimizes that pain quite a bit.
  - cratermoon 3y ago
    Remember when targeting Macromedia Flash was going to solve the web compatibility and interactivity conundrum?
    - sp332 3y ago
      Yeah? It was targeted for destruction by Apple because it was buggy and insecure, not because it wasn't delivering.
      - password4321 3y ago
        Don't forget horrendous mobile performance (battery drain)!
        MaxBarraclough 3y ago
        Don't forget proprietary.
        sp332 3y ago
        And the lack of accessibility. You generally couldn't even copy and paste text out of it.
    - jchw 3y ago
      > Remember when targeting Macromedia Flash was going to solve the web compatibility and interactivity conundrum? This sounds like the set up for a "No? Me neither." punchline. Certainly one of the features of Flash is that it gave you fairly good consistency across computers, but honestly my perception of Flash wasn't that it was going to solve some grand web problem, but more "oooh look, shiny rollover buttons!" and "ooh look, super obnoxious advertisement that forces people to pay attention to it!"
      - cratermoon 3y ago
        > "oooh look, shiny rollover buttons!" That's the interactivity aspect. At the time, it was the bees knees of UI capabilities.
- BackBlast 3y ago
  I've worked on various forms of "legacy code" for most of my career. As long as the economics line up and the customer is willing to pay for the required support, then it's a fine business avenue. If economics don't line up then you have to pull the plug and set them adrift, which is much easier and more secure with a fat client that runs without a server than say, a complex cloud system.
pxmpxm 3y ago
Ohh can't wait for the inevitable next step of dropping the "web" part of web assembly and doing, ya know, native fat clients again.
- BackBlast 3y ago
  I work with lean, business speculative software mostly. Which means not cross-platform native development is simply not economical to do. I generally need to be able to hit Windows, iOS, Android, and MacOS square on with one code base. A "native" electron or capacitor distribution system is a fine extension of a local-first web client. And an advantage of building fat clients generally is they lend themselves to such distribution models much easier than say, htmx or hotwire. Native fat client have had their benefits and lots of people still prefer them, but always had the drawback of manual data management and installs. Being able to leverage any device you own with a cloud synced local-first client really gives you the best of both worlds. But not all software fits readily within this model.
  - eternauta3k 3y ago
    Why not Java?
    - BackBlast 3y ago
      Java fails on multiple points. First, my list failed to include web because of the context. Web is, by far, the largest and most important platform. Even if I'm building only native installers for a project, I need to be able to build web projects with the same tools to make this work. Java also fails "one code base" requirement as desktop and mobile are very different. The poor iOS support is going to cause it to fail the "square on" requirement as well. No on Java.
- password4321 3y ago
  Excel is a great fat client. Writing a sync in VBA is not, but some of the pieces are already there.
- 3y ago

cratermoon 3y ago

Great until you have to support n versions on m platforms and half your customers are enterprisey and stay on a 6-year-old version from before your last LTS version on a now-unsupported platform because they built a core part of their business processes on a a misfeature.

sp332 3y ago
Yes but targeting WASM and SQLite minimizes that pain quite a bit.
- cratermoon 3y ago
  Remember when targeting Macromedia Flash was going to solve the web compatibility and interactivity conundrum?
  - sp332 3y ago
    Yeah? It was targeted for destruction by Apple because it was buggy and insecure, not because it wasn't delivering.
    - password4321 3y ago
      Don't forget horrendous mobile performance (battery drain)!
      - MaxBarraclough 3y ago
        Don't forget proprietary.
        sp332 3y ago
        And the lack of accessibility. You generally couldn't even copy and paste text out of it.
  - jchw 3y ago
    > Remember when targeting Macromedia Flash was going to solve the web compatibility and interactivity conundrum? This sounds like the set up for a "No? Me neither." punchline. Certainly one of the features of Flash is that it gave you fairly good consistency across computers, but honestly my perception of Flash wasn't that it was going to solve some grand web problem, but more "oooh look, shiny rollover buttons!" and "ooh look, super obnoxious advertisement that forces people to pay attention to it!"
    - cratermoon 3y ago
      > "oooh look, shiny rollover buttons!" That's the interactivity aspect. At the time, it was the bees knees of UI capabilities.
BackBlast 3y ago
I've worked on various forms of "legacy code" for most of my career. As long as the economics line up and the customer is willing to pay for the required support, then it's a fine business avenue. If economics don't line up then you have to pull the plug and set them adrift, which is much easier and more secure with a fat client that runs without a server than say, a complex cloud system.

pxmpxm 3y ago

Ohh can't wait for the inevitable next step of dropping the "web" part of web assembly and doing, ya know, native fat clients again.

BackBlast 3y ago
I work with lean, business speculative software mostly. Which means not cross-platform native development is simply not economical to do. I generally need to be able to hit Windows, iOS, Android, and MacOS square on with one code base. A "native" electron or capacitor distribution system is a fine extension of a local-first web client. And an advantage of building fat clients generally is they lend themselves to such distribution models much easier than say, htmx or hotwire. Native fat client have had their benefits and lots of people still prefer them, but always had the drawback of manual data management and installs. Being able to leverage any device you own with a cloud synced local-first client really gives you the best of both worlds. But not all software fits readily within this model.
- eternauta3k 3y ago
  Why not Java?
  - BackBlast 3y ago
    Java fails on multiple points. First, my list failed to include web because of the context. Web is, by far, the largest and most important platform. Even if I'm building only native installers for a project, I need to be able to build web projects with the same tools to make this work. Java also fails "one code base" requirement as desktop and mobile are very different. The poor iOS support is going to cause it to fail the "square on" requirement as well. No on Java.
password4321 3y ago
Excel is a great fat client. Writing a sync in VBA is not, but some of the pieces are already there.
3y ago