Back to Boring

@stefanjudis Back to boring

@stefanjudis news.stefanjudis.com Heyo, I'm Stefan! checklyhq.com

This is all way too complicated and too much code
for a standard website... My CTO

This is how we do it!

I love building websites! (But secretly, I'm super overwhelmed*) *
don't tell anyone

Sometimes I even dream about this...

Did we(b development) lose the right direction?

my-links.online/wrong-direction

httparchive.org

Page weight

Transferred JS Bytes

Time to interactive

HTML CSS JavaScript React Vue Angular Svelte Remix webpack Rollup
Parcel AWS GCloud Netlify Vercel Deno * * a very incomplete list

Hello world! 2012 10KB / 50KB Hello world! 2022 100KB
/ 300KB* Complexity * powered by 200MB+ of text ﬁles #node_modules

I’ve been building on the web for 15+ years in
some capacity, and it has never been so easy to build complex apps. Josh Comeau 100% agree! How many sites need to be complex apps, though?

Whoops!

Should really everything be an app, today?

Video platforms Blogs Shops Image & Illustration software Marketing sites
Games Productivity Apps PWAs Streaming sites Social Networks

Website Web App Grey zone

MPA vs. SPA Multi Page App Single Page App

I need a new site what should I use? You
should use Framework X with SSR, an oﬄine strategy! It depends... What's your use case?

Every technology choice has tradeo!s

<!doctype html> <html lang="en"> <head>...</head> <body> <h1>Hello world!</h1>    <script src="js/some-jquery-sugar.js"></script> </body> </html>

Server dynamically delivering HTML CSS, JavaScript, Images coming from a
CDN

First render (All of it!) index.html main.css jQuery.js A Fetch-Render
Waterfall some-spaghetti.js DB Calls API Calls API Calls API Calls Server Browser index.html DB Calls API Calls API Calls API Calls All done!

Browsers are freaking good at rendering websites!

-->   <script src="js/some-jquery-sugar.js"></script> </body> </html>

<!doctype html> <html lang="en"> <head>...</head> <body> <span>Loading...</span> <script src=“js/app-bundle-hash1.js”></script> <script
src=“js/app-bundle-hash2.js”></script> <script src=“js/app-bundle-hash3.js”></script> </body> </html>

<$Main> <SideBar> <Trends /" <OtherNonSense /" <$SideBar> <$App> App Sidebar Nav Main TweetBox Tweets SideBar Trends OtherNonSense Data for OtherNonSense Data for Trends Data for Tweets A Render-Fetch Waterfall (aka "fetch as you render")

<$Main> <SideBar> <Trends /" <OtherNonSense /" <$SideBar> <$App> App Sidebar Nav Main TweetBox Tweets SideBar Trends OtherNonSense Data for OtherNonSense Data for Trends Data for Tweets A Render-Fetch Waterfall (aka "fetch as you render") Network? CPU? Memory?

You can make your server fast, but you can't control
the user's network. Remix docs

developer.mozilla.org/en-US/docs/Web/API/History_API

We shifted all the work to the client, but at
least...

... we're in full control and can build beautiful experiences!

With client-side routing you might break Focus handling Scroll handling
Assistive technology

Next.js route announcer /% next.config.js module.exports = { reactStrictMode: true,
experimental: { scrollRestoration: true, }, };

Just because you can, doesn't mean you should.

With client-side routing you can Persist state Partially render routes
Keep UI elements alive

This is not fast enough!

<!doctype html> <html lang=""> <head>...</head> <body> <span>Loading...</span> <script src=“js/app-bundle-hash1.js”></script> <script
src=“js/app-bundle-hash2.js”></script> <script src=“js/app-bundle-hash3.js”></script> </body> </html>

-->   <script src=“js/app-bundle-hash1.js”></script> <script src=“js/app-bundle-hash2.js”></script> <script src=“js/app-bundle-hash3.js”></script> <script>window.__data__ = { greeting: "Hello world!" }</script> </body> </html>

Your content in HTML The same content in JavaScript

And then you have to hydrate everything, too!

Server delivering HTML CSS, JavaScript, Images coming from a CDN

HTML, CSS, JavaScript, Images coming from a CDN

SSR Server Side Rendering CSR Client Side Rendering SSG Static
Site Rendering DPR Incremental Static Regeneration Distributed Persistent Rendering ISR

Do we deliver the same user experience with more code
and complexity?

reactjs.org with JavaScript reactjs.org without JavaScript 433KB / 1.1MB 49KB
/ 175KB Initial weight 547KB / 2.3MB 100KB / 1.0MB Weight after 4 navigations

If your site feels like a "boring" Multi Page App,
maybe it should be one?

I'd love to write less code with easy-to-use technology.

Let's not reinvent (or install) accessible UI controls.

open-ui.org

Alert Avatar Badge Breadcrumb Button Card Checkbox Datepicker Dialog File
Flex Focusgroup Icon Image Menu Popup Radio Button Select Skeleton Slider Switch Table Tabs Text Toast Tooltip

<selectmenu id="ambassadors" class="ambassador"> <div slot="button"> <button behavior="button">Pick one<$button> <span behavior="selected-value"><$span>
<$div> <div popup slot="listbox" behavior="listbox"> <div class="grid"> <option value="benedek" checked>Benedek<$option> <option value="carmen">Carmen<$option> <option value="jeremias">Jeremias<$option> <$div> <$div> <$selectmenu> selectmenu and popup open-ui.org/prototypes/selectmenu Not ready yet...

microsoftedge.github.io/Demos/selectmenu/

const dialog = document.querySelector('dialog'); dialog.showModal(); // to close the dialog
use `close` dialog.close(); A new Dialog API

web.dev/building-a-dialog-component/

If the web platform provides more high-level components we have
to ship less code.

I want to bet on web standards and build things
that just work! (Yes, I'm talking about progressive enhancement)

class FlavorForm extends React.Component { constructor(props) { super(props); this.state =
{value: 'coconut'}; this.handleSubmit = this.handleSubmit.bind(this); } handleSubmit(event) { alert('Your favorite flavor is: ' + this.state.value); event.preventDefault(); } render() { return ( <form onSubmit={this.handleSubmit}> <label> Pick your favorite flavor: <select name="flavor" value={this.state.value} <option value="grapefruit">Grapefruit<$option> <option value="coconut">Coconut<$option> <$select> <$label> <input type="submit" value="Submit" /" <$form> ); } } Isn't it weird that we're preventing the browser default behavior for years now?

<form onSubmit={this.handleSubmit}> GET /?flavor=grapefruit

Buzzfeed twitter.com/philhawksworth/status/990890920672456707

kryogenix.org/code/browser/everyonehasjs.html

I want to create delightful experiences!

async function navigate(data) { if (!document.createDocumentTransition) { await updateTheDOMSomehow(data); return;
} const transition = document.createDocumentTransition(); await transition.start(async () =* { await updateTheDOMSomehow(); }); }

Shared Element Transitions SPA MPA

github.com/WICG/shared-element-transitions

I want to ship only necessary code.

11ty.dev

astro.build

I want to push code and see things live in
seconds.

HTML, CSS, JavaScript, Images coming from a CDN

HTML, CSS, JavaScript, Images coming from a CDN Edge compute

JavaScript pushes the boundaries of the web!

If browsers provide more components, navigation transitions are easy to
build and servers are around the world...

Let the server do its job Ship less JavaScript Build
more beautiful experiences

Use whatever works for you, but consider the trade o!s.

Keep pushing and have fun! (Because this is how we
do it)

@stefanjudis www.stefanjudis.com news.stefanjudis.com Thanks.

Back to Boring

Back to Boring

More Decks by stefan judis

Other Decks in Technology

Featured

Transcript