5 ms·

> That's one more reason not to rely on automated testing only. I took an alternative conclusion - don't use shadow DOM or other bleeding edge tech when someth

> That's one more reason not to rely on automated testing only. I took an alternative conclusion - don't use shadow DOM or other bleeding edge tech when something much simpler will do. What ever happened to using document.getElementById? You can even skip much of this if you finish your work on the server before sending that text/html response... I sometimes wonder if there's a huge thing I'm missing, but then I remember our customers love our product. Not a single one of them can tell that we don't use react or WASM. In fact, we have yet to receive a single complaint regarding our multipart form posts resulting in actual browser navigation. For whatever reason, the users don't seem to give a shit about this. It only ever seems to come up in the most ridiculous nerd conversations.

colordrops 3y ago
Shadow DOM is not "bleeding edge". It's been in all major browsers for years.
- Already__Taken 3y ago
  shadow don't has always been on the platform the only new big but is an API exposing it. before you just never got to change certain components like select dropdowns
- chrismorgan 3y ago
  Shadow DOM is frankly more bleeding edge than most new things, in the sense that you’ll cut yourself badly if you try using it much. There are just so many subtle and annoying problems with it because it broke the DOM model that has been around from the start, and now a bunch of stuff is just inaccessible from the DOM. The vast majority of places I see people thinking “Shadow DOM might be suitable here”, it’s a terrible idea. Good places to use it are actually really niche. Declarative Shadow DOM, more recently added and not yet universally supported, fixes one of the two biggest problems with it (that you have to load and run scripts before it can work), but the other one (that it’s strong insulating encapsulation, which is just occasionally what you want but normally not) is by design and is not going to change. In the forms they’ve ended up in, Shadow DOM was a mistake (yes, they should have just left browser widgets like <select> and <audio controls> special), and Web Components were almost certainly a mistake.
  - colordrops 3y ago
    I've been using shadow DOM almost exclusively for 7 years in very high profile important applications with no incident due to its use. If your code is properly encapsulated you won't have a problem. There shouldn't be any reason for other production components to pierce the shadow DOM boundary.
    - chrismorgan 3y ago
      Since you talk from this angle, here’s an example from a different perspective of how this is still a problem (though I maintain it’s almost always a terrible idea for development/maintenance reasons where people think to use it, too—few components actually want what Shadow DOM gets them): I’m a user. I want to write user scripts to tweak things to my liking and to support my specific use cases. If you use shadow roots (especially closed ones), you may fundamentally prevent me from doing so, removing the agency of my user agent. I don’t like that.
TheAceOfHearts 3y ago
It's fine to use whatever tools you consider most appropriate for your situation and use case. The tools you mention have helped enable a ton of new forms of development and interactions on the web. Consider: I was recently baking a cake and didn't have to use a sous vide for anything, I don't understand why people keep hyping those up so much. That's similar to how your comment reads to me.
- lcnPylGDnU4H9OF 3y ago
  > Consider: I was recently baking a cake and didn't have to use a sous vide for anything, I don't understand why people keep hyping those up so much. That's similar to how your comment reads to me. This analogy seems to work pretty well. On the other side of the fence, I see people talking about how good their sous vide cakes are and how they’d never work at a bakery that didn’t exclusively use a sous vide. That’s not to say that the cooking method is never viable, just that it’s touted as the only thing necessary. Meanwhile online baking recipes list “make sure you own a sous vide” as the first step.
  - ImPostingOnHN 3y ago
    Where do you see people talking about how good their sous vide cakes are and how they’d never work at a bakery that didn’t exclusively use a sous vide? Who here "touted [it] as the only thing necessary"? In fact, what cakes have you seen that are cooked via sous vide? Are you sure you understood the analogy? The components of it were: 1. Person says they built a basic website without React, doesn't know why people use React (it's because the use case for React typically isn't "build a basic website given unlimited time and effort") 2. Person says they made a cake without sous vide, doesn't know why people use sous vide (it's because the use case for sous vide typically isn't "bake a cake")
    - saurik 3y ago
      The person you are responding to is embracing the analogy and using it to demonstrate how--if you also agree that the analogy works well--ridiculous it thereby would be how online tutorials for websites (not cakes: that's a the point) make it sound like the way to do anything and the very first technique you should learn in a tutorial is React (not sous vide: that's the point).
