4 ms·

I have another fun challenge, try to completely disable the auto-zoom-feature on Google Maps. Last time I tried, I stepped through 20 stacks of obfuscated nonse

I have another fun challenge, try to completely disable the auto-zoom-feature on Google Maps. Last time I tried, I stepped through 20 stacks of obfuscated nonsense before eventually giving up. But tbh I can't really imagine any scenario that is near impossible - except for WASM driven web pages which will break just about anything :(

lgas 4y ago
why would WASM driven pages be any different to deal with than non-WASM driven pages?
- klibertp 4y ago
  You can't scrape HTML out of a rendered bitmap. It's not the only mode WASM can be used, but often all the rendering happens in the compiled code and the page only receives a series of images to display on a canvas. It's Flash all over again.
  - grishka 4y ago
    > It's Flash all over again. Flash was at least easy to decompile. The decompiled code was so good most of the time that you could compile it back into a working swf, with modifications if you want any. But then both WASM and Flash have to get the data from somewhere. That is usually something resembling an API endpoint that returns the result in XML or JSON. Why not sidestep the whole client app thing and go straight for that API endpoint?
  - RobbieGM 4y ago
    Almost nobody is doing this, and almost nobody ever will because it breaks accessibility and a whole host of other features. I would save the alarmism for another day.
    - klibertp 4y ago
      You're right about the accessibility and other features breaking. You're wrong in saying that (almost) nobody would do this. What (almost) nobody will do is creating an HTML-based rendering engine for windowing (GTK, Qt, wx, etc.) and graphical (SDL, DirectX, OpenGL, etc.) toolkits. It's technically possible, but maintainers have enough work with supporting just the 3 desktop and 2 mobile platforms. In the absence of a proper HTML rendering frontend, there's really nothing you can do other than compile the whole graphical stack and render into a canvas. That's the default for graphical apps under Emscripten - all games and GUI apps currently work that way. The only apps that have a HTML rendering frontend are CLI tools and REPLs, where it's trivial enough to rewrite the rendering in JS. There are frameworks currently being developed that allow rendering of widget trees in HTML or SVG, but they're still immature and not widely used. Well, WASM itself is not widely used, so it's normal. BTW: were you around in the days of Flash? Because it broke accessibility and a whole host of other features the same way, yet it was still used and hugely popular (there was also ActiveX, which worsened things even more). It began with online games and graphics-rich pages, but it evolved frameworks for generic apps (ie. Flex) and then even CMS engines. Soon enough Flash was used for even blogs and e-commerce. The situation today is different due to the Web having evolved into a more capable and standardized platform, but there's no shortage of devs who would welcome the ability to run their app in the browser, but who dislike HTML/JS so much they would do basically anything just to not have to touch it - accessibility and a lot of other things be damned. Don't underestimate how irrational people and even whole communities can be. As a bonus, here's an example of the "almost" part: http://35.158.218.205/experiments/webDOOM/ http://35.158.218.205/experiments/webDOOM/

lgas 4y ago

why would WASM driven pages be any different to deal with than non-WASM driven pages?

klibertp 4y ago
You can't scrape HTML out of a rendered bitmap. It's not the only mode WASM can be used, but often all the rendering happens in the compiled code and the page only receives a series of images to display on a canvas. It's Flash all over again.
- grishka 4y ago
  > It's Flash all over again. Flash was at least easy to decompile. The decompiled code was so good most of the time that you could compile it back into a working swf, with modifications if you want any. But then both WASM and Flash have to get the data from somewhere. That is usually something resembling an API endpoint that returns the result in XML or JSON. Why not sidestep the whole client app thing and go straight for that API endpoint?
- RobbieGM 4y ago
  Almost nobody is doing this, and almost nobody ever will because it breaks accessibility and a whole host of other features. I would save the alarmism for another day.
  - klibertp 4y ago
    You're right about the accessibility and other features breaking. You're wrong in saying that (almost) nobody would do this. What (almost) nobody will do is creating an HTML-based rendering engine for windowing (GTK, Qt, wx, etc.) and graphical (SDL, DirectX, OpenGL, etc.) toolkits. It's technically possible, but maintainers have enough work with supporting just the 3 desktop and 2 mobile platforms. In the absence of a proper HTML rendering frontend, there's really nothing you can do other than compile the whole graphical stack and render into a canvas. That's the default for graphical apps under Emscripten - all games and GUI apps currently work that way. The only apps that have a HTML rendering frontend are CLI tools and REPLs, where it's trivial enough to rewrite the rendering in JS. There are frameworks currently being developed that allow rendering of widget trees in HTML or SVG, but they're still immature and not widely used. Well, WASM itself is not widely used, so it's normal. BTW: were you around in the days of Flash? Because it broke accessibility and a whole host of other features the same way, yet it was still used and hugely popular (there was also ActiveX, which worsened things even more). It began with online games and graphics-rich pages, but it evolved frameworks for generic apps (ie. Flex) and then even CMS engines. Soon enough Flash was used for even blogs and e-commerce. The situation today is different due to the Web having evolved into a more capable and standardized platform, but there's no shortage of devs who would welcome the ability to run their app in the browser, but who dislike HTML/JS so much they would do basically anything just to not have to touch it - accessibility and a lot of other things be damned. Don't underestimate how irrational people and even whole communities can be. As a bonus, here's an example of the "almost" part: http://35.158.218.205/experiments/webDOOM/ http://35.158.218.205/experiments/webDOOM/