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

71–80 of 186 posts

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

#71

Post by Silhouette »

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 was one of the points that stood out for me in the article too, also because I strongly disagreed with it. There is nothing inherently wonderful about doing everything client-side.

You get a much more limited range of languages and libraries to work with. You get to use overcomplicated build and deployment processes with ever-changing tools. You get to reinvent the wheel if you do want to use things like URI-based routing and browser history in a sensible way. In many cases you are going to need most of the same back-end infrastructure to supply the underlying data anyway.

Also, it's tough to argue the SPA approach is significantly more efficient if it's being compared with a traditional web app built using a server-side framework where switching contexts requests exactly one uncached HTML file, no uncached CSS or JS in many cases, and any specific resources for the new page that you would have had to download anyway.

Of course some web apps are sufficiently interactive that you do need to move more of the code client-side, and beyond a certain point you might find it's then easier to do everything there instead of splitting responsibilities. I'm not saying everything should be done server-side; I'm saying different choices work for different projects and it is unwise to assume that SPA will be a good choice for all new projects.

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

#73

Post by vdaniuk »

billyhoffman wrote: post #61
vdaniuk wrote: post #44

Earlier quoted context omitted.

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, "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/

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

#74

Post by tenken »

balls187 wrote: post #34
codingdave wrote: post #29

Earlier quoted context omitted.

Security is never perfect. It is a deterrent, not impenetrable prevention. So sure, to security people, it is never good enough. To everyone else, a easy to digest blog post might give them food for thought that would make their work one step better than it was before, resulting in security that is still flawed, but better. So why not just accept the post for what it is - some basic advice to do that one better step.

If you're going to do something, do it right. Security is never perfect, and to security people, we know that there is a tradeoff between Security and Users. We don't advocate letting The Perfect be the Enemy of the Good when it comes to security, and on the same token we want you to implement security properly if you do it.

"right" is subjective. there is always "good enough for right now, with the tools available, and the budget in hand".

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

#76

Post by balls187 »

paragon_init wrote: post #66
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-appse…

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

True. You don't need to hire consultants to perform a security audit. Ask HN and Security Stack Exchange are good free alternatives to get critiques on your approach.

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

#77

Post by jaawn »

grey-area wrote: post #67
jaawn wrote: post #50

Earlier quoted context omitted.

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…

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 not for authentication, someone better tell Google: "Google APIs use the OAuth 2.0 protocol for authentication and authorization." [1]

TLS is basically just the newest version of SSL. The name was changed for legal reasons. So it is an understandable oversight [2]

The others aren't security related, so I didn't address them.

[1] https://developers.google.com/identity/protocols/OAuth2

[2] http://security.stackexchange.com/questions/5126/whats-the-d...

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

#78

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…

The title and article are also for web apps, not web sites.

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

#79

Post by dragonwriter »

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.

The special property that encryption functions have compared to hashing functions isn't that it is extremely difficult to discover the source, but rather almost the reverse -- that for every encryption function there exists a function (decryption function) by which you can recover the unique source.

Hashing functions in general do not have an inverse function: while you might be able to recover several possible sources from them (and this might be easy or difficult), you cannot recover the single source, because the space of inputs is larger than the space of outputs, so there can be no unique mapping from outputs back to inputs that would generate them.

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

#80

Post by schnable »

toynbert wrote: post #47

As a web application developer in 2015+ I would argue that developing with mobile in mind should be required. At least taken into consideration. At bare minimum have a pre-deployment test: is my app unusable/does this look terrible on the most popular iphone/android.

And that it passes Google's mobile check, so it doesn't get penalized in SERPs.
Post reply on HN