7 ms·

What code are you using to reactively render state? Or do you write all DOM manipulations manually and just accept the problem of state explosion?

by WA 1y ago

austin-cheney 1y ago
Here is an example: /lib/dashboard/dashboard_script.ts https://github.com/prettydiff/webserver https://github.com/prettydiff/webserver When you aren’t using framework like components state restoration is a single function that runs only on page load. There is no state explosion and on localhost the SPA fully renders and finishes state restoration in about 105ms from http request.
- WA 1y ago
  Thanks, but this is a server-side thing and has nothing to do with client-side DOM manipulation?! Sure, you can put stuff on the server and do HTTP over the wire. It's oftentimes the better solution. But there are apps/tools that are rightfully an SPA (like tldraw or excalidraw for example) and can run local-first and offline in a browser. You build the entire app in JS and you'd need a bit more than vanilla Web components for that if you want to avoid client-side state explosion.
  - austin-cheney 1y ago
    Look at the file path I specified. That file runs only in the browser.
- brazukadev 1y ago
  Mate, if you are proud and happy to code this way, congratulations. That code is an absolute nightmare tho. Your eyes are trained on it so you think this is as good as an ergonomic framework.
  - austin-cheney 1y ago
    How would you refactor it?
    - brazukadev 1y ago
      Is it some bundled code or those ~4k lines are written just for that case? You don't reuse even your own code? I would start by organizing the code in a sane and logical way. But that's why I said, if you enjoy coding this way, great.
      - austin-cheney 1y ago
        It is arranged in objects defined as TypeScript interfaces. It can be easily broken down into numerous smaller files and be equally organized, but then the code would be in multiple places without any benefits except that there would be fewer lines in one file. I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript. If they aren't also writing code outside the browser they are likely never exposed to application code in any real form because all they see is template abstractions. The reality is that it is just JavaScript which is no different in the browser compared to in Node, except for calling a different API. If this is the case then anything that isn't JSX is cause for an anxiety attack, most especially if its more than 120 lines of code. If you are not capable of reading code then no matter of alternate guidance will matter.
        brazukadev 1y ago
        > I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript. I knew anything I said your answer would be something in this line. You think what you wrote is amazing but it is just verbose bad abstraction. If you think the difference between 4k lines of code and separated logical modules is just a matter of fewer lines (which might not even be the case), there is nothing I can say to you but it is funny that you use this terrible code as an example. You literally wrote all DOM manipulation repetitively and inefficiently by hand. But it makes you proud! Congratulations, I guess. I couldn't care less about JSX tho you made too many assumptions about someone that thinks the example code sucks.
- deleted 1y ago
  [deleted]
- MrJohz 1y ago
  First off, thanks for sharing this, because I've seen a lot of your comments on these sorts of threads about web development, and it's helpful to see what your approach looks like in practice. There are a bunch of amber flags that immediately stand out, like this being an almost 4k line file with a commit history by only one person, and an idiosyncratic approach to naming and formatting. None of that is necessarily bad on its own, but this feels like code that is written by the author for themselves, rather than for any other potential readers of the code. It's a lot easier to write code if you're the only reader, because you can keep a lot of the code's context in your head, and you don't need to write it down in the same way. I skimmed through the start of the file and then jumped up the bottom looking for an entry point. From there, the table state jumped out to me as a thread I could follow, so I started exploring that. The first thing that jumped out at me was how much defensive programming you are doing. There are lots of "if state X is not null" or "if event is not null" sections where it's not clear from the types or the logic that these values can ever be null. This makes me a bit nervous, because if you don't know whether something can be null or not, the reader is going to find it even harder to tell. The next thing I noticed was how difficult it is to follow state changes around. Part of this is state being set in multiple places at once (e.g. `state.tables` and as data attributes on elements), but also because you use both `.dataset.xyz` and `"data-xyz"` fairly interchangeably, which makes it difficult to jump to the usages of some bit of state if that uses a different syntax. This got me (finally) to some of the DOM manipulation code, which is what I was just eager to see in the first place. I landed in the tables.populate function, and the most surprising thing that jumped out to me here is that every table seems to be special-cased with a bunch if-else statements, partly for the rendering of each row, and also for updating the payload. Searching through this code, it seems like this mechanism of switching on the type of each module/table is all over the place, and that updating one part of the code is going to have massive knock-on effects on other parts of the code as well. I'm going to stop here because I need to get on and do other things. I agree with you that you have largely managed to avoid building your own framework, but I think this is very much to the code's detriment: a small amount of abstraction would go a long way here in terms of, e.g. isolating the different tables from each other, or managing state effectively. I can fully believe that you find it easy to write and maintain this code, but I suspect that has a lot more to do with you being the sole maintainer of this code than it does the clarity of the code. I see people confuse these two ideas a lot, but it's important to separate them. Like I said at the start, I'm grateful for the chance to see your approach, and if it works for you then my opinion if it doesn't really matter. But it unfortunately does not convince me of your claims about the benefits of this style of development.

