3 ms·

> not sure if it's safe to remove That's a symptom of companies spending all their money on building new features without also spending money on regression tes

> not sure if it's safe to remove That's a symptom of companies spending all their money on building new features without also spending money on regression testing. If you build a feature to work around a third party then surely you have that third party on-hand to build automated tests against and ensure that something didn't break and/or is still needed? If not then you're not writing new features; you're writing hacks. And you are perpetuating the same problem on other people.

jokethrowaway 5y ago
While I agree in theory, for a long time there was no easy way to test frontend code across multiple browser. That effort was simply too high for anyone. Nowadays front-end testing is doable but still far from being a pleasant experience. I did it at some jobs, in others we just didn't think the benefits were worth the hassle. Now that I'm building a small business my backend is very well tested while the front-end doesn't have tests. This is partly because of the setup cost and partly because the development experience is so bad that I see our small company just throwing everything out of the window, keeping the html structure and rebuilding the thin UI with some better technology along the way (current stack is react + next + tailwind, we've been doing react for 5+ years)
- wpietri 5y ago
  Interesting! Could you say a bit about what you think might come next? Or from a different angle, the pain points you have that make you think a rewrite in a new stack is preferable?
  - jokethrowaway 5y ago
    I don't think we're waiting for some new concept that is missing. I've been hoping for someone to maintain some popular js library implementing real functional reactive programming and arrows (like https://hackage.haskell.org/package/auto https://hackage.haskell.org/package/auto), but I can live without it. I'm just waiting for something polished, with a small, simple, codebase (not React with fibers, yes to something like solidjs, preact) with widespread types support (not Typescript and the quest for implementing types for every dependency), ideally not creating huge bundles (I like solidjs / svelte), with a core solution to manage state (I like Elm), ideally supporting CSS encapsulation and semantic css (I like CSS modules, MaintainableCSS), mainstream enough that I can hire people to work with without having to become a teacher. I think Elm got 90% there, but it failed hard on the community side. I'm thinking of moving to a Rust framework (eg. seed-rs) next as soon as they get popular enough and after checking whether the wasm bundle size make sense.
jefftk 5y ago
The most likely case is that Firefox <65 still doesn't work (browsers almost always only fix bugs in new versions), and the question is whether or not it's still worth supporting the portion of traffic on pre-2019 Firefox.
- SilverRed 5y ago
  One of the things that shocked me is after installing a fresh windows XP VM, I was able to use the built in IE to use google and it all just worked.. If this is something that actually should work is another question but it's quite impressive that it does work.
xxpor 5y ago
Not always true. Especially for something running on client devices. You can't expect an app maker to own every possible device their code is going to run on. Now maybe Google could do something like that, but 99% of people couldn't. There's also, in this case, a question of if anyone is still using the device/browser/whatever. It sounds like they know removing the workaround will in fact break that use case, they just don't know if they should care or not. The third party in this case might be Grandpa Joe. You can't exactly ask him to use the beta version of X and see if it's broken. Or if he's still on Firefox vOld.ancent.
- z3t4 5y ago
  It used to be that when someone got a fancy new device, like an iPhone you just said: - If you want me to fix the issues, send me an device. Now alot can be emulated. I can for example start Xcode simulator and pick the device someone have issues with. Or I can run Windows Xp in VirtualBox. Or emulate the Samsung smart-watch, or run Android emulator. So a lot of devices can be simulated or emulated, and you can try removing a line of code and re-run the test suit on all the virtual devices. Lots of old code for obsolete devices is only one end of the problem! The other end is to make sure all those old devices still works when you make changes and add new features! There's no idea keeping and old fix if the app will crash on that device anyway.
mattnewton 5y ago
The pile of high quality regression testing Google search has is miles above any other product I have worked on; but the number of possibly generated search result pages and the number of supported browsers conspire to make the pile of possible breakages even higher. Even so, I felt better about removing code in that JavaScript codebase than just about any other I have contributed to, and frequently did. (My total line count in JavaScript was negative for a while). The problem was much less about the difficulty of it and more that it wasn't difficult or high enough impact for the amount of time you needed to spend to detect these cases and prove their safety. The low hanging fruit of stuff that already passed all the regression tests was often already scooped up and the piles of cruft all had one edge case with some test or were hard to trigger and confirm manually that it was fixed.