diggan 3y ago
> In fact, we have yet to receive a single complaint regarding our multipart form posts resulting in actual browser navigation. Just out of curiosity, how do you handle errors, specifically timeouts here? I'm guessing the HTTP server serves a custom error page, does it have a reference to the previous page with all the data they tried to submit and so on? Probably how I would have handled it. Timeouts are a bit trickier, as the user would just see the browser error page and dassit. Nice thing with decoupling server responses from what the browser actually renders is that you can handle things like that exactly like how you (as a developer) want to, without breaking the current page. But, as always, it depends. Seems you folks are giving your users a lot of value from whatever you're doing regardless, so seems what you're doing is working :) Congrats.
- chrismorgan 3y ago
  Such error handling is easier, because it’s a normal part of the flow, rather than a separate path that’s not tested. If submitting fails to load the page, you get the normal browser error page and reload, submitting it again. And that’s what you want it to be, unless you can actively do something else in the meantime (which is still a good deal more complex and not typically supported by web apps). By contrast, my experience says that scripting-based submission is very flimsy in the presence of unreliable network. It’s crazy just how many things enter broken, unrecoverable states because it didn’t occur to the authors that maybe that fetch could fail, and maybe you might want to try again. Or worse, and practically never handled properly, when network conditions lead to a stuck request, where the client is waiting for something that will never come. In the browser, you just press F5/Ctrl+R/⌘R when you recognise this situation, but when scripting-powered the only way of fixing this may be briefly toggling the network adapter in order to kill the request (because you can’t just reload the page because you’d lose in-page form state, another of these things that the browser gives you for free but scripting plays havoc with, though Firefox is best at compensating), and hoping that leads the page to let you submit again. Seriously, scripting-based submission, navigation, &c. is reimplementing a lot of what the browser give you for free, and it can’t be done perfectly (e.g. tab loading indicator) and what is reimplemented is absolutely never as flawless as possible. Yes, you get some interesting advantages, but you lose a lot too, more than developers tend to admit.
