Things to Know When Making a Web Application in 2015
Over the past year I've been working on building my first serious web application from scratch. The experience has taught me a lot that I didn't know previously, particularly when it came to security and user experience.
It's worth noting that the last time I tried building anything of any reasonable complexity was in 2005, so - in my defense - there was a lot for me to catch up on.
Even outside of what I knew about or had seen before, the laundry list of details to remember when making a web application can make it easy to forget something important - especially when you're just starting out.
This checklist isn't in any way exhaustive, and if you're an experienced developer I doubt there's anything here that'll surprise you, but I hope it'll prove helpful to those whom might otherwise have missed something.
Security
Confirm emails: When users sign up, you should e-mail them with a link that they need to follow to confirm their email. If a user updates their e-mail address at some point later on down the road, that same workflow should be triggered again.
Identity Management: When storing passwords, salt and hash 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.
Encryption: For all of its problems with certificates, there's still nothing better than SSL. Use it. Use HSTS as well.
Credentials: Don't ever check any sort of server credentials (API keys, database passwords, etc.) into source control.
Eng: Animations
For the love of all that is holy, don't animate everything on your app. Most CSS animations will trigger a layout redraw; you're best off limiting yourself as much as possible to transforms and opacity.
Avoid lazy transition calculations, and if you must use them, be sure to use specific properties (e.g., "transition: opacity 250ms ease-in" as opposed to "transition: all 250ms ease-in")
UX
Forms: When submitting a form, the user should receive some feedback on the submission. If submitting doesn't send the user to a different page, there should be a popup or alert of some sort that lets them know if the submission succeeded or failed.
Login redirects: If a user attempts to access a page on your site but isn't logged in, they should first be 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).
If they try to log-in and provide an incorrect password, provide a visual cue to remind them that they have the option to re-set their password if they've forgotten it.
Subscription settings: Any emails you send a user should include, at the very least, a link to a page on your application where they can modify their email settings, and preferably a separate link that unsubscribes them from all emails as well.
Don't make them e-mail you to unsubscribe.
Mobile
You don't have to develop for mobile...but whether or not you do, you should make sure it's an active decision, since it'll have a material impact on the design and engineering of your application.
The following notes assume that you've chosen to target mobile as one of your platforms. I happen to use Grunt as my build tool, so I've included some Grunt-specific plugins that I use, but something analogous probably exists for whatever JavaScript build tool you're using.
Engineering
Single Page Apps: These days the single-page application (SPA) is king. 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. If you're just starting out with a new web application, it should probably be an SPA.
UI
Resolutions: While developing your MVP, you probably don't need to make sure your UI works on every possible mobile device out there - but you should make sure it works on a basic range of phone and tablet resolutions. Leave worrying about every device until after you've hit product-market fit.
UX: Bandwidth
One of the big themes with mobile is that bandwidth is a more precious resource than it is on the desktop. Accordingly, you should look for every opportunity to decrease the number of requests being made, make them asynchronous where possible, and decrease the size of the resources being requested.
JS & CSS - Concat and minify: You should usually be concatenating all of your application-specific JavaScript and CSS files into standalone files (one for JS, one for CSS) and minifying them. Grunt-contrib-concat, Grunt-contrib-cssmin and Grunt-contrib-uglify are your friends here.
All assets - Use a CDN: There are two major advantages to using a CDN. The first applies to all hosted assets, and that's localization - a CDN makes sure that the resources served are located in a region that's geographically close to the user requesting them, reducing load times.
The second applies more to your dependencies (i.e., non application-specific styles and JS code). Here, using a CDN for your dependencies has the potential to greatly reduce loading times for your users by relying on their caches. For instance, since many sites will rely on Angular.js, using a CDN to link to the core Angular code will trigger a cache hit, and the user's mobile device will retrieve it from the device cache rather than making another HTTP request.
CSS - Reduce your footprint: Most developers starting out will probably use some sort of UI framework (e.g. Bootstrap, Foundation, etc.). These frameworks can be quite large, and while minified versions of their stylesheets are usually available on most CDNs, it's unlikely that you'll need all of the included styles. Consequently, a tool like uncss (typically paired with something like processhtml) can be incredibly valuable at removing the styles you don't end up using.
It's important to note that the uncss parser can't pick up dynamic styles (styles that only appear in response to, say, JavaScript events), so you'll have to be rigorous in your browser testing to make sure you don't cut styles that are in fact in use in your application.
CSS - Put crucial things in the head: Styles that need to be seen before the app is even finished loading should go in the head; less important styles can afford to be loaded later.
JS - Reduce your footprint: Since your JavaScript code doesn't need to have any of its internal variables make sense to a human reader once you're in production, it can be helpful to rename all those user.email vars to u.e to reduce your file size. Fortunately, there's a tool to do this - the aforementioned uglify, which makes JS code completely unreasonable, but usually much smaller.
UX: Forms
While it's generally good advice to keep your forms and workflows simple, this is especially important if you're also targeting mobile as a deployment platform. Nobody wants to fill out a 5-page form on their iPhone.
I hope this list proves useful to those of you just starting out on your first web application - or even for those of you who've maybe worked on backend or design before but weren't as familiar with some of the frontend optimization tricks. If you can think of other hints or things to remember when starting out, let me know and I'll see about adding them to the list.
Discuss this post on Hacker News or on Twitter (@venantius)
Thanks to Chris Dean (@ctdean), Danny King (@dannykingme) and Allen Rohner (@arohner) for not only reading drafts of this post, but for adding to it.