What code are you using to reactively render state? Or do you write all DOM manipulations manually and just accept the problem of state explosion?

by WA 1y ago

What code are you using to reactively render state? Or do you write all DOM manipulations manually and just accept the problem of state explosion?

austin-cheney 1y ago

Here is an example: /lib/dashboard/dashboard_script.ts https://github.com/prettydiff/webserver https://github.com/prettydiff/webserver When you aren’t using framework like components state restoration is a single function that runs only on page load. There is no state explosion and on localhost the SPA fully renders and finishes state restoration in about 105ms from http request.

WA 1y ago
Thanks, but this is a server-side thing and has nothing to do with client-side DOM manipulation?! Sure, you can put stuff on the server and do HTTP over the wire. It's oftentimes the better solution. But there are apps/tools that are rightfully an SPA (like tldraw or excalidraw for example) and can run local-first and offline in a browser. You build the entire app in JS and you'd need a bit more than vanilla Web components for that if you want to avoid client-side state explosion.
- austin-cheney 1y ago
  Look at the file path I specified. That file runs only in the browser.
brazukadev 1y ago
Mate, if you are proud and happy to code this way, congratulations. That code is an absolute nightmare tho. Your eyes are trained on it so you think this is as good as an ergonomic framework.
- austin-cheney 1y ago
  How would you refactor it?
  - brazukadev 1y ago
    Is it some bundled code or those ~4k lines are written just for that case? You don't reuse even your own code? I would start by organizing the code in a sane and logical way. But that's why I said, if you enjoy coding this way, great.
    - austin-cheney 1y ago
      It is arranged in objects defined as TypeScript interfaces. It can be easily broken down into numerous smaller files and be equally organized, but then the code would be in multiple places without any benefits except that there would be fewer lines in one file. I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript. If they aren't also writing code outside the browser they are likely never exposed to application code in any real form because all they see is template abstractions. The reality is that it is just JavaScript which is no different in the browser compared to in Node, except for calling a different API. If this is the case then anything that isn't JSX is cause for an anxiety attack, most especially if its more than 120 lines of code. If you are not capable of reading code then no matter of alternate guidance will matter.
      - brazukadev 1y ago
        > I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript. I knew anything I said your answer would be something in this line. You think what you wrote is amazing but it is just verbose bad abstraction. If you think the difference between 4k lines of code and separated logical modules is just a matter of fewer lines (which might not even be the case), there is nothing I can say to you but it is funny that you use this terrible code as an example. You literally wrote all DOM manipulation repetitively and inefficiently by hand. But it makes you proud! Congratulations, I guess. I couldn't care less about JSX tho you made too many assumptions about someone that thinks the example code sucks.
deleted 1y ago
[deleted]
MrJohz 1y ago
First off, thanks for sharing this, because I've seen a lot of your comments on these sorts of threads about web development, and it's helpful to see what your approach looks like in practice. There are a bunch of amber flags that immediately stand out, like this being an almost 4k line file with a commit history by only one person, and an idiosyncratic approach to naming and formatting. None of that is necessarily bad on its own, but this feels like code that is written by the author for themselves, rather than for any other potential readers of the code. It's a lot easier to write code if you're the only reader, because you can keep a lot of the code's context in your head, and you don't need to write it down in the same way. I skimmed through the start of the file and then jumped up the bottom looking for an entry point. From there, the table state jumped out to me as a thread I could follow, so I started exploring that. The first thing that jumped out at me was how much defensive programming you are doing. There are lots of "if state X is not null" or "if event is not null" sections where it's not clear from the types or the logic that these values can ever be null. This makes me a bit nervous, because if you don't know whether something can be null or not, the reader is going to find it even harder to tell. The next thing I noticed was how difficult it is to follow state changes around. Part of this is state being set in multiple places at once (e.g. `state.tables` and as data attributes on elements), but also because you use both `.dataset.xyz` and `"data-xyz"` fairly interchangeably, which makes it difficult to jump to the usages of some bit of state if that uses a different syntax. This got me (finally) to some of the DOM manipulation code, which is what I was just eager to see in the first place. I landed in the tables.populate function, and the most surprising thing that jumped out to me here is that every table seems to be special-cased with a bunch if-else statements, partly for the rendering of each row, and also for updating the payload. Searching through this code, it seems like this mechanism of switching on the type of each module/table is all over the place, and that updating one part of the code is going to have massive knock-on effects on other parts of the code as well. I'm going to stop here because I need to get on and do other things. I agree with you that you have largely managed to avoid building your own framework, but I think this is very much to the code's detriment: a small amount of abstraction would go a long way here in terms of, e.g. isolating the different tables from each other, or managing state effectively. I can fully believe that you find it easy to write and maintain this code, but I suspect that has a lot more to do with you being the sole maintainer of this code than it does the clarity of the code. I see people confuse these two ideas a lot, but it's important to separate them. Like I said at the start, I'm grateful for the chance to see your approach, and if it works for you then my opinion if it doesn't really matter. But it unfortunately does not convince me of your claims about the benefits of this style of development.