191–200 of 263 posts
Not a single mention of SEO on the article. I guess Google is dead too.
It wasn't mentioned because that particular fallacy has already been beat to death. Take a look at Discourse or Bustle. They're pure Javascript apps that are still SEO-friendly.
And the Phantom.js approach mentioned below seems more like a workaround to me than a solution
Earlier quoted context omitted.
Hardly, you have to consider the additional cost of attempting to support that additional 2%; it could very well cost more than it's worth in development time and long term complexity. Of course that's an app specific decision. Every market you specialize for has a cost, short term and long term, so it has to be worth it financially; businesses aren't in the habit of just being nice for no reason.
Another way to put it is that vanilla HTML will support the full market so you have to be confident that moving away from it will cover that margin in revenue or savings just to break even. On a large commerce site for example, even a small percentage of revenue could be a staggering amount.
Earlier quoted context omitted.
Google has been crawling AJAX'd websites bypassing the _escaped_fragment_ mechanism for at least a year now.
Has it really? Do you have an example? I've never seen an example where Google crawled a page and included content that was loaded via ajax or an external javascript file. I have seen Google index content that is loaded from a script tag included in the html page.
Earlier quoted context omitted.
Turing machines are not infinite. There are merely big enough for everything you want to do. (I.e. actual infinity vs potential infinity.)
Turing defined the machines with reference to an infinite tape. Obviously any given machine (that halts) isn't going to use all of it. If you give any specific hard bound, you have a system which can be implemented on a sufficiently large FSM. There is, therefore, a sense in which you can never "need" a Turing complete system to solve any given problem that you can solve with finite resources.
Earlier quoted context omitted.
On slow connections I can sometimes only get the base html to load. No images, no external CSS or js. Extra requests for content are just asking for trouble. Worse, when I'm halfway around the world my ping is atrocious. It doesn't matter how quickly you generate your content for me, it's going to take twice as long for me to get it if you don't send it the first time I ask for it. If I click on a link on your page a…
In that case, you'd likely prefer a JS based app that used its app manifest to cache the actual moving parts (JS/images) before you headed on vacation and landed on that slow connection. Now it only makes a bare minimum of compressed RPC's to provide the page with the content to render itself. Depending on the content being rendered, you could even get an RPC down to one or two packets, much better than sending you t…
Speaking as somebody who's been in that case, no.
1. The app manifest doesn't need "JS-based apps", they're indepedendents
2. Assets caching doesn't need the app manifest either
3. Stop breaking stuff which works. HTML works, your shitty application does not.
Earlier quoted context omitted.
I think this is a valid generalization. On a page that doesn't use JavaScript, some links, form fields, and/or buttons may be unlabeled, but a blind user at least knows they're there and might be able to look at some hints to their functionality, such as URLs or element IDs. Moreover, the controls and interactions are standard. What happens if the developer attaches some functionality to a device-dependent event, suc…
Today's reasonably-built JavaScript-based applications are built using HTML as templates. They don't use a as a button, they use a as a button. They don't invent navigation using JavaScript, they use tags and a JavaScript-based router. Take a look at discuss.emberjs.com, which uses Discourse (which is powered by Ember... INCEPTION): On the front page, every navigation, including the links on top and the links to indi…
Earlier quoted context omitted.
A versioned JSON API is awesome, I am not denying that. I also don't deny that the current state of the HTML markup on most sites is semantically rubbish. Regardless of this entire PE debate, we would still have a problem, on the web, of data being out of reach due to walled apps that only serve rubbish HTML. The problem of open + semantic data is very relevant to this discussion but we're pretending that one "side"…
and in fact that particular bustle link you posted is a perfect example of where using HTML5 + microdata would be not only faster to render and crawlable but also allow the underlying data structure to be consumed by javascript. There's no reason why Bustle.pageData.article.title couldn't have been extracted from Why We Should Root for Lamar Odom ...
Should I mark my concrete item as flingy where some elements are thingies or should that be a thingy with some subelements as flingies?
I just did my best and called it a day. Then spend a lot of time debugging it in the microdata analyzer tool.
People that consider app should be usable entirely without javascript certainly miss the point. So do people that consider progressive enhancement is only about supporting people that deactivated javascript.
As author mentioned, the browser is now more an execution environment rather than a document viewer. You know what it means ? It means that developers have no control over the execution environment. With server side, if it works for you, it works for everyone. With client side, you'll never know. You don't know what extensions your user use. You don't know how stable his system is. You don't know how stable his connection is. And you can't ask your users to have a such carefully crafted environment as your servers.
What this should make us concludes is that the most heavily your app rely on javascript, the better it should be at error handling.
Earlier quoted context omitted.
JavaScript architecture skills evolved much more slowly than traditional back-end web development and of course it's more difficult to monitor errors that happen on the client side, so yes, it's still a reality that there is a correlation between heavy javascript and broken pages. However I don't think citing the problems with Flash and Java Applets is applicable. JavaScript maturity is explicitly the long-awaited re…
Javascript is no cure-all. Just like flash and java, avoiding the subjugation of built-in browser features (back button, bookmarking, hyperlinks, context menus, copy and paste) requires explicit effort many developers simply don't give either out of laziness or ignorance. Being able to CURL any page on your site and parse it using standardized, agreed upon tag names is a feature.
But the vast majority of my users don't even know what cURL is, so why should I worry about this? And in any case, I believe that if I wanted to extract content programmatically, consuming the same API that the Javascript uses to fetch content would be much easier than extracting it from HTML.
Earlier quoted context omitted.
What, exactly, is the issue with writing a simple content site that requires JS? If you aren't pulling in half a MB of JS, but it does require scripting to function, I don't see the problem. Just because I could spend the effort to be progressive doesn't constrain me to have to do it. It doesn't make me a lazy programmer either: just pragmatic. 99.99% of the people visiting my site have JS enabled and I'm happy to su…
Search-engine optimization is a large part. The fact that the JS frequently results in lower usability is biggest on my list. I've encountered Blogger themes which are so fucking piss-poor I literally cannot read them, even with JS enabled. If the primary goal of your site is content, stick with vanilla HTML. You're vastly better off for it.
It doesn't look like it is too difficult to add search indexing support.
http://eviltrout.com/2013/06/19/adding-support-for-search-en...