19 ms·

The structure and class names? Probably not, the structure looks kinda verbose, but not unreasonable if you imagine them using an off-the-shelf HTML/CSS library

by k_sh 9y ago

The structure and class names? Probably not, the structure looks kinda verbose, but not unreasonable if you imagine them using an off-the-shelf HTML/CSS library for the site.

pmoriarty 9y ago
No. This is what I get when I wget http://www.iai.co.il/2013/36694-16153-en/Business_Areas_Land.aspx http://www.iai.co.il/2013/36694-16153-en/Business_Areas_Land... https://paste.pound-python.org/show/L3Yhf3vJ8rMuiO4OWLOm/ https://paste.pound-python.org/show/L3Yhf3vJ8rMuiO4OWLOm/ That looks pretty obfuscated to me. I'm guessing what you're seeing is the html that's generated from that somehow. Or maybe it's serving up different html to different clients/IPs? Maybe someone who's more familiar with web development could explain.
- deleted 9y ago
  [deleted]
- jszymborski 9y ago
  The page loads fine with javascript disabled, and from what I understand, view-source: doesn't interpret javascript. My best guess is that it's picking up the wget user-agent and serving up some bot counter-measures?
  - pmoriarty 9y ago
    It doesn't always do that. I first loaded the page in emacs-w3m, which doesn't interpret javascript, and got the output I pasted above. Then I went back a bit later and loaded the page again, and got normal html (while still using emacs-w3m, a browser that can't handle javascript). Then I tried wget and got the same weird obfuscated stuff I pasted above, and got it again when I wgot it again.
- devrandomguy 9y ago
  It's just a result of ruthless optimization. Management is always pushing us devs to optimize the metrics that are easiest to measure, and there are plenty of online tools that will score a site based partly on the file sizes for JS, CSS and even HTML. Right now, we're running the whole response through something like an optimizing compiler stack (Webpack, with lots of plugins and some custom modules). It renames everything to the shortest possible name, eliminates code that will never execute, inlines CSS into the <head> and <body> to reduce HTTP requests, splits the code into large bundles that can be cached forever and a small bundle that will be updated nearly every workday, stuff like that. I'm afraid we're at the point now where a modern HTML response requires advanced tools in order to make it legible to a human. For that, I apologize, no sarc, we are aware of the loss of culture that is happening. There is some pushback happening, in the form a ruthless minimalism (plain HTML, no css, no JS), but good luck demonstrating the beauty of that to the UX team. If it's any consolation, these advanced tools are built into FF and Chrome; just right click, inspect element, and look for associated JS handlers. The browser can clean up the code formatting for you, although the names will still be arbitrary. Set a breakpoint on an interesting statement, trigger (or manually fire) the action you followed to get there, and explore the values that are in scope at that point. Watching the values change will often tell you more than reading the code itself, when the names are meaningless. As for the inconsistency mentioned by my sibling, that sounds a little broken. One of the things we do with the Webpack stack, is specialize the code for known browsers, by eliminating the browser-specific stuff that isn't needed for the current visitor; w3m and wget are not high priority targets :/

by k_sh 9y ago

The structure and class names? Probably not, the structure looks kinda verbose, but not unreasonable if you imagine them using an off-the-shelf HTML/CSS library for the site.

pmoriarty 9y ago

No. This is what I get when I wget http://www.iai.co.il/2013/36694-16153-en/Business_Areas_Land.aspx http://www.iai.co.il/2013/36694-16153-en/Business_Areas_Land... https://paste.pound-python.org/show/L3Yhf3vJ8rMuiO4OWLOm/ https://paste.pound-python.org/show/L3Yhf3vJ8rMuiO4OWLOm/ That looks pretty obfuscated to me. I'm guessing what you're seeing is the html that's generated from that somehow. Or maybe it's serving up different html to different clients/IPs? Maybe someone who's more familiar with web development could explain.

deleted 9y ago
[deleted]
jszymborski 9y ago
The page loads fine with javascript disabled, and from what I understand, view-source: doesn't interpret javascript. My best guess is that it's picking up the wget user-agent and serving up some bot counter-measures?
- pmoriarty 9y ago
  It doesn't always do that. I first loaded the page in emacs-w3m, which doesn't interpret javascript, and got the output I pasted above. Then I went back a bit later and loaded the page again, and got normal html (while still using emacs-w3m, a browser that can't handle javascript). Then I tried wget and got the same weird obfuscated stuff I pasted above, and got it again when I wgot it again.
devrandomguy 9y ago
It's just a result of ruthless optimization. Management is always pushing us devs to optimize the metrics that are easiest to measure, and there are plenty of online tools that will score a site based partly on the file sizes for JS, CSS and even HTML. Right now, we're running the whole response through something like an optimizing compiler stack (Webpack, with lots of plugins and some custom modules). It renames everything to the shortest possible name, eliminates code that will never execute, inlines CSS into the <head> and <body> to reduce HTTP requests, splits the code into large bundles that can be cached forever and a small bundle that will be updated nearly every workday, stuff like that. I'm afraid we're at the point now where a modern HTML response requires advanced tools in order to make it legible to a human. For that, I apologize, no sarc, we are aware of the loss of culture that is happening. There is some pushback happening, in the form a ruthless minimalism (plain HTML, no css, no JS), but good luck demonstrating the beauty of that to the UX team. If it's any consolation, these advanced tools are built into FF and Chrome; just right click, inspect element, and look for associated JS handlers. The browser can clean up the code formatting for you, although the names will still be arbitrary. Set a breakpoint on an interesting statement, trigger (or manually fire) the action you followed to get there, and explore the values that are in scope at that point. Watching the values change will often tell you more than reading the code itself, when the names are meaningless. As for the inconsistency mentioned by my sibling, that sounds a little broken. One of the things we do with the Webpack stack, is specialize the code for known browsers, by eliminating the browser-specific stuff that isn't needed for the current visitor; w3m and wget are not high priority targets :/