51–60 of 114 posts
But how! I don't know about other people here, but in our company we haven't figured out how to parse (for testing of course) dynamic websites. All tools, including free tools like Selenium and paid tools like QF-Test, seem to not be able to understand how it works, or our web developers are not able to code dynamic web like it should be coded.
I've long thought that the need for a high performance sandboxed JavaScript VM was the real impetus for Google's investment in v8, and that Chrome was just a useful opportunity to leverage it and to get external contribution. Is there any evidence that this is the case?
I feel that dynamic websites are not websites, but applications. Even after this thorough research, I'd still be very wary of turning a primarily content-based site into a dynamic app. A plain HTML site is accessible, and will be accessible in a 1000 years. A site depending on (external) JavaScript sources will force John Titor to travel back in time to find version 1.x of jQuery. Starting with JavaScript abandons pr…
IMHO: Websites that don't have "realtime" content should always stick with traditional HTML. I'm a Webdeveloper myself and i don't like the JavaScript Frontend trend. Many Devs use Frontend JS in places where it's absolutely not needed. If you're building an App that updates in realtime, shows informations while it's created, i'm fine with Frontend JS, but it's an overkill for most content pages. Sure, it depends on…
Earlier quoted context omitted.
Maybe they trigger timers immediately
And how about server-side state? Imagine you use setInterval to load a new paragraph from a server, and the server only provides a new parapgraph 1200ms after the first polling?
Source: I primarily did JavaScript execution for Google's indexing pipeline 2006 to 2010.
I think there is no way they are going to scrap the websites as there are millions of them with each having their own structure.
This was actually my primary role at Google from 2006 to 2010. One of my first test cases was a certain date range of the Wall Street Journal's archives of their Chinese language pages, where all of the actual text was in a JavaScript string literal, and before my changes, Google thought all of these pages had identical content... just the navigation boilerplate. Since the WSJ didn't do this for its English language…
Or maybe they were trying to get past the great firewall of China?
Any idea whether this affects (randomized) A/B testing? I think that in the past, Google has simply ignored the dynamic test changes to the site's content. Now I'm not quite sure anymore.
As of when I left Google in 2010, the JavaScript random number generator always returned 0.5 (and some SEO figured it out and blogged about it, no secrets here). However, I was trying to convince my manager to let me instead seed a random number generator with an HMAC of all of the currently loaded HTML and JavaScript (to make it deterministic but hard to display something good 1 in a million times but 100% of the time to Google's indexing system).
I feel that dynamic websites are not websites, but applications. Even after this thorough research, I'd still be very wary of turning a primarily content-based site into a dynamic app. A plain HTML site is accessible, and will be accessible in a 1000 years. A site depending on (external) JavaScript sources will force John Titor to travel back in time to find version 1.x of jQuery. Starting with JavaScript abandons pr…
20 years ago a webpage was just text, but it has evolved in so much more.
I'd be ok with a data site rendering everything from a set of json files. There is more legitimacy in having the presentation done in static html.
Same would go with sites mixing different information sources (twitter, rss etc). You can do the data fetching server side, but the user might prefer having it done client side for a reason or another (transparency for instance).
These kind of sites woyld still be purely informative and yet having them heavily using js makes sense.
I could think of many more situations were generating html from a different format on the client side is the right way to go. Horses for courses.
This was actually my primary role at Google from 2006 to 2010. One of my first test cases was a certain date range of the Wall Street Journal's archives of their Chinese language pages, where all of the actual text was in a JavaScript string literal, and before my changes, Google thought all of these pages had identical content... just the navigation boilerplate. Since the WSJ didn't do this for its English language…
" Since the WSJ didn't do this for its English language pages, my best guess is that they weren't trying to hide content from search engines, but rather trying to work around some old browser bug that incorrectly rendered (or made ugly) Chinese text, but somehow rendering text via JavaScript avoided the bug." Or maybe they were trying to get past the great firewall of China?
Possible, but at that time the only affected pages were for a certain date range in their archives, not the most recent pages. I alse think the Great Firewall of China did simple context-free regex searches that would have caught the text in the JavaScript literals.
I'm just waiting for the first security researcher to exploit the googlebot.
My primary role at Google from 2006 to 2010 was executing JavaScript in the indexing pipeline (not exactly in Googlebot, but close enough). I knew I was executing probably every known exploit out there, plus a lot of 0-days, and took lots of precautions (single-threaded subprocesss with very restricted list of allowed syscalls, etc.). It's not perfect, but breaking out of the sandbox would require a kernel 0-day in t…