Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things to Know When Making a Web Application in 2015

blog.venanti.us

Post reply on HN
Print view View original

101–110 of 186 posts

Re: Things to Know When Making a Web Application in 2015

#101

Post by vdaniuk »

billyhoffman wrote: post #89
vdaniuk wrote: post #73

Earlier quoted context omitted.

jQuery CDN cache hit rate is 99.8%[0], Google CDN numbers should be comparable. So yes, you are leveraging browser cache for most popular libraries. Also I was talking from the subsequent requests from the same client. [0] https://www.maxcdn.com/blog/maxscale-jquery/

You are confusing browser cache hits with a CDN/edge server cache hit.jQuery, or MaxCDN for that matter has no idea what the "hit rate" of a browser cache is. This sentence should be a big clue: "We usually average around 15,000 hits per second to our CDN with 99.8% of those being cache hits." "We" in that sentence is Kris Borchers speaking collectively about the jQuery foundation, talking a MaxCDN interviewer. But h…

You are right, I was confusing browser cache with CDN cache hit. In their interview they state that:

"Our CDN is a huge part of the jQuery ecosystem. We usually average around 15,000 hits per second to our CDN with 99.8% of those being cache hits. This provides much better performance for those using our CDN as their visitors can use a cached copy of jQuery and not have to download it, thus decreasing load time."

Somehow because of that I assumed that they had analysis done to understand browser caching rates. My bad.

EDIT: Huh, funny thing. What exactly is the origin server for the CDN jQuery library when the request URI is https://code.jquery.com/jquery-2.1.4.min.js ?

What would be the point for going to origin server at all if versioned jquery libraries are static and do not change? Edge locations are for all intents and purposes an origin server. I think that the sibling comment may be more accurate in its assumption: 99.8% cache hit most probably are 200 vs 304 responses.

END OF EDIT

Nevertheless, I've spent more time to research the issue of random person loading a javascript library from browser cache.

Usage on top10k websites: Google JS CDN is used on 23.5% [1] jQuery DNS is used on 4% [4] CDNJS is used on 4% [2] jsDelivr is used on 0.5% [3] OSSCdn is used on 2% [5]

Supposedly set of websites that use a particular JS CDN belong are disjoint with a set of websites using a competitive CDN. Thus we can estimate total JS CDN use at 30% of top10k websites and literally millions of websites scattered around the internet.

As JS libraries popularity follows a power law distribution and libraries cache headers are set for a year and longer, I would suggest that the probability of top 100 JS libraries being already cached in a browser is really high.

Statistical data hints that JS cdns are in fact quite efficient at reaching their goals, but certainly doesn't prove anything conclusively.

[0]https://www.maxcdn.com/blog/maxscale-jquery/

[1]https://trends.builtwith.com/cdn/AJAX-Libraries-API

[2]https://trends.builtwith.com/cdn/CDN-JS

[3]https://trends.builtwith.com/cdn/jsDelivr

[4]https://trends.builtwith.com/cdn/jQuery-CDN

[5]https://trends.builtwith.com/cdn/OSS-CDN

Re: Things to Know When Making a Web Application in 2015

#102

Post by mandeepj »

joepie91_ wrote: post #65
tspike wrote: post #39

First of all, thanks for the nice writeup. I hate that comments tend to hone in on nitpicking, but so it goes. My apologies in advance. > If you're just starting out with a new web application, it should probably be an SPA. Your reasoning for this seems to be performance (reloading assets), but IMHO the only good reason for using a single-page app is when your application requires a high level of interactivity. In ne…

I fully agree with this. SPAs are for web apps , not web sites . For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for. Especially don't forget that no, not all your clients support JS. And there's no reason why they should n…

First page load can be totally server side generated. Once loaded on client side, you can check using modernizer or something if your user's browser supports the features that you need for SPA if yes then you can replace server side generated HTML structure with a client side version. Now, you can proceed with all of your server and client communication via your favorite SPA framework.

Re: Things to Know When Making a Web Application in 2015

#103

Post by balls187 »

cpitman wrote: post #91
grey-area wrote: post #67

Earlier quoted context omitted.

There are quite a few misleading or incorrect suggestions, to pick a few: Encryption passwords is not hashing (think this was fixed after publishing due to comments below) OAuth is not for authentication SPA is not suited to all or even most websites, and is far from being 'king' in any sense. CDNs have pros and cons, they don't suit everyone. Localisation does not mean serving assets closer to home, but translating…

Can you explain why OAuth is not for authentication? What does it not do that you expect an authentication system to do? What is fundamentally wrong with every site that allows me to sign in with a github/google/facebook account (via OAuth)?

