4 ms·

Somewhat unrelated but, I've been doing a ton of frontend coding past few years (coming from a backend/infra background). I think browser development is an und

Somewhat unrelated but, I've been doing a ton of frontend coding past few years (coming from a backend/infra background). I think browser development is an underrated difficult problem. With a lot of crappy half-assed solutions that don't have solutions at depth that the backend ecosystem has. Like if you get to the essence of it you're syncing two local event loops -- the JavaScript and browser renderer, omitting the JS async queue and webworkers. Then you have a distributed system on top connecting to your backend. And sometimes you have a distributed system across the same local instance of the app, e.g. multiple tabs of the same app. All this with neanderthal grade tools. At every layer of this there are half-thought tools with inconsistent data models that try to connect different layers of the problem (component rendering, data fetching, event loops, background jobs, etc) without any great way to do so. Straight glue. Sure most people call some hook with refresh loop or something and call it day, but the problem still hasn't been solved well for building ultra-rich apps.

n2d4 3y ago
This is the problem that most JavaScript frontend frameworks are trying to solve. Most of them just connect JS and renderer event loops, but some are approaching data fetching and background jobs as well (like React with the experimental `use` hook, or Svelte Query). They do however come with significant complexity for new users, and if you write React code without understanding the underlying event loops, you'll write code with weird edge cases (eg. overreliance on useEffect). But I do think that they solve the problem pretty well once you got past that initial burden of learning them.
- parhamn 3y ago
  > they solve the problem pretty well once you got past that initial burden of learning them. Please do share how the canary `use` hook solves: remote data syncing, proper data sharing across the UI, real-time remote syncing, incremental updates, optimistic updates, realtime collaboration, offline only, etc These are table stakes for good rich apps now. Now your answer is probably going to be to 'use other tools for this' and the lack of cohesion between those tools is what I'm saying is crappy glue. The atoms aren't good.
  - aidos 3y ago
    That’s… not react’s job? React is all about efficiently taking state and rendering it. We use mobx for managing state. We use Hasura for syncing. We use react for display. That works well for us and our requirements.
    - idbehold 3y ago
      > React is all about efficiently taking state and rendering it. You sure about that? https://github.com/facebook/react/blob/main/packages/react/src/ReactFetch.js https://github.com/facebook/react/blob/main/packages/react/s...
      - aidos 3y ago
        I’m searching for ReactFetch and not finding anything. My 10 years in React tell me that react isn’t a library focused on data fetching, maybe I’m missing something and I would happily discuss it if you point me towards some more information.
        dumbo-octopus 3y ago
        packages/react/src/ReactServer.js imports it.
        aidos 3y ago
        I don’t know what reactsever is either. Was looking more for some documentation to show what it is and how it’s used.
      - throwaway290 3y ago
        That's just patching fetch for suspense stuff, and suspense is literally about rendering state. Sure, not a pretty workaround, but nah react isn't trying to be in charge of fetching here.
    - parhamn 3y ago
emadda 3y ago
I've recently been writing a Chrome Extension. It becomes harder when any one of your distributed event loops can be closed/shut down at any time (e.g: content script, service worker, options page). Chrome Extensions with the newest "manifest v3" do not have persistent "background pages" any more, but have "service workers" that Chrome will terminate every 30s.
_heimdall 3y ago
This is a fundamental problem with the standard approach of shipping serialized state and rendering logic to the browser. It simply doesn't scale, and frankly its an asinine approach. Rendering should live inside the same system as the state being used. In most cases that state lives on a server somewhere, though there are plenty of cases where (usually small bits of) state live in the client exclusively and are never sent back to the server. The current approach of leveraging build systems and bundlers to generate RPC calls is only going to make it worse. The goal is to effectively hide obscure the split between backend and frontend, in reality all this will do is lead to a terrible debugging process and countless bugs cause by a misunderstanding of the complex DX required. Worse still, given that any piece of state has to either be the responsibility of the backend or the frontend, we can't blur that line completely and will be stuck papering over it with more and more complex solutions. HTMX has been getting more attention recently. I have no idea if its really the "right" answer for the next few years of web development, but it seems to strike a chord with devs precisely because it goes the way of leaving rendering of server state where it belongs...on the server.
pier25 3y ago
Maybe Phoenix Liveviews?
valand 3y ago
One thing I learnt going from frontend development, to distributed system database, development, and then back: These neanderthal grade tools have the same problem: attempting to abstract away unabstractible problems. The MO of said tools are to limit expressiveness rather than provide context or knowledge. Take the multi-tab syncing you mentioned. Syncing will always take a loop and a buffer, assuming a channel of communication is not a problem. Those can be in a library, in a browser's built-in API, abstracted away, or you can write it by yourself. But when you don't write it, you don't have control over it (e.g. when to sync, how to interlace the syncing with other operations). A better toolings work in the level of paradigm. Instead of simply abstracting, bring complexity to clarity and provide the learning ramp.
anonzzzies 3y ago
I have experienced the same. I am a backend person with 30 years experience who spent 2 years doing only frontend (mostly react) and the tooling is depressingly bad. What is worse though is that (even in this thread) most (all?) libraries scream ‘not our job’, so now it’s no-one’s job then as we don’t have ‘in between’ or ‘frontend/backend sync’ (I avoid middleware on purpose here as that’s already a thing) devs. Phoenix and other attempts are the future here imho. We have, for our saas with a few 100k users, rolled out a phoenix like (we use mostly go server side) next to our initial react/next frontend and a) our devs prefer it massively (write mostly only go and not typescript!) b) our users prefer it because it’s just more natural. With ssr you can accomplish the same but it takes more pain because we still have to think about state syncing etc; with liveview likes we are back to cgi on steroids: just handle it on the server and forget the client. You still have to do state but it’s much easier to reason about if it’s in one place.

