221–230 of 263 posts
Earlier quoted context omitted.
I hope the 10ms quote is for a localhost connection, otherwise I'll read it like I do huge fish weight on my father's last fishing trip.
No, the 10ms is because you don't have to hit the server on every page load.
Earlier quoted context omitted.
Do you have any statistics to back up your assertion that it's growing? From what I've seen from my own anecdotal experience, as well as from access logs from past places I've worked, this minority is vanishingly small ( Regardless, there is no right or wrong answer in general, there is only the right or wrong answer for your particular website/market. If a significant number of the users you want to support have JS…
How do you differentiate a user using NoScript from a bot dismissed as a browser? If just I look at my logs, more than 90% of the access are from Firefox and don't run Javascript.
Earlier quoted context omitted.
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.
To hold to your definition of Turing completeness would make the term effectively pointless. If you relax the definition only so slightly, suddenly it has meaning again to say that something can be Turing complete.
Earlier quoted context omitted.
Not if you are prepared to buy more RAM (or disk space for swapping) as the program is running.
There's only so much RAM in the universe.
"And most importantly: Don’t be ashamed to build 100% JavaScript applications. You may get some incensed priests vituperating you in their blogs. But there will be an army of users (like me) who will fall in love with using your app." This statement needs a huge, HUGE caveat that you should only be building 100% JavaScript apps in situations where doing so makes sense . For example, I find the new Blogger "web app" i…
Performance is paramount. On many smartphone browser tabbing out while I wait for your slow-assed page to load and render isn't an option like it would be on the desktop. I feel the pain of every lazy-loaded image, every sluggish layout script, etc. Many "responsive" pages are actually the worst culprits.
Yes, I need a new phone. But older smartphone browsers aren't exactly a rare use-case.
Earlier quoted context omitted.
There are two different kinds of minority to consider: 1. People who are part of a minority by choice. For instance, they choose to use an old computer, old OS, old web browser, etc. even though it is within their means to upgrade. Or they have current software but intentionally restrict it with add-ons like NoScript. You might be justified in not catering to these minorities, because it's just not profitable and you…
I should've phrased it better, but I was asking him as a person of minority by choice. I fully understand making a site accessible for those who need it, but I don't understand the NoScript people.
Also, if you don't have an unlimited Internet plan, not having to download 5MB of trackers, "analytics" scripts and Flash ads can be a pretty significant advantage.
Earlier quoted context omitted.
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.
That's the opposite way of putting it. The way of extra work to support edge case users that often aren't worth the effort. Now maybe it's worth it for a big enough site, but for the average site I doubt it ever is. I think it perfectly reasonable to ignore users who disable JavaScript for most websites.
Earlier quoted context omitted.
In all honesty, why should I care about you, the tiny minority? Why should I waste any time at all worrying about you?
There are two different kinds of minority to consider: 1. People who are part of a minority by choice. For instance, they choose to use an old computer, old OS, old web browser, etc. even though it is within their means to upgrade. Or they have current software but intentionally restrict it with add-ons like NoScript. You might be justified in not catering to these minorities, because it's just not profitable and you…
Earlier quoted context omitted.
I've been building 100% JS apps for 4 years now. With proper fragment loading, rendering optimization, and CDN usage, the apps appear to load just fast as an asp/php/jsp page (i.e. 200ms). Once the base page is loaded, page loads are instant (i.e. 10ms) smoking a non JS web app. Blogger is sadly a dog and has been for the longest time. Profiling it just now, some of the blocking JS dependencies take > 800ms to load.…
I hope the 10ms quote is for a localhost connection, otherwise I'll read it like I do huge fish weight on my father's last fishing trip.
I quote 10ms as client side code to produce the new HTML and browser painting events can take time, but if you used a canvas or similar you could cut down even further on that render time.
Earlier quoted context omitted.
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.
https://news.ycombinator.com/item?id=3985981
However, from working with customers of BromBone, I know this. People have javascript powered webpages that were not getting indexed by Google. Google would crawl the page, and see no content. The pages were not in Google. After creating prerendered snapshots and serving them when the _escaped_fragment_ parameter was present, the pages showed up in Google.