Live data from Hacker News

Things to Know When Making a Web Application in 2015

blog.venanti.us

131–140 of 186 posts

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

#131
post #118

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…

> JavaScript is an integral part of the platform that is the web, just like HTML and CSS

I always think it's interesting when people bring CSS into this, because it's actually a very strong counter to the general argument.

By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea what the UA's capabilities are, up to and including whether or not it's doing any kind of visual rendering at all.

This isn't a news flash to everyone, but even those already aware of this seem to think the main reason you'd do this is ADA accommodations and those are some kind of minority afterthought. My experience is that this is misguided -- accommodations for unusual visitors is important, but I think the biggest benefit might be that the simpler you make things for the client, the less complicated the engineering tends be, even if you can't import your Java-imitation-of-smalltalk-inspired application paradigm of choice.

And "too bad if you didn't have JS!" position seems to basically boil down to the idea that serving a custom client that consumes JSON instead of HTML as the media type for a given URI is Real Progress™.

Keep things as simple as possible. Don't require JS unless what the application needs to do can't be done without it.

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

#132
post #121
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…

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…

Screen readers a JavaScript get along just fine if a site is coded well. A SPA can be perfectly accessible. The Section 508 refresh is well underway and will essentially be WCAG 2.0 AA [1]

[1]: http://www.w3.org/WAI/WCAG20/quickref/

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

#133
post #98
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.

Honest question - What are you trying to prove by not enabling JS by default?

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

#134
post #96
post #40

Earlier quoted context omitted.

The only acceptable advice in this situation is "use bcrypt". Vague stuff about "hashing or encrypting" is not good enough.

Wait, what about "scrypt"? Maybe the only acceptable advice changed in the last hour? :-)

Bcrypt is a very easy to use hashing tool that exists in all popular languages. It is the best choice, and the easiest to implement.

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

#136
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…

If you need a backend, starting with a SPA has one strong point, decoupling, you can leave your backend unmodified and start writing that native iOS, Android client or desktop client when needed it.

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

#137

Earlier quoted context omitted.

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.

GitHub How To: https://developer.github.com/guides/basics-of-authentication... And the OpenID Connect standard (essentially OAuth V2 + identity service): http://openid.net/connect/

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

#138

>When storing passwords, encrypt them Nopenopenopenopenope! This is terrible advice. Don't do this. Remember what happened when Adobe did this?

I hope that at least some services will eventually consider that for sites that aren't storing valuable data, Passwordless (i.e. emailed, etc. one-time token) and long-lived session tokens are better than even touching passwords.

Are there actually any sites that do this? It is somewhat interesting.

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

#139
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…

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.

Also, most of the corporate people still have forced IE installed on their work laptops. SPAs do generally break in IE.

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

#140
post #133
post #98

Earlier quoted context omitted.

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.

Honest question - What are you trying to prove by not enabling JS by default?

Aside from the fact that JavaScript is often poorly written, I generally don't want untrusted code running on my computer.
Post reply on HN