selalipop 3y ago
I recently launched an app in an extremely saturated space (AI characters, https://tryspellbound.com https://tryspellbound.com) Most of my differentiation is in the UX: specifically things like animations that were carefully selected to make the UI feel snappy even though the AI isn't that quick. It sounds silly, but there are literally 100 apps doing exactly what mine does. If my site felt like submitting a form, and the UI had native selects, and overall it felt like a site that leaned more on native web technology, the demographic that uses it would have shunned it for other options before giving it a chance. Sometimes you're in a market where you get the luxury of ignoring looks and just delivering value in a way that doesn't allow people to complain, but other times you have to give the people what they want: and a lot of them want that "it feels like an app" experience.
- bob1029 3y ago
  How many distinct aspects of your product actually require asynchronous submission of form data? A little bit of javascript/AJAX/etc is perfectly acceptable. We didn't get 100% of the way there with multipart/form because iOS/Safari exists and will crash hard if you try to post big forms. You don't need ReactJS to submit a user input and avoid a page load. This is ~20 lines of vanilla javascript.
  - chrismorgan 3y ago
    > iOS/Safari exists and will crash hard if you try to post big forms. I find things like https://stackoverflow.com/questions/10195459/ios-safari-crashing-with-large-post-data-form-submit https://stackoverflow.com/questions/10195459/ios-safari-cras... and https://bugs.webkit.org/show_bug.cgi?id=84168 https://bugs.webkit.org/show_bug.cgi?id=84168, from 2012. Is that still an issue? I find it difficult to imagine you could have a bug that prevents you from submitting a form with even half a megabyte of data being allowed to last for long.
    - bob1029 3y ago
      > I find things like https://stackoverflow.com/questions/10195459/ios-safari-cras https://stackoverflow.com/questions/10195459/ios-safari-cras... and https://bugs.webkit.org/show_bug.cgi?id=84168 https://bugs.webkit.org/show_bug.cgi?id=84168, from 2012. Is that still an issue? Yes. It is 100% still an issue. That is the exact bug I was looking at. I can get Safari on my latest gen iPad to crash hard after only 3 submissions pretty much every time. We are sending large images in our forms but it's only like 1-5 megabytes.

colordrops 3y ago

Shadow DOM is not "bleeding edge". It's been in all major browsers for years.

Already__Taken 3y ago
shadow don't has always been on the platform the only new big but is an API exposing it. before you just never got to change certain components like select dropdowns
chrismorgan 3y ago
Shadow DOM is frankly more bleeding edge than most new things, in the sense that you’ll cut yourself badly if you try using it much. There are just so many subtle and annoying problems with it because it broke the DOM model that has been around from the start, and now a bunch of stuff is just inaccessible from the DOM. The vast majority of places I see people thinking “Shadow DOM might be suitable here”, it’s a terrible idea. Good places to use it are actually really niche. Declarative Shadow DOM, more recently added and not yet universally supported, fixes one of the two biggest problems with it (that you have to load and run scripts before it can work), but the other one (that it’s strong insulating encapsulation, which is just occasionally what you want but normally not) is by design and is not going to change. In the forms they’ve ended up in, Shadow DOM was a mistake (yes, they should have just left browser widgets like <select> and <audio controls> special), and Web Components were almost certainly a mistake.
- colordrops 3y ago
  I've been using shadow DOM almost exclusively for 7 years in very high profile important applications with no incident due to its use. If your code is properly encapsulated you won't have a problem. There shouldn't be any reason for other production components to pierce the shadow DOM boundary.
  - chrismorgan 3y ago
    Since you talk from this angle, here’s an example from a different perspective of how this is still a problem (though I maintain it’s almost always a terrible idea for development/maintenance reasons where people think to use it, too—few components actually want what Shadow DOM gets them): I’m a user. I want to write user scripts to tweak things to my liking and to support my specific use cases. If you use shadow roots (especially closed ones), you may fundamentally prevent me from doing so, removing the agency of my user agent. I don’t like that.

TheAceOfHearts 3y ago

It's fine to use whatever tools you consider most appropriate for your situation and use case. The tools you mention have helped enable a ton of new forms of development and interactions on the web. Consider: I was recently baking a cake and didn't have to use a sous vide for anything, I don't understand why people keep hyping those up so much. That's similar to how your comment reads to me.

lcnPylGDnU4H9OF 3y ago
> Consider: I was recently baking a cake and didn't have to use a sous vide for anything, I don't understand why people keep hyping those up so much. That's similar to how your comment reads to me. This analogy seems to work pretty well. On the other side of the fence, I see people talking about how good their sous vide cakes are and how they’d never work at a bakery that didn’t exclusively use a sous vide. That’s not to say that the cooking method is never viable, just that it’s touted as the only thing necessary. Meanwhile online baking recipes list “make sure you own a sous vide” as the first step.
- ImPostingOnHN 3y ago
  Where do you see people talking about how good their sous vide cakes are and how they’d never work at a bakery that didn’t exclusively use a sous vide? Who here "touted [it] as the only thing necessary"? In fact, what cakes have you seen that are cooked via sous vide? Are you sure you understood the analogy? The components of it were: 1. Person says they built a basic website without React, doesn't know why people use React (it's because the use case for React typically isn't "build a basic website given unlimited time and effort") 2. Person says they made a cake without sous vide, doesn't know why people use sous vide (it's because the use case for sous vide typically isn't "bake a cake")
  - saurik 3y ago
    The person you are responding to is embracing the analogy and using it to demonstrate how--if you also agree that the analogy works well--ridiculous it thereby would be how online tutorials for websites (not cakes: that's a the point) make it sound like the way to do anything and the very first technique you should learn in a tutorial is React (not sous vide: that's the point).

diggan 3y ago

> In fact, we have yet to receive a single complaint regarding our multipart form posts resulting in actual browser navigation. Just out of curiosity, how do you handle errors, specifically timeouts here? I'm guessing the HTTP server serves a custom error page, does it have a reference to the previous page with all the data they tried to submit and so on? Probably how I would have handled it. Timeouts are a bit trickier, as the user would just see the browser error page and dassit. Nice thing with decoupling server responses from what the browser actually renders is that you can handle things like that exactly like how you (as a developer) want to, without breaking the current page. But, as always, it depends. Seems you folks are giving your users a lot of value from whatever you're doing regardless, so seems what you're doing is working :) Congrats.

chrismorgan 3y ago
Such error handling is easier, because it’s a normal part of the flow, rather than a separate path that’s not tested. If submitting fails to load the page, you get the normal browser error page and reload, submitting it again. And that’s what you want it to be, unless you can actively do something else in the meantime (which is still a good deal more complex and not typically supported by web apps). By contrast, my experience says that scripting-based submission is very flimsy in the presence of unreliable network. It’s crazy just how many things enter broken, unrecoverable states because it didn’t occur to the authors that maybe that fetch could fail, and maybe you might want to try again. Or worse, and practically never handled properly, when network conditions lead to a stuck request, where the client is waiting for something that will never come. In the browser, you just press F5/Ctrl+R/⌘R when you recognise this situation, but when scripting-powered the only way of fixing this may be briefly toggling the network adapter in order to kill the request (because you can’t just reload the page because you’d lose in-page form state, another of these things that the browser gives you for free but scripting plays havoc with, though Firefox is best at compensating), and hoping that leads the page to let you submit again. Seriously, scripting-based submission, navigation, &c. is reimplementing a lot of what the browser give you for free, and it can’t be done perfectly (e.g. tab loading indicator) and what is reimplemented is absolutely never as flawless as possible. Yes, you get some interesting advantages, but you lose a lot too, more than developers tend to admit.

selalipop 3y ago

I recently launched an app in an extremely saturated space (AI characters, https://tryspellbound.com https://tryspellbound.com) Most of my differentiation is in the UX: specifically things like animations that were carefully selected to make the UI feel snappy even though the AI isn't that quick. It sounds silly, but there are literally 100 apps doing exactly what mine does. If my site felt like submitting a form, and the UI had native selects, and overall it felt like a site that leaned more on native web technology, the demographic that uses it would have shunned it for other options before giving it a chance. Sometimes you're in a market where you get the luxury of ignoring looks and just delivering value in a way that doesn't allow people to complain, but other times you have to give the people what they want: and a lot of them want that "it feels like an app" experience.

bob1029 3y ago
How many distinct aspects of your product actually require asynchronous submission of form data? A little bit of javascript/AJAX/etc is perfectly acceptable. We didn't get 100% of the way there with multipart/form because iOS/Safari exists and will crash hard if you try to post big forms. You don't need ReactJS to submit a user input and avoid a page load. This is ~20 lines of vanilla javascript.
- chrismorgan 3y ago
  > iOS/Safari exists and will crash hard if you try to post big forms. I find things like https://stackoverflow.com/questions/10195459/ios-safari-crashing-with-large-post-data-form-submit https://stackoverflow.com/questions/10195459/ios-safari-cras... and https://bugs.webkit.org/show_bug.cgi?id=84168 https://bugs.webkit.org/show_bug.cgi?id=84168, from 2012. Is that still an issue? I find it difficult to imagine you could have a bug that prevents you from submitting a form with even half a megabyte of data being allowed to last for long.
  - bob1029 3y ago
    > I find things like https://stackoverflow.com/questions/10195459/ios-safari-cras https://stackoverflow.com/questions/10195459/ios-safari-cras... and https://bugs.webkit.org/show_bug.cgi?id=84168 https://bugs.webkit.org/show_bug.cgi?id=84168, from 2012. Is that still an issue? Yes. It is 100% still an issue. That is the exact bug I was looking at. I can get Safari on my latest gen iPad to crash hard after only 3 submissions pretty much every time. We are sending large images in our forms but it's only like 1-5 megabytes.