Things to Know When Making a Web Application in 2015 • Hacker News Board

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

#61

Post by billyhoffman » Fri, Jul 10, 2015, 8:17 PM UTC

vdaniuk wrote: post #44

billyhoffman wrote: post #35

Earlier quoted context omitted.

Just to clarify. General CDNs tend to be a good idea of you are having latency issues. Standard libraries for major JavaScript project, all served from a single shared CDN (like Google, maxcdn, cdnjs, etc) also tend to be called "CDNs" but this is a little confusing. Yes, these shared files are often stored on a CDN, but that's not the so-called major benefit of these shared hosts. The main benefit is supposed to be…

Ugh, I will never understand this reasoning. Overheads of fetching library from a CDN are applicable to the first request. Why do you consider this to be an important factor? Also can you provide any stats/citation that cache hit probability on first request is in fact very low?

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, "Overheads of fetching library from a CDN are applicable to the first request" The problem is, because of the fragmentation, every website is asking you to hit a different URL, so every request is a "first request". You aren't leveraging the browser cache.

Most sites are already serving you site-specific JS anyway over a warm connection (even more so with HTTP/2), so there is even less benefit to going to a 3rd party host to potentially avoid downloading a few dozen kilobytes. Couple that with the security implications of injecting 3rd party code into your page, its just plain silly and wasteful to do this for a modern website.

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

#62

Post by sarciszewski » Fri, Jul 10, 2015, 8:17 PM UTC

>For all of its problems with certificates, there's still nothing better than SSL.

Yes there is. It's called Transport Layer Security (TLS).

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

#63

Post by ahayschi » Fri, Jul 10, 2015, 8:18 PM UTC

Domenic_S wrote: post #41

How to make a reasonbly-decent webapp in 2015 without having to worry about bcrypt and open redirects and such: 1. Use a widely-accepted framework. 2. Implement your application using that framework's methods. Why a beginner would implement even 1/3 of this list manually is beyond me.

I think this is more of a question of what kind of project or team you are working on, not one of experience in web development. Because it seems that you're suggesting beginners use Sails or Meteor (if focusing on JS), which are great and allow for rapid prototyping, but they and other 'high-level frameworks' that implement these methods for you tend to be very opinionated with important details of developing for the web abstracted away.

If you're a student or are serious about learning web development (and want to focus on developing in JS), it would make a lot of sense to dedicate your time to actually learning Node and Express, figuring out all of these hairy details and 'manually' implementing the items in Venantius' list.

Or don't figure out the hairy details, because many of his items have proven and documented solutions in the Node context, and learning how to properly use bcrypt and passport isn't too difficult. These libs are a good middle-ground between low-level details and something more out of the box.

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

#64

Post by baby » Fri, Jul 10, 2015, 8:19 PM UTC

ovi256 wrote: post #8

rfrey wrote: post #4

Earlier quoted context omitted.

The full quote is: "When storing passwords, encrypt them first, using an existing, widely used crypto library. If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow." Can you elaborate on what's so "nope" about that advice? Are you saying one shouldn't encrypt passwords?

Of course one shouldn't encrypt them, one should salt and hash them. With a cryptographically secure hash such as bcrypt or scrypt. If you use a batteries-included web-framework, this is already done for you. If you do not, you better understand the tradeoff of redeveloping those parts.

and if you're salting them yourself you're doing things wrong, use a good library that takes care of these little crypto details for you.

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

#65

Post by joepie91_ » Fri, Jul 10, 2015, 8:20 PM UTC

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 webapps, not websites.

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 need to, for a website.

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

#66

Post by paragon_init » Fri, Jul 10, 2015, 8:21 PM UTC

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…

If you are a business, then definitely yes. But the average self-taught developer will not have the resources available to hire a security consultant.

Instead of throwing money at the problem, you can instead choose to teach yourself more about the subject. We maintain a curated list on Github for people interested in learning about application security for this very reason.

https://github.com/paragonie/awesome-appsec

But if you're a company and your operating budget is in the millions of dollars hire a security consultant!

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

#67

Post by grey-area » Fri, Jul 10, 2015, 8:24 PM UTC

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…

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

Nothing better than SSL? TLS

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

#68

Post by blowski » Fri, Jul 10, 2015, 8:24 PM UTC

Quanttek wrote: post #54

> The key advantage to an SPA is fewer full page loads - you only load resources as you need them, and you don't re-load the same resources over and over. I don't know much about web development, but shouldn't those resources get cached? Isn't the disadvantage of SPAs that you are unable to link to / share a specific piece of content?

> Isn't the disadvantage of SPAs that you are unable to link to / share a specific piece of content?

Actually, this is achievable with push states, so isn't a strong argument against single page apps.

I think the problem with SPAs is that they exacerbate memory leaks, since they don't have the typical 'reset' of a browser page load to clear them. Also, a lot of SPAs re-implement browser functionality like scrollbars and the back button without proper cross-browser testing - let alone usability testing.

Conceptually, there's nothing wrong with SPAs, but many of the implementations are shoddy at best with no clear advantage gained.

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

#69

Post by mbq » Fri, Jul 10, 2015, 8:27 PM UTC

devNoise wrote: post #31

Question about JavaScript and CDN for mobile devices. Should I use a CDN for standard libraries or should I just concat and minify all my JavaScript? The concat and minify seems better as that reduces the JavaScript libraries and code load to a single HTTP request. A CDN seems nice in theory. Reality is: Does the browser have the library cached? Is the library cached from the CDN that I'm using? The browser is making…

Also pulling anything from CDN basically means that CDN operator (or anyone that will manage to hack it) can spy on or alter communication between your users and your server.

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

#70

Post by cpeterso » Fri, Jul 10, 2015, 8:28 PM UTC

quadrature wrote: post #58

This is a bit of a pet peeve of mine, but that banner image is 10 megabytes, it can be compressed down to 2mb without any perceptible loss of quality. Heck it could probably be shrunk further if you can accept a bit more loss because most of the image is blurry and noisy anyway. heres a compressed version: https://www.dropbox.com/s/bw606t7znouxpj1/photo-141847963101...

Ironically the original banner image doesn't even load for me on iOS Safari.