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

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

#121

Post by hluska » Fri, Jul 10, 2015, 11:02 PM UTC

baddox wrote: post #118

joepie91_ wrote: post #114

Earlier quoted context omitted.

> Sure there is, if you care about interactivity, responsiveness, and general user experience. And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs. > The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. Your use of the term 'probably' suggests to me that you have not run any actual metrics. H…

> Your use of the term 'probably' suggests to me that you have not run any actual metrics. What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. > Requ…

It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story."

The comparison between JavaScript and a browser is very weak as a web app absolutely requires a browser, but JavaScript is most certainly not required. But, that aside, requiring JavaScript with absolutely no workarounds is a very bad idea.

Consider people who are sight impaired. Screen readers and heavy JavaScript really are not friends, but there is legislation in many countries that makes this basic kind of accessibility a legal necessity.

Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."

First, this is rude. Second, your comparison between JavaScript and click-only commerce is even weaker than your previous comparison between a web browser and JavaScript.

But, those points aside, the web was a lot different ten years ago. Ten years ago, I could browse the web with JavaScript turned off and I rarely came across sites that didn't work for me. When I came across sites that didn't work, they always politely had a that told me that the site needs .js. Today, my experience is the exact opposite and basic accessibility has faded.

Change is not necessarily positive - no website should require JavaScript. And, I'd argue that most applications should work without JavaScript.

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

#122

Post by joepie91_ » Fri, Jul 10, 2015, 11:13 PM UTC

> If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow.

The thing that everybody seems to overlook here: this has serious legal consequences.

You are demanding of your users that they agree to a set of TOS from a third party, that does not have either their or your best interests at heart, and that could have rather disturbing things in their TOS - such as permission to track you using widgets on third-party sites.

Not to mention the inability to remove an account with a third-party service without breaking their authentication to your site as well.

Always, always offer an independent login method as well - whether it be username/password, a provider-independent key authentication solution, or anything else.

> When storing passwords, salt and hash them first, using an existing, widely used crypto library.

"Widely used" in and of itself is a poor metric. Use scrypt or bcrypt. The latter has a 72 character input limit, which is a problem for some passphrases, as anything after 72 characters is silently truncated.

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

#123

Post by davnicwil » Fri, Jul 10, 2015, 11:20 PM UTC

jmulho wrote: post #88

davnicwil wrote: post #27

Earlier quoted context omitted.

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

That's exactly why the inverted advice needs to be heeded, so that that sucky experience, which does still occur daily with a lot of sites and apps, goes away by default.

Note, I'm absolutely not saying that a big screen desktop experience isn't inherently better for all but the simplest apps, there's very high probability it is because it's more ergonomic hardware with far more screen real estate.

However since most people want to, and do use mobile in preference to desktop for a huge proportion of tasks now, the design philosophy in most cases needs to flip from 'full functionality for desktop, scale down gracefully for mobile' to 'full functionality for mobile, scale up for desktop, taking advantage of the extra UX potential where possible'.

It's actually a far more optimistic, and creative, approach. Make it, then enhance it for the less popular use case rather than make it, then degrade it for the less popular use case.

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

#124

Post by JupiterMoon » Fri, Jul 10, 2015, 11:32 PM UTC

baddox wrote: post #118

joepie91_ wrote: post #114

Earlier quoted context omitted.

> Sure there is, if you care about interactivity, responsiveness, and general user experience. And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs. > The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. Your use of the term 'probably' suggests to me that you have not run any actual metrics. H…

> Your use of the term 'probably' suggests to me that you have not run any actual metrics. What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. > Requ…

> huge class of web apps

You have a failure of understanding here.

There is a difference between a web site and a web app (although there is blur in the middle obviously). A web site (e.g. this site, a news paper, a blog, a search page, a job application form etc) should not need JS - and frankly if you put it in there then you're over-engineering things. Meanwhile web apps like e.g. Google docs/Office 365, a webmail client etc are clearly going to need specific JS.

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

#125

Post by liviu- » Fri, Jul 10, 2015, 11:43 PM UTC

baddox wrote: post #111

fred2133 wrote: post #105

Earlier quoted context omitted.

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.

Just out of curiosity, what's the standard way to gather that data? I guess you could put a non-JS request (like an image) and a JS request (like XMLHttpRequest) on each page, and compare numbers.

A `` tag seems most intuitive to me, perhaps paired with some server-side Google Analytics.

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

#126

Post by baddox » Fri, Jul 10, 2015, 11:43 PM UTC

joepie91_ wrote: post #119

baddox wrote: post #118

Earlier quoted context omitted.

> Your use of the term 'probably' suggests to me that you have not run any actual metrics. What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. > Requ…

> What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. I was refering specifically to websites, not webapps. > It's really not the end of story, and i…

> I was refering specifically to websites, not webapps.

Okay, then yes, we were using terms differently. I consider web apps to be a subset of web sites (which is the standard usage as far as I knew), and thus I thought you were claiming that JavaScript should not be a requirement for any web site, including web apps. But you're using "web site" to mean web sites which aren't web apps, and in that case, I do agree.

I disagree with several claims you make later in that comment, but since I think I've addressed our primary disagreement I will leave it at that.

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

#127

Post by balls187 » Sat, Jul 11, 2015, 12:04 AM UTC

superuser2 wrote: post #113

balls187 wrote: post #28

Earlier quoted context omitted.

1. Why use OAuth unless you want to grant 3rd parties access to your services data, on behalf of your customers? 2. Security best practices subject to "open for interpretation."

While OAuth isn't "for" authentication, everyone uses it that way by "authorizing" access to "view your email address" which is as good as authenticating your email address.

Can you link to implementations that use OAuth in such a manner?

Login with FB, Google, Github, Twitter, etc different systems, separate from OAuth.

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

#128

Post by hello_there » Sat, Jul 11, 2015, 12:42 AM UTC

balls187 wrote: post #28

artmageddon wrote: post #22

Earlier quoted context omitted.

I took that to mean use both identity management as well as OAuth.

1. Why use OAuth unless you want to grant 3rd parties access to your services data, on behalf of your customers? 2. Security best practices subject to "open for interpretation."

> Why use OAuth unless you want to grant 3rd parties access to your services data, on behalf of your customers?

So, what would you use instead?

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

#129

Post by borski » Sat, Jul 11, 2015, 12:42 AM 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…

This is something we help with a lot at Tinfoil (https://www.tinfoilsecurity.com). You can read our blog for useful tips and info, but we always recommend actually running our web application scans against your app in order to actually look for vulnerabilities. Is it as good as having 'tptacek or someone else from Matasano looking at it as a human? Not quite, since humans have more ingenuity. Is it better than reading a blog post and trying to follow 'best practices'? Infinitely.

Don't try to do it yourself.

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

#130

Post by codingdave » Sat, Jul 11, 2015, 1:22 AM UTC

balls187 wrote: post #32

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.

> So why not just accept the post for what it is - some basic advice to do that one better step. http://www.nytimes.com/2015/07/10/us/office-of-personnel-man...

Do you honestly feel that the work of beginning web developers falls into the same risk management quadrant as a major governmental database of personal information?