jokethrowaway 5y ago

While I agree in theory, for a long time there was no easy way to test frontend code across multiple browser. That effort was simply too high for anyone. Nowadays front-end testing is doable but still far from being a pleasant experience. I did it at some jobs, in others we just didn't think the benefits were worth the hassle. Now that I'm building a small business my backend is very well tested while the front-end doesn't have tests. This is partly because of the setup cost and partly because the development experience is so bad that I see our small company just throwing everything out of the window, keeping the html structure and rebuilding the thin UI with some better technology along the way (current stack is react + next + tailwind, we've been doing react for 5+ years)

wpietri 5y ago
Interesting! Could you say a bit about what you think might come next? Or from a different angle, the pain points you have that make you think a rewrite in a new stack is preferable?
- jokethrowaway 5y ago
  I don't think we're waiting for some new concept that is missing. I've been hoping for someone to maintain some popular js library implementing real functional reactive programming and arrows (like https://hackage.haskell.org/package/auto https://hackage.haskell.org/package/auto), but I can live without it. I'm just waiting for something polished, with a small, simple, codebase (not React with fibers, yes to something like solidjs, preact) with widespread types support (not Typescript and the quest for implementing types for every dependency), ideally not creating huge bundles (I like solidjs / svelte), with a core solution to manage state (I like Elm), ideally supporting CSS encapsulation and semantic css (I like CSS modules, MaintainableCSS), mainstream enough that I can hire people to work with without having to become a teacher. I think Elm got 90% there, but it failed hard on the community side. I'm thinking of moving to a Rust framework (eg. seed-rs) next as soon as they get popular enough and after checking whether the wasm bundle size make sense.

jefftk 5y ago

The most likely case is that Firefox <65 still doesn't work (browsers almost always only fix bugs in new versions), and the question is whether or not it's still worth supporting the portion of traffic on pre-2019 Firefox.

SilverRed 5y ago
One of the things that shocked me is after installing a fresh windows XP VM, I was able to use the built in IE to use google and it all just worked.. If this is something that actually should work is another question but it's quite impressive that it does work.

xxpor 5y ago

Not always true. Especially for something running on client devices. You can't expect an app maker to own every possible device their code is going to run on. Now maybe Google could do something like that, but 99% of people couldn't. There's also, in this case, a question of if anyone is still using the device/browser/whatever. It sounds like they know removing the workaround will in fact break that use case, they just don't know if they should care or not. The third party in this case might be Grandpa Joe. You can't exactly ask him to use the beta version of X and see if it's broken. Or if he's still on Firefox vOld.ancent.

z3t4 5y ago
It used to be that when someone got a fancy new device, like an iPhone you just said: - If you want me to fix the issues, send me an device. Now alot can be emulated. I can for example start Xcode simulator and pick the device someone have issues with. Or I can run Windows Xp in VirtualBox. Or emulate the Samsung smart-watch, or run Android emulator. So a lot of devices can be simulated or emulated, and you can try removing a line of code and re-run the test suit on all the virtual devices. Lots of old code for obsolete devices is only one end of the problem! The other end is to make sure all those old devices still works when you make changes and add new features! There's no idea keeping and old fix if the app will crash on that device anyway.

mattnewton 5y ago

The pile of high quality regression testing Google search has is miles above any other product I have worked on; but the number of possibly generated search result pages and the number of supported browsers conspire to make the pile of possible breakages even higher. Even so, I felt better about removing code in that JavaScript codebase than just about any other I have contributed to, and frequently did. (My total line count in JavaScript was negative for a while). The problem was much less about the difficulty of it and more that it wasn't difficult or high enough impact for the amount of time you needed to spend to detect these cases and prove their safety. The low hanging fruit of stuff that already passed all the regression tests was often already scooped up and the piles of cruft all had one edge case with some test or were hard to trigger and confirm manually that it was fixed.