oldweb.today
Such a vividly nostalgic project. Choose an obsolete browser. Enter a URL. Select which slice of the past you want to see.
Digital archives in action. Access drives preservation.
Such a vividly nostalgic project. Choose an obsolete browser. Enter a URL. Select which slice of the past you want to see.
Digital archives in action. Access drives preservation.
A fascinating detective story of the Enlightenment, told from a very personal perspective.
A small little JavaScript helper from Lea.
The helper library for people who don’t like helper libraries.
A wonderful sci-fi vignette from Matt.
Great tips from Heydon on building a real design system using flexbox. Perfect for those times when you can’t predict the amount of content that will be in layout …so, pretty much always.
There’s even a trick in here that kinda sorta gives us element queries.
I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:
- The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
- In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
- The next time a user clicks, rather than being sent to the server, the client-side app is in control.
- If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.
YES!!!
Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:
Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.
Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.
Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.
Visit this site using different browsers on different devices to get a feel for what you can do with web technologies.
Native will always be ahead, but the feature gap is closing impressively fast.
A rousing call to arms for progressive enhancement. I agree with the sentiment, but I’m less comfortable making assumptions about the reasons why developers don’t use progressive enhancement:
However, what’s actually happening is that “universal access to content” is being subversively replaced with “universal access for a limited subset of users that I care about”.
Honestly, I think that plenty of developers just aren’t thinking about it—especially if they’re relying on a particular tool or framework to save them time and effort (which is not a crime). So that’s why I agree with the title of this piece: let’s talk about this more; let’s make sure developers understand what they’re doing when they make JavaScript a requirement for basic functionality.
I particularly like the point in here about content blockers like NoScript:
In fact, it’s probably more likely that a user will try browsing the Web today without scripting than at any other time since the 1990s.