n2d4 3y ago

This is the problem that most JavaScript frontend frameworks are trying to solve. Most of them just connect JS and renderer event loops, but some are approaching data fetching and background jobs as well (like React with the experimental `use` hook, or Svelte Query). They do however come with significant complexity for new users, and if you write React code without understanding the underlying event loops, you'll write code with weird edge cases (eg. overreliance on useEffect). But I do think that they solve the problem pretty well once you got past that initial burden of learning them.

parhamn 3y ago
> they solve the problem pretty well once you got past that initial burden of learning them. Please do share how the canary `use` hook solves: remote data syncing, proper data sharing across the UI, real-time remote syncing, incremental updates, optimistic updates, realtime collaboration, offline only, etc These are table stakes for good rich apps now. Now your answer is probably going to be to 'use other tools for this' and the lack of cohesion between those tools is what I'm saying is crappy glue. The atoms aren't good.
- aidos 3y ago
  That’s… not react’s job? React is all about efficiently taking state and rendering it. We use mobx for managing state. We use Hasura for syncing. We use react for display. That works well for us and our requirements.
  - idbehold 3y ago
    > React is all about efficiently taking state and rendering it. You sure about that? https://github.com/facebook/react/blob/main/packages/react/src/ReactFetch.js https://github.com/facebook/react/blob/main/packages/react/s...
    - aidos 3y ago
      I’m searching for ReactFetch and not finding anything. My 10 years in React tell me that react isn’t a library focused on data fetching, maybe I’m missing something and I would happily discuss it if you point me towards some more information.
      - dumbo-octopus 3y ago
        packages/react/src/ReactServer.js imports it.
        aidos 3y ago
        I don’t know what reactsever is either. Was looking more for some documentation to show what it is and how it’s used.
    - throwaway290 3y ago
      That's just patching fetch for suspense stuff, and suspense is literally about rendering state. Sure, not a pretty workaround, but nah react isn't trying to be in charge of fetching here.
  - parhamn 3y ago

emadda 3y ago

I've recently been writing a Chrome Extension. It becomes harder when any one of your distributed event loops can be closed/shut down at any time (e.g: content script, service worker, options page). Chrome Extensions with the newest "manifest v3" do not have persistent "background pages" any more, but have "service workers" that Chrome will terminate every 30s.

_heimdall 3y ago

This is a fundamental problem with the standard approach of shipping serialized state and rendering logic to the browser. It simply doesn't scale, and frankly its an asinine approach. Rendering should live inside the same system as the state being used. In most cases that state lives on a server somewhere, though there are plenty of cases where (usually small bits of) state live in the client exclusively and are never sent back to the server. The current approach of leveraging build systems and bundlers to generate RPC calls is only going to make it worse. The goal is to effectively hide obscure the split between backend and frontend, in reality all this will do is lead to a terrible debugging process and countless bugs cause by a misunderstanding of the complex DX required. Worse still, given that any piece of state has to either be the responsibility of the backend or the frontend, we can't blur that line completely and will be stuck papering over it with more and more complex solutions. HTMX has been getting more attention recently. I have no idea if its really the "right" answer for the next few years of web development, but it seems to strike a chord with devs precisely because it goes the way of leaving rendering of server state where it belongs...on the server.

pier25 3y ago

Maybe Phoenix Liveviews?

valand 3y ago

One thing I learnt going from frontend development, to distributed system database, development, and then back: These neanderthal grade tools have the same problem: attempting to abstract away unabstractible problems. The MO of said tools are to limit expressiveness rather than provide context or knowledge. Take the multi-tab syncing you mentioned. Syncing will always take a loop and a buffer, assuming a channel of communication is not a problem. Those can be in a library, in a browser's built-in API, abstracted away, or you can write it by yourself. But when you don't write it, you don't have control over it (e.g. when to sync, how to interlace the syncing with other operations). A better toolings work in the level of paradigm. Instead of simply abstracting, bring complexity to clarity and provide the learning ramp.

anonzzzies 3y ago

I have experienced the same. I am a backend person with 30 years experience who spent 2 years doing only frontend (mostly react) and the tooling is depressingly bad. What is worse though is that (even in this thread) most (all?) libraries scream ‘not our job’, so now it’s no-one’s job then as we don’t have ‘in between’ or ‘frontend/backend sync’ (I avoid middleware on purpose here as that’s already a thing) devs. Phoenix and other attempts are the future here imho. We have, for our saas with a few 100k users, rolled out a phoenix like (we use mostly go server side) next to our initial react/next frontend and a) our devs prefer it massively (write mostly only go and not typescript!) b) our users prefer it because it’s just more natural. With ssr you can accomplish the same but it takes more pain because we still have to think about state syncing etc; with liveview likes we are back to cgi on steroids: just handle it on the server and forget the client. You still have to do state but it’s much easier to reason about if it’s in one place.