| ▲ | voxic11 12 hours ago |
| The idea is you wouldn't mix innerHTML and setHTML, you would eliminate all usage of innerHTML and use the new setHTMLUnsafe if you needed the old functionality. |
|
| ▲ | extraduder_ire 11 hours ago | parent | next [-] |
| I looked up setHTMLUnsafe on MDN, and it looks like its been in every notable browser since last year. Good idea to ship that one first, when it's easier to implement and is going to be the unsafe fallback going forward. |
| |
|
| ▲ | croes 11 hours ago | parent | prev | next [-] |
| If I need the old functionality why not stick to innerHTML? |
| |
| ▲ | orf 11 hours ago | parent | next [-] | | because the "unsafe" suffix conveys information to the reader, whereas `innherHTML` does not? | | |
| ▲ | goatlover 10 hours ago | parent [-] | | Any potential reader should be familiar with innerHTML. | | |
| ▲ | kennywinker 9 hours ago | parent | next [-] | | Right. Like how any potential reader is familiar with the risks of sql injection which is why nothing has ever been hacked that way. Or how any potential driver is familiar with seat belts which is why everybody wears them and nobody’s been thrown from a car since they were invented. | | | |
| ▲ | orf 9 hours ago | parent | prev [-] | | yes, and bugs shouldn't exist because everyone should be familiar with everything. | | |
| ▲ | croes 8 hours ago | parent [-] | | But if some are marked unsafe and others are not it gives a false sense of security if something is not marked unsafe. | | |
| ▲ | orf 8 hours ago | parent [-] | | So we shouldn’t mark anything as unsafe then? And give no indication whatsoever? The issue isn’t that the word “safe” doesn’t appear in safe variants, it’s that “unsafe” makes your intentions clear: “I know this is unsafe, but it’s fine because of X and Y”. | | |
| ▲ | croes 7 hours ago | parent [-] | | Maybe we should add the word safe and consider everything else as unsafe | | |
| ▲ | orf 6 hours ago | parent [-] | | Like life, things should default to being safe. Unsafe, unexpected behaviours should be exception and thus require an exceptional name. Legacy and backwards compatibility hampers this, but going forward… |
|
|
|
|
|
| |
| ▲ | tbrownaw 11 hours ago | parent | prev | next [-] | | Because then your linter won't be able to tell you when you're done migrating the calls that can be migrated. | |
| ▲ | philipwhiuk 9 hours ago | parent | prev [-] | | Because sooner or later it'll be removed. | | |
| ▲ | goatlover 8 hours ago | parent | next [-] | | No because the web has to remain backwards compatible with older sites. This has always been the case. | |
| ▲ | croes 8 hours ago | parent | prev [-] | | And break millions of sites? |
|
|
|
| ▲ | reddalo 11 hours ago | parent | prev | next [-] |
| You can't rename an existing method. It would break compatibility with existing websites. |
|
| ▲ | post-it 12 hours ago | parent | prev [-] |
| > you would eliminate all usage of innerHTML The mythical refactor where all deprecated code is replaced with modern code. I'm not sure it has ever happened. I don't have an alternative of course, adding new methods while keeping the old ones is the only way to edit an append-only standard like the web. |
| |
| ▲ | thenewnewguy 11 hours ago | parent | next [-] | | If you want to adopt this in your project, you can add a linter that explicitly bans innerHTML (and then go fix the issues it finds). Obviously Mozilla cannot magically fix the code of every website on the web but the tools exist for _your_ website. | |
| ▲ | Vinnl 11 hours ago | parent | prev | next [-] | | I kinda like the way JS evolved into a modern language, where essentially ~everyone uses a linter that e.g. prevents the use of `var`. Sure, it's technically still in the language, but it's almost never used anymore. (Assuming transpilers have stopped outputting it, which I'm not confident about.) | | | |
| ▲ | bulbar 11 hours ago | parent | prev | next [-] | | It for sure happens for drop in replacements. | |
| ▲ | littlestymaar 10 hours ago | parent | prev | next [-] | | Nobody's talking about old code here. Having an alternative to innerHTML means you can ban it from new code through linting. | |
| ▲ | noduerme 11 hours ago | parent | prev [-] | | Finally, a good use case for AI. | | |
| ▲ | Aachen 11 hours ago | parent | next [-] | | Yeah, using a kilowatt GPU for string replacement is going to be the killer feature. I probably shouldn't even be joking, people are using it like this already | | |
| ▲ | charcircuit 11 hours ago | parent | next [-] | | When the condition for when you want to replace is hard to properly specify, AI shines for such find and replaces. | | |
| ▲ | Aachen 10 hours ago | parent | next [-] | | This one is literally matching "innerHTML = X" and setting "setHTML(X)" instead. Not some complex data format transformation But I can see what you mean, even if then it would still be better for it to print the code that does what you want (uses a few Wh) than doing the actual transformation itself (prone to mistakes, injection attacks, and uses however many tokens your input data is) | | |
| ▲ | charcircuit 9 hours ago | parent [-] | | That can break the site if you do the find and replace blindly. The goal here is to do the refactor without breaking the site. |
| |
| ▲ | lelanthran 7 hours ago | parent | prev [-] | | > When the condition for when you want to replace is hard to properly specify, AI shines for such find and replaces. And, in your opinion, this is one of those cases? | | |
| |
| ▲ | littlestymaar 10 hours ago | parent | prev [-] | | This ship has sailed unfortunately, no later than yesterday I've seen coworkers redact a screenshot using chatGTP. |
| |
| ▲ | josefx 11 hours ago | parent | prev [-] | | Wouldn't AI be trained on data using innerHTML? | | |
| ▲ | Aachen 11 hours ago | parent | next [-] | | My experience is that they somehow print quite modern code despite things like ES6 being too new to be standard knowledge even for me and I'm not even middle-aged yet Maybe the last 10 years saw so much more modern code than the last cumulative 40+ years of coding and so modern code is statistically more likely to be output? Or maybe they assign higher weights to more recent commits/sources during training? Not sure but it seems to be good at picking this up. And you can always feed the info into its context window until then | | |
| ▲ | skeeter2020 10 hours ago | parent | next [-] | | This is not my experience. Claude has been happily generating code over the past week that is full of implicit any and using code that's been deprecated for at least 2 years. >> Maybe the last 10 years saw so much more modern code than the last cumulative 40+ years of coding and so modern code is statistically more likely to be output? The rate of change has made defining "modern" even more difficult and the timeframe brief, plus all that new code is based on old code, so it's more like a leaning tower than some sort of solid foundation. | |
| ▲ | SahAssar 9 hours ago | parent | prev | next [-] | | ES6 is 11 years old. It's not that new. | |
| ▲ | chrisweekly 8 hours ago | parent | prev [-] | | > "ES6 being too new to be standard knowledge" Huh? It's been a decade. |
| |
| ▲ | charcircuit 11 hours ago | parent | prev | next [-] | | Which is why it can easily understand how innerHTML is being used so that it can replace it with the right thing. | |
| ▲ | stvltvs 11 hours ago | parent | prev [-] | | Honest question: Is there a way to get an LLM to stop emitting deprecated code? | | |
| ▲ | fragmede 11 hours ago | parent [-] | | Theoretically, if you could train your own, and remove all references to the deprecated code in the training data, it wouldn't be able to emit deprecated code. Realistically that ability is out of reach at the hobbiest level so it will have to remain theoretical for at least a few more iterations of Moore's law. |
|
|
|
|
