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

81–90 of 186 posts

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

#81

Post by tomjen3 »

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…

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.

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

#82

Post by balls187 »

jaawn wrote: post #50
balls187 wrote: post #19

If you're new to web application development and security, don't blindly follow the advice of someone else who is also new to web application security. You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant. Security is a hairy issue, and no si…

In general, you may be right, but the security suggestions in this particular post are the same I hear from people "who have experience in security." Also, they often encourage readers to basically go out and find the thing everyone says is the best thing (i.e. "When storing passwords, salt and hash them first, using an existing, widely used crypto library.") I challenge you to point out specific suggestions in this…

My first comment on this article was pointing out that Facebook Login et al isn't OAuth.

I am guilty of not editing that one comment to hang my other comment off of.

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

#83

Post by grey-area »

jaawn wrote: post #77
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…

Most (all?) encryption functions are also hash functions, they're just special hash functions with the extra property of making it extremely difficult to discover the source. (edit: I realized after posting this, that this item is incorrect in regards to the cipher text, which obviously changes in length in relation to the length of the source, unlike the output of a hash function which is a fixed length) If OAuth is…

Most (all?) encryption functions are also hash functions, they're just special hash functions with the extra property of making it extremely difficult to discover the source.

There's a fundamental difference between storing a password so that you can read it again (encrypt implies this), and storing it so that you can only verify it, not read it (hash). But a broader criticism of the article is that it is far too sweeping in its judgements based on scant knowledge of the topic - the little mistakes are just indications of that.

It's fine to be a beginner asking questions and the mistakes are not really so important, but it's not really useful to attempt a definitive summary of a field which you know very little about.

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

#84

Post by arikrak »

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 often find many ajaxy effects on websites don't work work. For example, when I click to expand a comment in Quora, it often fails and I find it much quicker to just open it in a new page.

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

#85

Post by balls187 »

jaawn wrote: post #77
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…

Most (all?) encryption functions are also hash functions, they're just special hash functions with the extra property of making it extremely difficult to discover the source. (edit: I realized after posting this, that this item is incorrect in regards to the cipher text, which obviously changes in length in relation to the length of the source, unlike the output of a hash function which is a fixed length) If OAuth is…

OAuth isn't for Identification.

You can use OAuth for authentication, but that is specific purpose for Authorization.

Google has a separate product for Sign In:

https://developers.google.com/identity/sign-in/web/

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

#86

Post by anton_gogolev »

> sent to a page where they can log in, and after that should be redirected to the page they were originally trying to access (assuming, of course, that they're authorized to do so).

Smells like an information discolsure highway. I usually 404 all requests that hit "unauthorized" content.

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

#87

Post by baddox »

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…

> 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 Internet.

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

#88

Post by jmulho »

davnicwil wrote: post #27
jameshart wrote: post #20

"You don't have to develop for mobile..." ... well, no. Technically you don't have to. But you almost certainly should .

Was surprised to see this too, considering the article's title is Things to Know When Making a Web Application in 2015 If anything the advice should be inverted by replacing 'mobile' with 'desktop'

In 2015, my primary use of web apps "for mobile" is to find the link that says "full site".

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

#89

Post by billyhoffman »

vdaniuk wrote: post #73
billyhoffman wrote: post #61

Earlier quoted context omitted.

First, research on hit factor: https://zoompf.com/blog/2010/01/should-you-use-javascript-li... http://statichtml.com/2011/google-ajax-libraries-caching.htm... https://github.com/h5bp/html5-boilerplate/pull/1327#issuecom... I have more recent data on this that is not yet published from my day-to-day work at a web performance company. The pictures has improved somewhat, but not significantly. You are correct, "Overhead…

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 he is not talking about the browser cache. He can't be, because jQuery, or MaxCDN for that matter has no idea what the "hit rate" of a browser cache is.

Example: If I go to 1.example.com, which links to maxcdn.com/jquery.js, and then later I go to site 2.example.com, which links to the same maxcdn.com/jquery.js file, my browser doesn't send any requests! That is the entire point of far-future caching! I was able to use the version of jquery that was in my browser cache. However MaxCDN, or jQuery for that matter, have no idea this hit took place.

By the same token, if I go to 1.example.com, which links to maxcdn.com/jquery.js, and then later I go to site 2.example.com, which links to a different URL like maxcdn.com/master/jquery.js, my browser has a cache miss. /master/jquery.js is not in my browser's cache, I've never been there. MaxCDN, or jQuery for that matter, have no idea that I requested something different then before.

CDN cache hit rate has nothing to do with browser caches. In fact, people that are not you, being able to detect if something is in your browser cache or not, is a massive security problem. See my talk at BlackHat in 2007, Many of Jeremiah Grossman's talks at BlackHat (2006, 2007, 2009), or go all the way back to Ed Felton's work on using the timing side channels against browser caches.

In the industry, "99.8%" cache hit on a CDN's edge server means that 99.8% of the time the edge server can handle the request, instead of the request having to go all the way to the origin. They have no way of knowing how often a random person on the internet loads a random file from their browser cache.

This whole thing proves my point: Calling shared, common, publicly hosted copies of popular JS libraries "CDN's" or "JavaScript CDNs" is just confuses people. CDNs are about reducing latency. Share JS libraries are about trying to avoid requests altogether by leveraging the browser cache, and they are largely ineffective.

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

#90

Post by martin-adams »

>> When users sign up, you should e-mail them with a link that they need to follow to confirm their email

I'm curious, why is this good? Sure, sending an email to them so they confirm they have the correct email, but what is the benefit of the verification step? Is it to prevent them from proceeding in case they got the wrong email? It would be nice if this was justified in the article.

I would also add, that changing a password should send an email to the account holder to notify them. Then when changing the email address, the old email address should be notified. This is so a hijacked account can be detected by the account owner.

Post reply on HN