Building a modern front end in Django without reaching for a full-blown JavaScript framework. Choosing the right tools for the job, and bringing them into your project.
This is as close to a tutorial as you’ll see on Changelog News. I’m linking to it not for the step-by-step bits like talking to your “Django backend without a full-page reload”, but for the decision making bits like “when you might choose low-JavaScript.”
JS Party listeners and panelists celebrate our favorite moments from the past 100 episodes! You’ll hear from over 20 of your favorite voices across 14 episodes. We also share some behind-the-scenes and read/hear from listeners! Here’s to the last 200 episodes, and the next 200 as well. 🥂
Your
<head>is the single biggest render-blocking part of your page—ensuring it is well-formed is critical.ct.cssis a diagnostic CSS snippet that exposes potential performance issues in your page’s<head>tags.
htmlq uses CSS selectors to extract bits of content from HTML files. Mozilla’s MDN has a good reference for CSS selector syntax.
This looks super handy. Examples!
// Find part of a page by ID
curl --silent https://www.rust-lang.org/ | htmlq '#get-help'
// Find all links in a page
curl --silent https://www.rust-lang.org/ | htmlq --attribute href a
// Get the text content of a post
curl --silent https://nixos.org/nixos/about.html | htmlq --text .main
Henrik Fricke:
Indiepen lets you embed HTML, CSS, and JS code examples on a website. We built it because we wanted to embed code examples on our blog, but many existing solutions set cookies, have a ton of features or just come with a bad performance.
😎 No cookies, no tracking, no external requests
⚡️ Small footprint with less than 20 KB
❤️ Features built for everyone
Congrats, Henrik, on shipping your first open source project! 👏
Chris Coyier is not too pleased about browsers changing the way cross-origin iframes handle certain native JavaScript calls such as alert and confirm:
Cross-origin iframes are essentially the heart of how CodePen works. You write code, and we execute it for you in an iframe that doesn’t share the same domain as CodePen itself, as the very first line of security defense. We didn’t hear any heads up or anything, but I’m sure the plans were on display.
The change is about security and performance, it seems. There’s a workaround using postMessage, but that comes with its own problems that Chris details. Overall, it seems the way this change is being rolled out is more of a concern than the change itself…
Believe it or not, I generally am a fan of Google and think they do a good job of pushing the web forward. I also think it’s appropriate to waggle fingers when I see problems and request they do better. “Better” here means way more developer and user outreach to spell out the situation, way more conversation about the potential implications and transition ideas, and way more openness to bending the course ahead.
I believe Chris Coyier put that period at the end of this post title for a reason:
Putting images on websites is incredibly simple, yes? Actually, yes, it is. You use
<img>and link it to a valid source in thesrcattribute and you’re done. Except that there are (counts fingers) 927 things you could (and some you really should) do that often go overlooked. Let’s see…
He goes on to list 15 bullet points of things to consider. This images situation is actually a microcosm of the web (and all software?) itself: it appears easy/simple at first, but the deeper you go, the more dizzying the depth.
Austin Gil explains some of the benefits of using SVG for your site’s favicon:
Disclaimer: browser support is not amazing.
When we had Adam Wathan on JS Party, I asked him if anybody besides the Tailwind team were working on component libraries. He said yes, but didn’t name any off the top of his head. Well, add DaisyUI to the list.
Your HTML doesn’t need to be messy. DaisyUI adds component classes to Tailwind CSS. Classes like
btn,card, etc… No need to deal with hundreds of utility classes.
No script dependencies. 2KB gzipped. Worth a look.
Brian LeRoux has been building the web long enough to see many ways we produce HTML come in and go out of fashion. On this episode, he joins Amal & Nick to discuss the past, present, and potential future of rendering patterns on the web. SSR, ISR, & DSR (oh my!)
This week Emma and Adam are joined by Una Kravets to discuss difficult parts of CSS.
Ashley Kolodziej speaking directly to HTML:
You are the foundation of the Internet. You are the bridge between humans and information. When we say HTML isn’t an expertise in and of itself, when we take you for granted, we leave behind the people and systems who access that information using web crawlers and accessibility technology.
and CSS:
There is a time and place for specificity, and I cherish your ability to manage that. I love your system of overrides, of thinking ahead to what should and shouldn’t be modifiable by another developer easily. I find the appreciation of specificity and
!importantand contrast and all the beautiful little things you do well increasingly lost in the pursuit of the newest and shiniest frameworks.
A lovely love letter to two of my favorite technologies. 💚
Jerod & Feross learn all about htmx (a pragmatic approach to web frontends) and _hyperscript (an experimental scripting language inspired by HyperTalk) with special guest Carson from Big Sky Software. Thanks to Rajasegar Chandran for requesting this episode!
The wonderful folks behind CSS-Tricks (maybe you’ve heard of it?) face off in our much beloved don’t-call-it-jeopardy game show. Can you out smart our intrepid contestants?
Play along while you listen (or watch). It’s JS Danger time, y’all!
Matt E. Patterson writing for A List Apart:
The dual approach of marrying a Single Page App with an API service has left many dev teams mired in endless JSON wrangling and state discrepancy bugs across two layers. This costs dev time, slows release cycles, and saps the bandwidth for innovation.
What’s old is new again (with a twist):
a new WebSockets-driven approach is catching web developers’ attention. One that reaffirms the promises of classic server-rendered frameworks: fast prototyping, server-side state management, solid rendering performance, rapid feature development, and straightforward SEO. One that enables multi-user collaboration and reactive, responsive designs without building two separate apps. The end result is a single-repo application that feels to users just as responsive as a client-side all-JavaScript affair, but with straightforward templating and far fewer loading spinners, and no state misalignments, since state only lives in one place.
I won’t spoil the ending where Matt places his bet on the best toolkit to accomplish this, but let’s just say you’ve probably heard of it. Whoops!
The entire application exists in a single HTML file with “an ancient jQuery package and a webfont pack.” All data is stored in localStorage so it can be used completely offline. Intrigued but wondering with the author would build such a thing? Check the background section of the README.
Our debate format returns! Divya & Feross take the “Nope” side while Amal & Nick represent the “Yep”s. Whose side will you take?
There’s a lot you can accomplish with just modern HTML and CSS. The problem is, when you don’t know about it, you can’t put it in action. This is an excellent post on the Web Performance Calendar about some common things you may be reaching for JavaScript to accomplish and how you can get ’em done without it.
An epic 5-part series on building HTML forms right.
Forms are arguably the most important parts of any web application. Without forms, we would not have sites like Google, Facebook, Amazon, Reddit, etc. However, the more I browse the web, the more I see poor implementations of forms.
In this series, we will examine the proper steps to creating forms for the web, how to think about the code we write, and considerations to make along the way.
Austin plans on turning this series into a full-blown book this year, so expect more from him in this arena very soon.
Fun to read the comments as people collaborated on making it smaller and smaller. TLDR:
<body onload=z=c.getContext`2d`,setInterval(`c.width=W=150,Y<W&&P<Y&Y<P+E|9<p?z.fillText(S++${Y=`,9,9|z.fillRect(p`}*0,Y-=--M${Y+Y},P+E,9,W),P))):p=M=Y=S=6,p=p-6||(P=S%E,W)`,E=49) onclick=M=9><canvas id=c>
Chris Coyier:
Earlier this year I wrote a bit about autogrowing textareas and inputs. The idea was to make a
<textarea>more like a<div>so it expands in height as much as it needs to in order to contain the current value. It’s almost weird there isn’t a simple native solution for this, isn’t it?
I’ll go a step further and say that this lack of a feature isn’t merely “almost weird”, it’s down right criminal. I’d love to champion this feature to the browser vendors/standards bodies, if one of y’all is willing to help me understand and navigate that process…
Our much anticipated Family Feud rip-off inspired game show is finally here! Emma was joined by Nick and special guest Abenezer Abebe to form the Hypertext Assassins. KBall captained (despite never seeing Family Feud before) the DSL Destroyers with Mikeal and special guest Ali Spittel.
Holler if you want MOAR Feud and check the outro for a chance to win some JS Party swag.
Addy Osmani:
Native lazy-loading for images landed in Chrome 76 via the
loadingattribute and later came to Firefox. We are happy to share that native lazy-loading for iframes is now standardized and is also supported in Chrome and Chromium-based browsers.
<iframe src="https://changelog.com" loading="lazy" width="600" height="400"></iframe>
YaS!! Lazy load all the things 💚
You might be asking yourself… “is CSS a programming language now?!” Turns out it is, thanks to the Space Toggle trick (which I’m still trying to grok as I write this).
Instead of only triggering the default email or phone apps when selecting a mailto or tel link on your website, “mailgo” provides a modal with more options such as “Open in Gmail”, “Open in Outlook”, etc.
This will extra functionality will be less important on mobile now that Apple is letting us change our default clients in iOS 14 (so that the default app would already be set to Gmail, for example), but you may find it helpful for your users anyhow. 4.96 KB cheap.