3 ms·

Are you referring to frontend mostly? Would a language like Elm be a good fit for what you're referring to in terms of organization? One of the additional goal

by taosx 3y ago

Are you referring to frontend mostly? Would a language like Elm be a good fit for what you're referring to in terms of organization? One of the additional goals I have is to be able to write type safe APIs between frontend and backend similar to trpc (elysia framework).

austin-cheney 3y ago
That does pose an interesting question. Why is the front end so much more reliant on frameworks? Is it the environment or the people doing the work? Regardless the problem and the result are often the same. The inability to organize logical structures as necessary to complete a flow of business processes hinders which goals one aspires to achieve. In my experience writing large applications in JavaScript the front end (in the browser) and the back end are less different than people typically consider. It could be that many people struggle with the DOM, but anyways it’s all APIs and event handling.
- solardev 3y ago
  I'm sure there's a billion reasons for frontend frameworks not really worth debating here, but I was curious about this: > It could be that many people struggle with the DOM, but anyways it’s all APIs and event handling. Without a framework, how do you usually like to handle cross-component/cross-screen state in the frontend? Like where do you keep track of logged-in state, dark mode, the shopping cart, etc? Do you just like to put that in the backend, or is there a neat way to organize such data in vanilla JS in the frontend?
  - austin-cheney 3y ago
    I keep state in a single object. State management is ridiculously simple but people tend to make it more challenging than it needs to be. I then send the data stored in that object out of the browser as determined by the app for storage at the server. Restoring state is as simple as embedding the state data directly into the static html so that it’s always there as fast as possible every time the page is requested.
    - solardev 3y ago
      Sounds like using "window" as a big global variable, but cached on the backend almost like a manual cookie? Well typed, I'd imagine the dev ex would be similar to a monolithic React context. Seems like it'd work.

by taosx 3y ago

austin-cheney 3y ago

That does pose an interesting question. Why is the front end so much more reliant on frameworks? Is it the environment or the people doing the work? Regardless the problem and the result are often the same. The inability to organize logical structures as necessary to complete a flow of business processes hinders which goals one aspires to achieve. In my experience writing large applications in JavaScript the front end (in the browser) and the back end are less different than people typically consider. It could be that many people struggle with the DOM, but anyways it’s all APIs and event handling.

solardev 3y ago
I'm sure there's a billion reasons for frontend frameworks not really worth debating here, but I was curious about this: > It could be that many people struggle with the DOM, but anyways it’s all APIs and event handling. Without a framework, how do you usually like to handle cross-component/cross-screen state in the frontend? Like where do you keep track of logged-in state, dark mode, the shopping cart, etc? Do you just like to put that in the backend, or is there a neat way to organize such data in vanilla JS in the frontend?
- austin-cheney 3y ago
  I keep state in a single object. State management is ridiculously simple but people tend to make it more challenging than it needs to be. I then send the data stored in that object out of the browser as determined by the app for storage at the server. Restoring state is as simple as embedding the state data directly into the static html so that it’s always there as fast as possible every time the page is requested.
  - solardev 3y ago
    Sounds like using "window" as a big global variable, but cached on the backend almost like a manual cookie? Well typed, I'd imagine the dev ex would be similar to a monolithic React context. Seems like it'd work.