> What is fundamentally wrong with every site that allows me to sign in with a github/google/facebook account (via OAuth)?

That is a inaccurate statement.

Those sites allow you to login with your Github/Facebook/Google Accounts. That isn't OAuth. Those sites also use OAuth in order to let 3rd party applications access the users data stored on that system.

Take this Scenario

Alan has a service that finds funny tweets. cpitman wants to use Alan's service, to find his funny tweets.

No OAuth Example:

cpitman gives Alan service his Twitter Username and Password.

Alan service logs into Twitter, and pulls twitter data.

With OAuth:

Alan service opens a request to Twitter asking for twitter data for cpitman

Alan service redirects cpitman to Twitter

Twitter notifies cpitman that Alan Service wants to access twitter data

cpitman agrees

Twitter passes back a token

Alan service uses token to access cpitman twitter data.

Re: Things to Know When Making a Web Application in 2015

#105

Post by fred2133 »

baddox wrote: post #87
joepie91_ wrote: post #65

Earlier quoted context omitted.

I fully agree with this. SPAs are for web apps , not web sites . For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for. Especially don't forget that no, not all your clients support JS. And there's no reason why they should n…

> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the In…

You should check your stats some time and see how many of your users fail to load your JS, rather than are capable of loading your JS. You might be surprised, especially if you have lots of mobile traffic.

Re: Things to Know When Making a Web Application in 2015

#106

Post by baddox »

liviu- wrote: post #92
baddox wrote: post #87

Earlier quoted context omitted.

> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the In…

I think he means that it's best to offer both variants with a graceful fallback for no-js users. This doesn't require sacrificing interactivity, responsiveness or UX for users with JS enabled.

It does, however, require a potentially large amount of work for a SPA. Granted, server-side rendering for JavaScript libraries like Ember and React is doable now.

Re: Things to Know When Making a Web Application in 2015

#107

Post by balls187 »

cpitman wrote: post #91
grey-area wrote: post #67

Earlier quoted context omitted.

There are quite a few misleading or incorrect suggestions, to pick a few: Encryption passwords is not hashing (think this was fixed after publishing due to comments below) OAuth is not for authentication SPA is not suited to all or even most websites, and is far from being 'king' in any sense. CDNs have pros and cons, they don't suit everyone. Localisation does not mean serving assets closer to home, but translating…

Can you explain why OAuth is not for authentication? What does it not do that you expect an authentication system to do? What is fundamentally wrong with every site that allows me to sign in with a github/google/facebook account (via OAuth)?

Contrast that with the following scenario.

Alan has a web application that shows you all funny tweets. In order to see those tweets you must first create an account.

Username/Pass

You pick a username, you enter a password. That combination is attached to Alan WebApp UserID: 12345

Everytime you login with that username and password combination, you get back Alan WevApp UserID 12345.

Google Login

You click the "Login with Google" button.

It redirects you to say "Do you want to associate your google account with Alans Web App?"

You click yes.

Google ID: XYZZY is returned. That id is tied to Alan WebApp UserID 12345.

The next time you go to login, Google returns "This is Google ID: XYZZY". Alan WebApp finds the association XYZZY with Alan WebApp 12345.

Re: Things to Know When Making a Web Application in 2015

#109

Post by [deleted] »

AdeptusAquinas wrote: post #57
tspike wrote: post #39

First of all, thanks for the nice writeup. I hate that comments tend to hone in on nitpicking, but so it goes. My apologies in advance. > If you're just starting out with a new web application, it should probably be an SPA. Your reasoning for this seems to be performance (reloading assets), but IMHO the only good reason for using a single-page app is when your application requires a high level of interactivity. In ne…

This is totally true. If you're just starting out, chances are you are not (or should not be) making any sort of application where the performance increases by operating as a SPA will be even be noticeable compared to a standard server app. Plus, I'd argue that you won't really understand what a SPA adds (or takes away) unless you are thoroughly familiar with the traditional model. Finally, at the end of the day trad…

[deleted]

Re: Things to Know When Making a Web Application in 2015

#110

Post by oldmanjay »

dorgo wrote: post #98
tomjen3 wrote: post #81

Earlier quoted context omitted.

Maybe not all my clients support javascript, but substantially all I care about do. I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it. Works very well.

I enable JS for sites I feel are valueable for me. The first impression is always without JS. If navigation-buttons dont work without JS - I just leave.

if you self-select into the group that isn't cared about, then do you expect your leaving to be cared about?

i ask only because i'm puzzled as to the purpose of your reply.

Post reply on HN