71–80 of 114 posts
This is a subject that really irks the engineering side of me. It's utterly ridiculous that engineering and efficiency decisions are so deeply affected by whether or not the largest search engine will properly index your content. Why is it that Google doesn't get flak for not discovering content that's engineered to send the absolute minimum over the wire, cache intelligently in localStorage and IndexedDB, and scale…
This is a subject that really irks the engineering side of me. It's utterly ridiculous that engineering and efficiency decisions are so deeply affected by whether or not the largest search engine will properly index your content. Why is it that Google doesn't get flak for not discovering content that's engineered to send the absolute minimum over the wire, cache intelligently in localStorage and IndexedDB, and scale…
It this problem really that difficult? Why?
Why should your code care if it is running on my computer or yours?
Isomorphic JS has been around for years. Build your product on bloated tech stack relying on a increasingly poorly planned web of dependencies, and I'll agree it could be challenging.
> Why can't I expose a REST API to deep link mapping and have Google just crawl my REST API
They do crawl REST APIs. Specifically, ones using Hypertext Markup Language.
> cache intelligently in localStorage and IndexedDB
Speak of hundreds of thousands of wasted engineering hours...HTTP caches are simple and straightforward. IndexedDB leaks memory in Chrome so badly that Emscripten had to disable it (https://bugs.chromium.org/p/chromium/issues/detail?id=533648 https://github.com/kripken/emscripten/pull/3867/files). Mozilla advised developers not to adopt Local Storage due to the inherent performance issues. (https://blog.mozilla.org/tglek/2012/02/22/psa-dom-local-stor...) And how many wasted hours went into WebSQL?
> utterly ridiculous that engineering and efficiency decisions are so deeply affected by whether or not the largest search engine will properly index your content
Actually, it makes a lot of sense. Content needs to be discoverable. Hosting a complex language in a VM where the slightest deviation from the 600-page specification (and that's just for the core language...not the browser APIs) causes failure -- that's not "discoverable". It's like putting up a billboard with one giant QR code, just because that makes it easier to develop the content.
This is a subject that really irks the engineering side of me. It's utterly ridiculous that engineering and efficiency decisions are so deeply affected by whether or not the largest search engine will properly index your content. Why is it that Google doesn't get flak for not discovering content that's engineered to send the absolute minimum over the wire, cache intelligently in localStorage and IndexedDB, and scale…
Uhh, the answer to all your "why"s is pretty much" because that would be an open door to abuse"? For better or worse, Google has figured that the best way for them to have the most accurate indexing is to get things the exact same way browsers do, and figure it out from there.
It's fairly clear that just by developing those webmaster tools, Google is effectively (and understandably to a point) saying that they won't try to create engineering solutions to certain problems. Or that at this point it's not a sound financial investment because, after all, people will come to them because they're the biggest game in town.
If you're referring to my alternate crawling strategy suggestion of mapping a deep link structure into a structured REST URL structure, that's just an optimization I'd love to see. Really, I just think that search indexers should index what my users see, regardless of my engineering decisions.
This is a subject that really irks the engineering side of me. It's utterly ridiculous that engineering and efficiency decisions are so deeply affected by whether or not the largest search engine will properly index your content. Why is it that Google doesn't get flak for not discovering content that's engineered to send the absolute minimum over the wire, cache intelligently in localStorage and IndexedDB, and scale…
This is a subject that really irks the engineering side of me. It's utterly ridiculous that engineering and efficiency decisions are so deeply affected by whether or not the largest search engine will properly index your content. Why is it that Google doesn't get flak for not discovering content that's engineered to send the absolute minimum over the wire, cache intelligently in localStorage and IndexedDB, and scale…
Google brings something that no amount of fancy engineering and elegant solutions can provide: New Users. Because of that it is necessary to dance to their SEO tune.
Of course, now that they're gigantic, they now are the primary force that's adding unneeded engineering complexity to keep content in a format they can already read.
So who's really helping whom?
Earlier quoted context omitted.
Google did not kill Flash. Chrome came bundled with Flash already installed. Apple made the biggest push to kill Flash and once support for HTML5 video was solid and widespread the main use case for Flash was gone. Java applets just always sucked and only masochists/sadists ever used them.
Adobe killed Flash itself, not Apple, not Chrome,not anti-flash troll X or Z on the internet.
Earlier quoted context omitted.
And here I was thinking that it was Apple and the iPhone that effectively killed Flash. Silly me.
They disliked flash for different reasons. Google for search and apple because flash games were too powerful, jobs wanted those games turned into iPhone apps. The offical reasons were speed and security, which was obviously a farce since all the major browser vendors wrote their own PDF viewers which is both slow and known for tons of security issues as well. They could have just as easily wrote their own fast and se…
Google went to significant efforts to sandbox it, but that still caused problems, not least with additional complexity. As for this idea that NPAPI should continue to live... Yes "security" is a problem with NPAPI.
As for Google fixing Java... You may have heard of Oracle? And the fact that they are .... not nice?
Earlier quoted context omitted.
Yeah, it would make sense. There has to be more reason to giving people a free web browser other than just that it uses Google search.
Chrome does send domains/urls entered in the omnibar to google (I think someone did the experiment to test it several years ago), but sending out page content to google? If it were true it'll cause a huge legal and privacy problem, especially in places with tight privacy law like Europe.
I'll mention that there is a ule that was added a few years back, in backbone.js days, that urls with /#!route anchors will enable (read: force) ajax requests and JavaScript from the spider. Still remains a helpful way to force caching/indexing of JavaScript-only pages in Google.
This is a subject that really irks the engineering side of me. It's utterly ridiculous that engineering and efficiency decisions are so deeply affected by whether or not the largest search engine will properly index your content. Why is it that Google doesn't get flak for not discovering content that's engineered to send the absolute minimum over the wire, cache intelligently in localStorage and IndexedDB, and scale…