The web, technology wise, is in a great place.
We’ve grown closer to parity with native apps, that’s the gist of progressive web applications, we can have pretty close to the same experience form web apps as we can from native.
CSS has moved forward y leaps and bounds. We can do a lot of things that lead directly to our current Responsive Web Design paradigm. The scope of CSS will only make sense when you look at the complete list of CSS specifications.
Chris Heilmann tackles some of these question in his JSConf.Asia 2015 presentation. I will follow up on some Chris’s presentation and address some additional items that I think are also essential.
Matt Griffin’s The Future of The Web sums up the current debate really well.
Progressive web applications has again reignited the debate between progressive enhancement and the extensible web camp.
On the Extensible Web side…
On the other hand…
- Slow/old computer
- Slow connection
- Slow computer and slow connection
- Old browser on a computer they don’t control
- Someone trying mirror your site for offline access
- Search engine crawler or the Internet Archive
- Text only browser (Lynx, Links, Emacs W3)
- Your CDN goes down
I’m guilty of not bothering to check. The worst example:
I seldom, if ever, do.
And it’s as basic as this: it doesn’t matter how cool or powerful an experience we provide to our users if they can’t access it in some fashion after all the bells and whistles are taken away.
Marcy Sutton reminds us that making content accessible is not hard and shouldn’t be but we need to be smart about it.
When working in higher education I remember several colleagues working with the disability support group on campus to test products and technologies. What would be the equivalent of doing that for a business? How expensive would it be?
What is core, what is an enhancement?
Yes, we are talking about apps and interaction heavy sites but, at some point, we must provide a core we can enhance. Scott Jenson has an interesting G+ post on the subject titled My Issues with Progressive Enhancement. He asks:
What I’m chaffing at is the belief that when a page is offering specific functionality, Let’s say a camera app or a chat app, what does it mean to progressively enhance it?
Jeremy Keith gives what to me is the the best answer I’ve heard so far:
If that were what progressive enhancement meant, I’d be with him all the way. But progressive enhancement is not about offering all functionality; progressive enhancement is about making sure that your core functionality is available to everyone. Everything after that is, well, an enhancement (the clue is in the name).
The trick to doing this well is figuring out what is core functionality, and what is an enhancement. There are no hard and fast rules.
Sometimes it’s really obvious. Web fonts? They’re an enhancement. Rounded corners? An enhancement. Gradients? An enhancement. Actually, come to think of it, all of your CSS is an enhancement. Your content, on the other hand, is not. That should be available to everyone. And in the case of task-based web thangs, that means the fundamental tasks should be available to everyone …but you can still layer more tasks on top.
Even in reading applications we need to ask ourselves these questions. They drive development and they should also drive UX/UI design.
What’s the core of our user experience? To get people content that they want to engage with in some form regardless of the level of technology that we use to access the content
The shinny new thing syndrome
How often do we hear about the newest, greatest and fastest library? Have you seen articles like:
- Top 10 web development trends and predictions for 2015
- The Languages And Frameworks You Should Learn In 2016
- 5 Technologies Disrupting Web Design in 2015
So what’s wrong with the existing tools and technologies? It seems like the community is looking at doing things their way rather than working together to implement a best of breed solution.
We have what I call the “new and shinny” syndrome. We latch on to the latest and greatest technology rather than make sure the existing technology is working fine before we measure whether the application needs to be updated at all.
Furthermore, as Paul mentiones in the video above, there is some serious cost involved in moving from one framework to another and, some times between versions of the same Framework. What is the learning curve to learn React over Angular or to Learn Angular instead of Polymer?
I never stopped to consider the cost of having to learn new frameworks as I’ve managed to keep myself on a fairly strict diet of frameworks and technologies on my development stack. But I do realize that sometimes it’s not up to the individual developer or team. Some times the tools you use in a project are dictated by what the project makes available to you.
For task runners and build systems we have so many options to make it dangerous to even suggest one. The ones I found when searching:
- GNU Make (yes, this is still an option)
- NPM (not its primary function)
- Ant (Java based)
All these systems perform the same task, getting your files ready for production, in slightly different ways.
I can only imagine what would happen with Frameworks and how many times would you have to switch projects if all you do is use the latest and greatest framework.