Utah Front End Conferences 2023 Edition - Part 2

Did you know that Utah has a vibrant JavaScript community? We even have a few local “tech celebrities” such as Tanner Linsley, Kent C Dodds, & Ryan Florence of Remix & React Router fame. With that community comes some great conferences, two of which include React Rally and the super local UtahJS Conf that I was able to attend this year! See Part 1 for insights around React Rally, this time let’s talk about UtahJS Conf!

UtahJS is a small, community-driven conference that is held annually in Utah. This year it was held September 15th and like React Rally, is the 6th UtahJS Conf I’ve been able to attend. UtahJS Conf is one of my favorite conferences because it gives me a chance to talk to past coworkers, see what local devs are up to, & enjoy talks while sitting in super comfy theater seats because it’s always held at a Megaplex theater!

You can check out the full schedule (might not be accurate anymore) or watch the actual recordings if you’d like, but I wanted to comment on specific talks I enjoyed or had interesting insights into.

I attended this talk because I respect Cory and because I sort of disagree and wanted to see his take. I can’t say that he changed my mind completely but I can appreciate some of his points:

• Promises give you built-in scope isolation.
• Promises give you less code branching.
• Promises push you towards functional programming.

I think these are all fair, but I would still reach for async/await simply because they’re easier for people new to Promises to understand the code. If I were working with a code base with only myself or seasoned JS devs, I could see using Promises only being a compelling argument.

Nick lives mostly in the SRE space so this talk leaned heavily that way but I can see how this talk can be just as applicable to front end development as back end or even in simple problem solving. His list of skills include:

1. Self-care. Take breaks, find rituals for focus, remove distractions, & try to get away from emotional response so that logic can kick in.
2. Prove yourself wrong or make a hypothesis. Also remember to document them! This can help provide focus and a way to not keep retreading things you’ve already tried.
3. Fast feedback. The faster you can try things, the faster you can discover solutions. Also lean on Occam’s Razor - simpler explanations are generally better than more complex ones.
4. Ask good questions. Use co-workers or the internet as a rubber duck. Remember to provide context with your questions! If you can, provide a minimal complete verifiable example.
5. Observability. Don’t look through logs, use a tool that helps cut through them like Honeycomb.io, Datadog, etc.
6. Improve the process. Have postmortems. Focus on how to improve processes and tools you may need.

I've experienced some incident management processes that seem better than most in my career. Still, these are skills that can help in non-incident situations and are good food for thought.

I’m going to be real here: I don’t like Jest. I’ve never liked Jest because it’s slow, bloated, and while it’s easy to set up, the cost was never worth it for me and I look forward to the next best thing to replace it. Another confession: I think end to end tests are important but I don’t like to write many of them because they tend to be brittle and slow.

Because of these biases, I wanted to attend this talk and I’m really glad I did! I won’t get too much into details (watch the talk if you’re interested) but here are my key takeaways:

• Cypress can mount components, not just sites.
• Cypress makes authoring component tests a much easier process than with Jest because you have an interactive browser showing you what’s going on. Even with data mocking since to the browser, it’s just another request.
• Cypress can run headless, but it still runs in a browser.
• Cypress has a CI test runner you can pay for but there’s an open source, self-hosted one called Sorry Cypress.
• Cypress isn’t super fast but parallelizes well.

I hit up Tyler about some questions I had and while his whole company isn’t using Cypress for component testing, it’s been gaining traction. The speed thing is concerning but the authoring story is very intriguing! Hope to find some time to try this out more.

This was an interesting guide through the various rendering methods used the last few decades and their various tradeoffs such as:

• CGI scripts - Websites are dynamic but not that interactive.
• Client-side Rendering (e.g. SPAs) - Way more interactive but huge bundles that needed to be downloaded, poor SEO, and compute-heavy on the client.
• Server-side Rendering (e.g. SSR) - Smaller bundles, better SEO, and faster time to paint but hydration is compute-heavy and time to interactive is still slow.
• Islands Architecture - Essentially componentized SSR where a component has its own SSR lifecycle and bundle. Faster page loads, faster time to interactive, but larger sites require maybe hundreds or thousands of islands.
• Resumability - Idea is to do work on the server, pause, and resume execution on the client. Similar to SSR but less hydration needed since paused state is serialized in the HTML that is sent to the client which results in less rework on the client. Somewhat similar to Islands Architecture but at an even smaller (sub-component) level. Seems cool but really only available in Qwik with not enough conversations around it.
• Streaming SSR & Selective Hydration - Instead of waiting for everything to be fetched before hydration, this starts hydration on components that are most likely to be interacted with first by the user. The rest of the hydration happens as the page is loaded in order of likelihood of user interaction. Kind of tricky to set up and assumes that the heuristics on what should hydrate first is correct. Very much bleeding edge and work is still being done here.
• React Server Components - Very similar to Islands Architecture but is The Blessed React Way™ to do it (as long as you’re using Next.js 🙃). Takes a minute to wrap your head around how things work with the syntax but this post by Josh Comeau can help.

Matheus wrapped up his talk about how all of these approaches include tradeoffs that give us more options as we create front ends. Not every company is positioned to be on the bleeding edge like this, but it's good to see what's available for when it's time to redo front ends.

Long title but a short and sweet talk. Tyler ran though how to identify and shrink your bundle size as well as make your site more performant. Some key things he went through:

• Use webpack-bundle-analyzer to see how things are being bundled as you go through this discovery process.
• Lazy import pages at the router layer and wrap in Suspense blocks.
• Dynamically import things that are expensive and aren’t need to display the page initially.
• Use https://bundlephobia.com to see if there are smaller versions of packages you’re using.

I’ve used some of these tools & techniques in the past and can attest to their usefulness. The only thing that was new to me was the bundlephobia site. Seems like a great resource for finding smaller dependencies when a new dependency is needed.

This talk had a lot of motivational speaker vibes but fortunately for Dano, I eat that stuff up. Dano talked about the importance of finishing projects (and how to do it) rather than the typical mountain of unfinished projects that many devs are used to. In a nutshell, he suggests:

• Find the biggest friction to completion and take that on first. For him it was AWS.
• Build and keep momentum in any way, even if it’s only a few minutes a day.
• When planning a project, go through a process defined in The Right It (haven’t read it yet): Thoughtland (ideation) → Pretotype (fake/mocked up version of the prototype) → Prototype.

He mentioned that while you can do this process on your own time, you can apply them to how you work:

• Ask for more responsibility at work. Hopefully in something that will encourage growth.
• Set a goal and hold yourself accountable.
• Find opportunities to take on and do a project to completion.

He applies these to various experience levels and archetypes (junior dev, staff-level, manager, etc). If this is something that interests you, I recommend checking out the video!

UtahJS Conf is a short conference, but I managed to get a lot out of it and plan on going next year as well.

What small, local conferences run in your area? You may want to check them out since my experience has been that they’re high value for your money. Even if you’re not using the technology the conference is about, the material is often useful across other disciplines (some of my favorite conferences have been based around Ruby which I’ve never done professionally). And if you’re not attending conferences yet, start planning for next year! It’s great for your career and is a great benefit provided by most companies.