6 ms·

I have a different take on this. I think local-first is the future. This is where the apps runs mostly within user's browser with little to no help from the s

I have a different take on this. I think local-first is the future. This is where the apps runs mostly within user's browser with little to no help from the server. Apps like Figma, Linear and Superhuman use this model very successfully. And to some degree Stackblitz does as well. If somewhat complex apps like Figma can run almost entirely within user's browser, then I think vast majority of the apps out there can. Server side mostly is there to sync data between different instances of the app if the user uses it from different locations. The tooling for this is in the works, but is not yet mature. e.g Electric-SQL. Once these libraries are mature, I think this space will take off. Serverless is mostly there to make money for Amazon and Azures of the world and will eventually go the way of the CGI. WASM could succeed as well. But mostly in user's browser. Microsoft uses it today for C#/Blazor. But it isn't the correct approach as dotnet in browser will likely never be as fast as Javascript in the browser.

jamil7 2y ago
I work on an iOS app like this right now, it predates a lot of these newer prebuilt solutions. There are some really nice features of working and building features this way, when it works well you can ignore networking code entirely. There are some tradeoffs though and a big one has been debugging and monitoring as well as migrations. There is also some level of end user education because the apps don’t always work the way they’re expecting. The industry the app serves is one in which people are working in the field, doing data entry on a tablet or phone with patchy connections.
mattdesl 2y ago
I’m not sure I’d call Figma local first. If I’m offline or in a spotty wifi area, I can’t load my designs. And unless it’s recently changed, if you lose wifi and quit the browser after some edits, they won’t be saved.
- curtisblaine 2y ago
  That's intentional: they need you and your data tied to the server to make money. But there's no reason why it couldn't be local first (except the business model), since the bulk of execution is local. Incidentally, I think that's why local-first didn't take off yet: it's difficult to monetize and it's almost impossible to monetize to the extent of server-based or server-less. If your application code is completely local, software producers are back to copy-protection schemes. If your data is completely local, you can migrate it to another app easily, which is good for the user but bad for the companies. It would be great to have more smaller companies embracing local-first instead of tech behemoths monopolizing resources, but I don't see an easy transition to that state of things.
  - llm_trw 2y ago
    >Incidentally, I think that's why local-first didn't take off yet Local first is what we had all throughout the 80s to 10s. It's just that you can make a lot more from people who rent your software rather than buy it.
    - OtomotO 2y ago
      More and more reliably. When people have an abo that cannot be quit every month it gives more financial security to the company. Previously people would buy e.g. the creative suite from Adobe and then work with that version for many, many years to come
      - curtisblaine 2y ago
        Previously people would crack CS from Adobe then work with that version for many, many years to come :)
        actionfromafar 2y ago
        True but do all those peeople now pay $100 a month to Adobe? Hardly.
        auggierose 2y ago
        If they need what Adobe offers, yes.
        llm_trw 2y ago
        Previously amateurs would crack Adobe software and then get a letter telling them they needed to pay or be sued when they went professional. The cracked software was there to onramp teens into users. Adobe has burned this ramp and now no one under 14 uses it any more which is quite the change from when I was 14.
    - baq 2y ago
      The sweet, sweet ARR. Investors love it, banks love it, employees should also love it since it makes their paychecks predictable. It sucks for customers, though.
- pen2l 2y ago
  A better example than Figma is Rive, made with Flutter. Works well local-first, and syncs with the cloud as needed. Flutter space lends itself very well to making local-first apps that also play well in the cloud.
csomar 2y ago
At the end of the day, all you are doing is syncing state with the server. In the future, you'll have a local state and a server state and the only server component is a sync Wasm binary hehe. Still, you'll be coding your front-end with Wasm/Rust, so get in on the Rust train :)
- meow_catrix 2y ago
  Rust frontend dev is not going to become mainstream, no matter what.
- bryanrasmussen 2y ago
  metaphorically, Rust train does not sound enticing.
