I work at Mozilla in London, UK

Engineering Manager @FirefoxDevTools

I'm also Spanish

English is not my first language

I wonder about things native speakers don't

So what is the Web's natural direction?

• HTML for Content
• CSS for Presentation
• JavaScript for Functionality

When you build with these principles in mind, you are 'cutting along the grain'.

You are playing to the Web's strengths.

Websites built on top of this foundation are delightful because they acknowledge the dual nature of the Web platform

• declarative (HTML, CSS) - trusting the browser to do its job
• imperative (JS) - carefully filling the gaps

Some developers build against the Web's natural direction

• they aim for full browser control
• often interfering with the browser
• Pixel perfect UIs
• Long time from request to render...
• (sometimes even no render at all 😒)

They also choose to ignore many aspects

• the existence of the network layer
• the existence of built-in browser features
• users which are not themselves ('works fine in my computer')
• that the web environment is unpredictable and unknown

Thus they often badly reimplement existing features, creating jank and accessibility issues.

All in pursuit of building a 'web' app!

Neither users neither developers of these apps will be happy

• they are hard to develop
• they are hard to use and break unexpectedly

1) Architect your content

Ask yourself: what do users need?

• Do they need a big heavy single page app?
• Or do they just need a sample menu, opening times and a booking form?
• Do they need to load a full templating engine etc to render a blog...?
• Or could you simply render it in your server once?
• etc...

2) Turn the content into HTML

Use all the tools the standards give you to represent content

• Advanced browsers will be nicer to the users
• Basic browsers are still functional

Examples: tel:// protocol, pattern in forms, input[type=number]...

3) Add CSS

Go bottom up

• Build for the most basic browser first
• Use sane defaults for those basic browsers
• Be mindful of proprietary prefixes—use preprocessors if needed
• Use features such as @supports

Always be learning

• New CSS features build on top of existing syntax and semantics
• Understanding the CSS algorithms will pay off: box, flow, sizing, flex, grid...

3.1) Feel proud to be a CSS developer

Don't let anyone tell you that you're not "a real developer" because you only write CSS

• Writing good CSS is an extremely valuable skill
• Good CSS can avoid many lines of unmaintainable JS code...
• ... and also be orders of magnitude faster and more performant!

4) Add JavaScript—wisely
(with great powers...)

• Learn feature detection. Don't serve code that won't be used, or worse, that will break the website. Consider using the polyfill service.
• Prefer feature libraries over frameworks—composition over inheritance.
• Prefer frameworks with built-in accessibility.
• Remember that no framework is a silver bullet.

Watch out for...

• Ads, tracking and other stuff that interferes with browsers
• Content that will not display in absence of JS

If you must replace something a browser does with your own code, you'd better know what you're doing

5) Look server side too!

Because...

• Server side rendering still beats front side JavaScript rendering
• Users of basic browsers need server side rendering anyway
• Server side validation is still required

Check your server configuration

• Caching (sp. static files)
• HTTP2 for faster transmissions
• HTTPS—required for HTTP2 and privacy sensitive APIs

To diagnose, use the browser developer tools and online tools like Web Page Test