Forem: Daniel Nagy

Are Inline Styles Faster than CSS?

Daniel Nagy — Sat, 06 Apr 2024 13:49:20 +0000

https://danielnagy.me/posts/Post_tsr8q6sx37pl

TL;DR

I recently migrated my website from CSS-in-JS to inline styles and was pleasantly surprised by the performance improvement. Encouraged by this, I wrote a blog post suggesting that inline styles could enhance website load times.

However, some skeptics rightly pointed out that my migration from a specific CSS-in-JS library to inline styles wasn't sufficient evidence to claim inline styles were faster than CSS. Determined to uncover the truth, I embarked on a comprehensive experiment.

The experiment involved migrating my entire website to CSS, a painstaking process. I meticulously crafted over 2,000 lines of handwritten CSS, utilizing BEM for component styling and atomic CSS for non-component elements. Then, I built three versions of my React app: one with inline styles, one with a separate CSS file, and one with CSS inlined in the document head.

Deploying all versions to a single testing environment, I meticulously measured various metrics including server render time, HTML and JavaScript sizes, browser render time, and web vitals.

Server render times showed no significant correlation between inline styles and CSS. HTML size comparison revealed inline styles producing larger documents, yet after compression, they were smaller than inline CSS due to compression efficiency. JavaScript bundle size increased slightly with inline styles but became negligible after compression, resulting in the fewest bytes over the wire.

Browser render performance favored inline styles, particularly in putting pixels on the screen quickly, especially evident on low-powered devices. Web vitals, including first contentful paint and largest contentful paint, often favored inline styles over CSS.

In conclusion, my experiment suggests that inline styles could offer better performance than CSS, especially considering factors like browser rendering and initial page load. However, I acknowledge that this may not be universally true and encourage others to conduct their own experiments to gather more data.

Switching to Inline Styles Could Save You 15% or More on Page Speed

Daniel Nagy — Mon, 18 Mar 2024 15:10:06 +0000

https://danielnagy.me/posts/Post_capv6evei09g

So easy, a backend developer could do it.

TL;DR

I switched from CSS-in-JS to inline styles and improved the load performance of my website by 18%. I also decreased the complexity of my website, and I decreased the size of my JavaScript bundle by 6.36%. All while maintaining the same developer experience for styling.

The Two-Tree Problem with Styling on the Web

Daniel Nagy — Mon, 11 Mar 2024 22:14:54 +0000

https://danielnagy.me/posts/Post_jt4adn0o5bnr

TL;DR

In this article, I discuss what I call the "two-tree problem" with styling modern web apps. The problem arises from the separation of structure and style.

I suggest that while CSS is a well-designed language for styling, the cascade and separation of styles from HTML may have been mistakes.

I then examine some popular styling libraries, including Emotion, Styled Components, Tailwind, and UI Box, assessing their effectiveness in addressing the two-tree problem.

I make a case for inline styles as a potential solution, emphasizing their simplicity. I acknowledge the limits of inline styles but suggest that these limits might not be significant issues for modern web development.

The American Dream

Daniel Nagy — Thu, 29 Feb 2024 20:40:54 +0000

In this article, I tell the story of my journey into computer science and my struggle with mental health.

While intentionally dramatic at times, I promise this is not a sob story, and I'm not looking for sympathy. I just want to share my story.

Summary

I begin my story by informing the reader that I had a rough start in life and that I had to enter the work force at a young age. I then progress to my high school years when I started messing with computers.

After high school I went to college to study computer science. My junior year I got an internship doing web development. During my internship, I created an open-source project that became popular. I got a job at a startup in Los Angeles and moved to California.

I made some job transitions, and then the pandemic hit. I started working remotely from my apartment in Hollywood. I was miserable living in Hollywood, so I moved to Austin, TX. My job started to become toxic for me but I did not realize it at the time.

I bought a house, and the day after I moved in, my mom passed away. I became very depressed and left my job. For awhile I could not look at code. Now I'm coding again, and I started a blog. I end by telling the reader some things I wish I would have done differently.

If my story sounds interesting to you then you can read it here. I hope your journey was better than mine!

Introducing Transporter

Daniel Nagy — Fri, 12 Jan 2024 16:55:19 +0000

I am the author of Transporter. Transporter was made public on Jan 2, 2024. The purpose of this post it to bring attention to Transporter and receive feedback. I hope this is an appropriate place to self-promote my work.

Transporter is a library for typesafe distributed computing in TypeScript. Transporter was influenced by Comlink and rxjs.

Transporter makes it possible to call functions in other processes as if they were in-process. This is known as remote procedure call or RPC for short. Unlike other TypeScript RPC libraries, that focus primarily on RPC over HTTP between a web server and client, Transporter is a little more low level and general purpose.

I began work on Transporter back in 2021 as part of a larger prototype that involved reusing UI fragments in React Native and in the browser. I wanted there to be a well defined API barrier between the sub-frames and the host.

Some key differences between Transporter and other TypeScript RPC libraries are

Transporter is designed to be general purpose. Not only can you use Transporter over HTTP but you can use transporter over just about any transport layer, including postMessage in the browser.
Transporter does not use a router. Instead you organize your API into namespaces using object composition.
Transporter does not use a builder API or otherwise couple your functions to Transporter. You can organize your API however you want using the syntax of TypeScript. This allows Transporter to support generic functions.
Transporter supports recursive RPC depending on your subprotocol. Recursive RPC allows state to be held on the call stack between processes. This also enables the use of Observables for pub-sub.

If I have peeked your interest in Transporter than please read my blog post and checkout Transporter's GitHub page where you can find examples and API docs! If you would like to discuss Transporter then feel free to start a discussion on GitHub. Thanks!