llm_trw 2y ago
>Serverless is mostly there to make money for Amazon and Azures of the world and will eventually go the way of the CGI. CGI empowers users and small sites. No one talks about it because you can't scale to a trillion add impressions a second on it. Serverless functions add 10 feet to Bazoz's yacht every time someone writes one.
smolder 2y ago
I also support the development of client side applications, but I don't think they should necessarily be run in a browser or sandbox or be bought through an app store, and it's definitely not a new idea.
torginus 2y ago
Hehehe, so the future is how we used to run applications from before the era of the web.
- flohofwoe 2y ago
  Except with runtime safety, no installation process, no pointless scare popups when trying to run an app directly downloaded from the internet, and trivial distribution without random app store publishing rules getting in the way. In a way - yes - it's almost like it was before the internet, but mostly because other ways to distribute and run applications have become such a hassle, partly for security reasons, but mostly for gatekeeping reasons by the "platform owners".
  - torginus 2y ago
    Apps like these were incredibly common on Windows from the late 90s-early 2010s era. They could do all this (except for the sandboxing thing). You just downloaded a single .exe file, and it ran self-contained, with all its dependencies statically linked, and it would work on practically any system. On MacOS, the user facing model is still that you download an application, drop it in the Applications folder, and it works.
    - flohofwoe 2y ago
      > You just downloaded a single .exe file, and it ran self-contained, with all its dependencies statically linked, and it would work on practically any system. Yeah, but try that today (and even by 2010 that wouldn't work anymore). Windows will show a scare popup with a very hard to find 'run anyway' button, unless your application download is above a certain 'reputation score' or is code-signed with an expensive EV certificate. > On MacOS, the user facing model is still that you download an application, drop it in the Applications folder, and it works. Not really, macOS will tell you that it cannot verify that the app doesn't do any harm and helpfully offer to move the application into the trash bin (unless the app is signed and notarized - for which you'll need an Apple developer account, and AFAIK even then there will be a 'mild' warning popup that the app has been downloaded from the internet and whether you want to run it anyway). Apple is definitely nudging developers towards the app store, even on macOS.
OtomotO 2y ago
I have a different take on this: It depends on what you're actually building. For the business applications I build SSR (without any JS in the stack, but just golang or Rust or Zig) is the future. It saves resources which in turn saves money, is way more reliable (again: money) and less complex (again: money) to syncing state all the time and having frontend state diverge from the actual (backend) state.
- boomskats 2y ago
  I have a different take on this: Business applications don't care about client side resource utilisation. That resource has already been allocated and spent, and it's not like their users can decide to walk away because their app takes an extra 250ms to render. Client-side compute is the real money saver. This means CSR/SPA/PWA/client-side state and things like WASM DuckDB and perspective over anything long-lived or computationally expensive on the backend.
moi2388 2y ago
> Microsoft uses it today for C#/Blazor. But it isn't the correct approach as dotnet in browser will likely never be as fast as Javascript in the browser. Might be true, but both will be more than fast enough. We develop Blazer WASM. When it comes to performance, dotnet is not the issue
- josephg 2y ago
  Yep. And when wasmgc is stable & widely adopted, apps built using blazer will probably end up smaller than their equivalent rust+wasm counterparts, since .net apps won’t need to ship an allocator.
- jmull 2y ago
  I thought the problem was the hefty upfront price to pay for loading the runtime.
  - noworriesnate 2y ago
    There's some truth to this, but there's a new way of rendering components on the server and pushing that HTML directly to the browser first. The components render but aren't fully interactive until the WASM comes in. It can make it feel snappy if it doesn't take too long to load the WASM.
curtisblaine 2y ago
Some applications are inherently hard to make local-first. Social media and Internet forums come to mind. Heavily collaborative applications maybe too.
- swiftcoder 2y ago
  I feel like social media is one of the main things folks want to be local-first. Own your own data, be able to browse/post while offline, and then it all syncs to the big caches in the sky on reconnect...
  - curtisblaine 2y ago
    But how do you do that without essentially downloading the whole social network to your local machine? Are other people's comments, quotes, likes, moderation signals something that should stay on the server or should be synced to the client for offline use? In the first case, you can't really use the social network without connecting to a server. The second case is a privacy and resources nightmare (privacy, because you can hold posts and comments from users that have deleted their data or banned you, you can see who follows who etc. Resources, because you need to hold the whole social graph in your local client).
    - curtisblaine 2y ago
      (unless you want another paradigm of social networking in which you don't have likes, public follows, replies etc., which won't probably fly because it has a much worse UX compared to established social networks)
    - swiftcoder 2y ago
      Usually folks looking for this sort of social network are also looking for a more intimate social experience, so we're not necessarily talking about sync'ing the whole Twitter feed firehose. I don't think it's unreasonable from a resources perspective to sync the posts/actions of mutual followers, and from a privacy standpoint it's not really any worse than your friend screenshotting a text message from you.
createaccount99 2y ago
The frontend space is moving away from client-side state, not toward it.
- bryanrasmussen 2y ago
  the frontend space is always moving in every direction at the same time, this is known as Schrodinger's frontend, depending on when you look at it and what intentions you have - you may think you're looking at the backend.
- nwienert 2y ago
  I think you'll find the real long-term movement is to client-side, not away, and that's because it is both a faster and simpler model if done right.
adrianN 2y ago
CGI is alive and well. It’s still the easiest way to build small applications for browsers.
- chgs 2y ago
  Nobody talks about it because people who use it just use it and get on with their life. It’s painfully easy to develop and host. However it’s likely that generations who weren’t making websites in the days of Matt’s script archive don’t even know about cgi, and end up with massive complex frameworks which go out of style and usability for doing simple tasks. I’ve got cgi scripts that are over 20 years old which run on modern servers and browsers just as the did during the dot com boom.
silvestrov 2y ago
> Figma can [...] then I think vast majority of the apps out there can This doesn't follow. If Figma has the best of the best developers then most businesses might not be able to write just as complex apps. C++ is a good example of a language that requires high programming skills to be usable at all. This is one of the reasons PHP became popular.
jgord 2y ago
I definitely view the browser as an app delivery system... one of the benefits being you don't have to install and thus largely avoid dependency hell. Recently I wrote an .e57 file uploader for quato.xyz - choose a local file, parse its binary headers and embedded xml, decide if it has embedded jpg panoramas in it, pull some out, to give a preview .. and later convert them and upload to 'the cloud'. Why do that ? If you just want a panorama web tour, you only need 1GB of typically 50GB .. pointclouds are large, jpgs less so ! I was kind of surprised that was doable in browser, tbh. We save annotations and 3D linework as json to a backend db .. but I am looking for an append-only json archive format on cloud storage which I think would be a simpler solution, especially as we have some people self hosting .. then the data will all be on their intranet or our big-name-cloud provider... they will just download and run the "app" in browser :]
oscargrouch 2y ago
I worked on something in this space[1], using a heavily modified Chrome browser years ago, but I consider I was too early and I bet something in this lines (probably simpler) will take off when the time is right. Unfortunately I got a little of a burnout for working some years on it, but I confess I have a more optimized and more to the point version of this. Also having to work on Chrome for this with all its complexity is a bit too much. So even though is a lot of work, nowadays I think is better to start from scratch and implement the features slowly. 1 - https://github.com/mumba-org/mumba https://github.com/mumba-org/mumba
lagrange77 2y ago
> WASM could succeed as well. I would guess WASM is a big building block of the future of apps you imagine. Figma is a good example.
sausagefeet 2y ago
> I think local-first is the future. This is where the apps runs mostly within user's browser with little to no help from the server. Apps like Figma, Linear and Superhuman use this model very successfully. The problem is: Figma and Linear are not local-first in the way people who are local-first proponents explain local-first. Both of them require a centralized server, that those companies run, for synchronization. This is not what people mean when they talk about "local-first" being the future, they are talking about what Martin Kleppman defined it as, which is no specialized synchronization software required.
deleted 2y ago
[deleted]
consteval 2y ago
It truly depends on the application. If you have a LOB database-centered application that's pretty much impossible to make "local first". Figma and other's work because they're mostly client-side applications. But I couldn't, for example, do that with a supply chain application. Or a business monitoring application. Or a ticketing system.

jamil7 2y ago

I work on an iOS app like this right now, it predates a lot of these newer prebuilt solutions. There are some really nice features of working and building features this way, when it works well you can ignore networking code entirely. There are some tradeoffs though and a big one has been debugging and monitoring as well as migrations. There is also some level of end user education because the apps don’t always work the way they’re expecting. The industry the app serves is one in which people are working in the field, doing data entry on a tablet or phone with patchy connections.

mattdesl 2y ago

I’m not sure I’d call Figma local first. If I’m offline or in a spotty wifi area, I can’t load my designs. And unless it’s recently changed, if you lose wifi and quit the browser after some edits, they won’t be saved.

curtisblaine 2y ago
That's intentional: they need you and your data tied to the server to make money. But there's no reason why it couldn't be local first (except the business model), since the bulk of execution is local. Incidentally, I think that's why local-first didn't take off yet: it's difficult to monetize and it's almost impossible to monetize to the extent of server-based or server-less. If your application code is completely local, software producers are back to copy-protection schemes. If your data is completely local, you can migrate it to another app easily, which is good for the user but bad for the companies. It would be great to have more smaller companies embracing local-first instead of tech behemoths monopolizing resources, but I don't see an easy transition to that state of things.
- llm_trw 2y ago
  >Incidentally, I think that's why local-first didn't take off yet Local first is what we had all throughout the 80s to 10s. It's just that you can make a lot more from people who rent your software rather than buy it.
  - OtomotO 2y ago
    More and more reliably. When people have an abo that cannot be quit every month it gives more financial security to the company. Previously people would buy e.g. the creative suite from Adobe and then work with that version for many, many years to come
    - curtisblaine 2y ago
      Previously people would crack CS from Adobe then work with that version for many, many years to come :)
      - actionfromafar 2y ago
        True but do all those peeople now pay $100 a month to Adobe? Hardly.
        auggierose 2y ago
        If they need what Adobe offers, yes.
      - llm_trw 2y ago
        Previously amateurs would crack Adobe software and then get a letter telling them they needed to pay or be sued when they went professional. The cracked software was there to onramp teens into users. Adobe has burned this ramp and now no one under 14 uses it any more which is quite the change from when I was 14.
  - baq 2y ago
    The sweet, sweet ARR. Investors love it, banks love it, employees should also love it since it makes their paychecks predictable. It sucks for customers, though.
pen2l 2y ago
A better example than Figma is Rive, made with Flutter. Works well local-first, and syncs with the cloud as needed. Flutter space lends itself very well to making local-first apps that also play well in the cloud.

csomar 2y ago

At the end of the day, all you are doing is syncing state with the server. In the future, you'll have a local state and a server state and the only server component is a sync Wasm binary hehe. Still, you'll be coding your front-end with Wasm/Rust, so get in on the Rust train :)

