Your teams should be working closer to the web platform with a lot less complex abstractions. We need to relearn what the web is capable of and go back to that.
Let’s be clear, I’m not suggesting this is strictly better and the answer to all of your problems. I’m suggesting this as an intentional business tradeoff that I think provides more value and is less costly in the long run.
Practice Progressive Enhancement.
Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.
All content should be readable without scripting.
If it’s worth building on the web, it’s worth building it robustly, and building it to last.
If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.
Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).
- Opt into web platform features incrementally
- Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
- Write code that leans into the browser, not away from it
I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.
I’m subscribing to this RSS feed.
Put the kettle on; it’s another epic data-driven screed from Alex. The footnotes on this would be a regular post on any other blog (and yes, even the footnotes have footnotes).
This is a spot-on description of the difference between back-end development and front-end development:
Code that runs on the server can be fully costed. Performance and availability of server-side systems are under the control of the provisioning organisation, and latency can be actively managed by developers and DevOps engineers.
Code that runs on the client, by contrast, is running on The Devil’s Computer. Nothing about the experienced latency, client resources, or even available APIs are under the developer’s control.
Client-side web development is perhaps best conceived of as influence-oriented programming. Once code has left the datacenter, all a web developer can do is send thoughts and prayers.
As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site’s lifetime.
React is a non-transferable skill.
React proponents might claim that React will teach you modern UI, but from what I’ve seen it barely copes with modern UI.
autofocus is broken, custom elements don’t work in all but the experimental version, using any “modern” features likedialogor popovers requiresuseEffect, and the synthetic event system teaches you so little about how DOM actually works. This isn’t modern UI, it’s UI from 2013 at its inception. I don’t have the time left in my career to pick up UI paradigms that haven’t evolved much beyond from when Barack Obama was in office.When I mentor early career developers and they ask me what they should learn, I can’t say React, they don’t have time. I mean sure, pick up enough React to land you the inevitable job doing it, but it’s not going to level up your career.
Technically, websites can do just about anything that native apps can do. And yet the actual experience of using the web on mobile is worse than ever.
Balancing the ledger.
Responses to my thoughts on why developers would trust third-party code more than a native browser feature.
I’m trying to understand why developers would trust third-party code more than a native browser feature.
Defining the inputs instead of trying to control the outputs.