meow_catrix 2y ago
Rust frontend dev is not going to become mainstream, no matter what.
bryanrasmussen 2y ago
metaphorically, Rust train does not sound enticing.

llm_trw 2y ago

>Serverless is mostly there to make money for Amazon and Azures of the world and will eventually go the way of the CGI. CGI empowers users and small sites. No one talks about it because you can't scale to a trillion add impressions a second on it. Serverless functions add 10 feet to Bazoz's yacht every time someone writes one.

smolder 2y ago

I also support the development of client side applications, but I don't think they should necessarily be run in a browser or sandbox or be bought through an app store, and it's definitely not a new idea.

torginus 2y ago

Hehehe, so the future is how we used to run applications from before the era of the web.

flohofwoe 2y ago
Except with runtime safety, no installation process, no pointless scare popups when trying to run an app directly downloaded from the internet, and trivial distribution without random app store publishing rules getting in the way. In a way - yes - it's almost like it was before the internet, but mostly because other ways to distribute and run applications have become such a hassle, partly for security reasons, but mostly for gatekeeping reasons by the "platform owners".
- torginus 2y ago
  Apps like these were incredibly common on Windows from the late 90s-early 2010s era. They could do all this (except for the sandboxing thing). You just downloaded a single .exe file, and it ran self-contained, with all its dependencies statically linked, and it would work on practically any system. On MacOS, the user facing model is still that you download an application, drop it in the Applications folder, and it works.
  - flohofwoe 2y ago
    > You just downloaded a single .exe file, and it ran self-contained, with all its dependencies statically linked, and it would work on practically any system. Yeah, but try that today (and even by 2010 that wouldn't work anymore). Windows will show a scare popup with a very hard to find 'run anyway' button, unless your application download is above a certain 'reputation score' or is code-signed with an expensive EV certificate. > On MacOS, the user facing model is still that you download an application, drop it in the Applications folder, and it works. Not really, macOS will tell you that it cannot verify that the app doesn't do any harm and helpfully offer to move the application into the trash bin (unless the app is signed and notarized - for which you'll need an Apple developer account, and AFAIK even then there will be a 'mild' warning popup that the app has been downloaded from the internet and whether you want to run it anyway). Apple is definitely nudging developers towards the app store, even on macOS.

OtomotO 2y ago

I have a different take on this: It depends on what you're actually building. For the business applications I build SSR (without any JS in the stack, but just golang or Rust or Zig) is the future. It saves resources which in turn saves money, is way more reliable (again: money) and less complex (again: money) to syncing state all the time and having frontend state diverge from the actual (backend) state.

boomskats 2y ago
I have a different take on this: Business applications don't care about client side resource utilisation. That resource has already been allocated and spent, and it's not like their users can decide to walk away because their app takes an extra 250ms to render. Client-side compute is the real money saver. This means CSR/SPA/PWA/client-side state and things like WASM DuckDB and perspective over anything long-lived or computationally expensive on the backend.

moi2388 2y ago

> Microsoft uses it today for C#/Blazor. But it isn't the correct approach as dotnet in browser will likely never be as fast as Javascript in the browser. Might be true, but both will be more than fast enough. We develop Blazer WASM. When it comes to performance, dotnet is not the issue

josephg 2y ago
Yep. And when wasmgc is stable & widely adopted, apps built using blazer will probably end up smaller than their equivalent rust+wasm counterparts, since .net apps won’t need to ship an allocator.
jmull 2y ago
I thought the problem was the hefty upfront price to pay for loading the runtime.
- noworriesnate 2y ago
  There's some truth to this, but there's a new way of rendering components on the server and pushing that HTML directly to the browser first. The components render but aren't fully interactive until the WASM comes in. It can make it feel snappy if it doesn't take too long to load the WASM.

curtisblaine 2y ago

Some applications are inherently hard to make local-first. Social media and Internet forums come to mind. Heavily collaborative applications maybe too.

swiftcoder 2y ago
I feel like social media is one of the main things folks want to be local-first. Own your own data, be able to browse/post while offline, and then it all syncs to the big caches in the sky on reconnect...
- curtisblaine 2y ago
  But how do you do that without essentially downloading the whole social network to your local machine? Are other people's comments, quotes, likes, moderation signals something that should stay on the server or should be synced to the client for offline use? In the first case, you can't really use the social network without connecting to a server. The second case is a privacy and resources nightmare (privacy, because you can hold posts and comments from users that have deleted their data or banned you, you can see who follows who etc. Resources, because you need to hold the whole social graph in your local client).
  - curtisblaine 2y ago
    (unless you want another paradigm of social networking in which you don't have likes, public follows, replies etc., which won't probably fly because it has a much worse UX compared to established social networks)
  - swiftcoder 2y ago
    Usually folks looking for this sort of social network are also looking for a more intimate social experience, so we're not necessarily talking about sync'ing the whole Twitter feed firehose. I don't think it's unreasonable from a resources perspective to sync the posts/actions of mutual followers, and from a privacy standpoint it's not really any worse than your friend screenshotting a text message from you.

createaccount99 2y ago

The frontend space is moving away from client-side state, not toward it.

bryanrasmussen 2y ago
the frontend space is always moving in every direction at the same time, this is known as Schrodinger's frontend, depending on when you look at it and what intentions you have - you may think you're looking at the backend.
nwienert 2y ago
I think you'll find the real long-term movement is to client-side, not away, and that's because it is both a faster and simpler model if done right.

adrianN 2y ago

CGI is alive and well. It’s still the easiest way to build small applications for browsers.

chgs 2y ago
Nobody talks about it because people who use it just use it and get on with their life. It’s painfully easy to develop and host. However it’s likely that generations who weren’t making websites in the days of Matt’s script archive don’t even know about cgi, and end up with massive complex frameworks which go out of style and usability for doing simple tasks. I’ve got cgi scripts that are over 20 years old which run on modern servers and browsers just as the did during the dot com boom.

silvestrov 2y ago

> Figma can [...] then I think vast majority of the apps out there can This doesn't follow. If Figma has the best of the best developers then most businesses might not be able to write just as complex apps. C++ is a good example of a language that requires high programming skills to be usable at all. This is one of the reasons PHP became popular.

jgord 2y ago

I definitely view the browser as an app delivery system... one of the benefits being you don't have to install and thus largely avoid dependency hell. Recently I wrote an .e57 file uploader for quato.xyz - choose a local file, parse its binary headers and embedded xml, decide if it has embedded jpg panoramas in it, pull some out, to give a preview .. and later convert them and upload to 'the cloud'. Why do that ? If you just want a panorama web tour, you only need 1GB of typically 50GB .. pointclouds are large, jpgs less so ! I was kind of surprised that was doable in browser, tbh. We save annotations and 3D linework as json to a backend db .. but I am looking for an append-only json archive format on cloud storage which I think would be a simpler solution, especially as we have some people self hosting .. then the data will all be on their intranet or our big-name-cloud provider... they will just download and run the "app" in browser :]

oscargrouch 2y ago

I worked on something in this space[1], using a heavily modified Chrome browser years ago, but I consider I was too early and I bet something in this lines (probably simpler) will take off when the time is right. Unfortunately I got a little of a burnout for working some years on it, but I confess I have a more optimized and more to the point version of this. Also having to work on Chrome for this with all its complexity is a bit too much. So even though is a lot of work, nowadays I think is better to start from scratch and implement the features slowly. 1 - https://github.com/mumba-org/mumba https://github.com/mumba-org/mumba

lagrange77 2y ago

> WASM could succeed as well. I would guess WASM is a big building block of the future of apps you imagine. Figma is a good example.

sausagefeet 2y ago

> I think local-first is the future. This is where the apps runs mostly within user's browser with little to no help from the server. Apps like Figma, Linear and Superhuman use this model very successfully. The problem is: Figma and Linear are not local-first in the way people who are local-first proponents explain local-first. Both of them require a centralized server, that those companies run, for synchronization. This is not what people mean when they talk about "local-first" being the future, they are talking about what Martin Kleppman defined it as, which is no specialized synchronization software required.

deleted 2y ago

[deleted]

consteval 2y ago

It truly depends on the application. If you have a LOB database-centered application that's pretty much impossible to make "local first". Figma and other's work because they're mostly client-side applications. But I couldn't, for example, do that with a supply chain application. Or a business monitoring application. Or a ticketing system.