Web development

Svelte vs React: State Management Without the Ceremony
Continuing my Svelte deep-dive series, let’s talk about state management and reactivity. This is where the differences between React and Svelte can ‘feel’ much different.

React’s State Ceremony

In React, state requires a specific ritual. You declare state with useState, which gives you a getter and a setter:
```
const [count, setCount] = useState(0);

function increment() {
  setCount(count + 1);
}
```
Want to update a variable? You have to call a function. You can’t just reassign count. React won’t know anything changed. This is fine once you internalize it, but it adds ceremony to what should be a simple operation.

Then there’s useEffect, which is where things get tricky. You need to understand dependency arrays, and if you get them wrong, you’re looking at infinite loops or stale data:
```
useEffect(() => {
  document.title = `Count: ${count}`;
}, [count]); // forget this array and enjoy your infinite loop
```
Some of useEffect usage is actually unnecessary and likely using it wrong. If you’re using it for data transformations, derived values from state or props, or responding to user events, you’re probably reaching for the wrong tool.

The React docs themselves will tell you that you might not need an effect. It’s a common source of bugs and confusion, especially for developers who are still building their mental model of React’s render cycle.

Svelte: Reactivity Through the Language Itself

Svelte takes a fundamentally different approach. Reactivity is baked into the language semantics. Want to declare state? Just declare a variable:
```
<script>
  let count = $state(0);

  function increment() {
    count += 1;
  }
</script>

<button onclick={increment}>{count}</button>
```
That’s it. You assign a new value, and the DOM updates. The Svelte compiler sees your assignments and automatically generates the code to update exactly the parts of the DOM that depend on that variable. No virtual DOM diffing, no setter functions, no dependency arrays to manage.

Need a derived value? Svelte has you covered with $derived:
```
<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

<p>{count} doubled is {doubled}</p>
```
In React, you’d either compute this inline, use useMemo with a dependency array, or… if you didn’t know better reach for useEffect and a second piece of state (please don’t do this).

Svelte’s $effect rune exists for side effects like updating document.title or logging, but you should reach for it far less often than useEffect in React. The compiler handles most of what useEffect gets used for automatically.

More Svelte comparisons coming as I keep digging in. Thanks for Svelting with me.
Apr 8, 2026 / javascript / svelte / React / Web development

Enjoyed this?
Svelte vs React: The Virtual DOM Tax You Might Not Need

I’m diving more into Svelte and SvelteKit lately, and I’m going to be writing a few posts about it as I learn. Fair warning: some of these will be general knowledge posts, but writing things out helps me internalize the details.

The Virtual DOM Question

It’s well known that React relies on a virtual DOM. The basic idea is that React maintains a copy of the DOM in memory, diffs it against the actual DOM, and then batches the changes to update the real thing. This works, but having to maintain this virtual DOM can lead to complications and confusion around what triggers a render or a re-render. If you’ve ever stared at a useEffect dependency array wondering why your component is re-rendering, you know what I mean.

Svelte takes a completely different approach. It’s not a library you ship to the browser, it’s a compiler step. You write Svelte code, and it compiles down to highly optimized vanilla JavaScript that surgically updates the DOM directly. No virtual DOM to maintain. No diffing algorithm running in the background. The framework essentially disappears at build time, and what you’re left with is just… JavaScript.

Templating That Feels Like the Web

I like how Svelte handles the relationship between HTML, CSS, and JavaScript. React forces you to write HTML inside JavaScript using JSX. You get used to it, sure, but it’s a specific way of thinking about your UI that can take some getting used to.

Svelte flips this around. Your .svelte files are structured more like traditional web pages — you’ve got <script> tags for your JavaScript, regular HTML for markup, and <style> tags for CSS. Everything lives in one file, but there’s a clear separation between the three concerns.

If you’ve ever worked with Django templates, Laravel Blade, or Ruby on Rails views, this will feel immediately familiar. It’s a lot closer to how the web actually works than JSX’s “everything is JavaScript” approach. For someone coming from those backgrounds, the learning curve is noticeably gentler.

More Svelte posts coming as I dig deeper. That’s all for now!

Apr 8, 2026 / javascript / svelte / React / Web development

Enjoyed this?
Svelte vs React: State Management Without the Ceremony
Continuing my Svelte deep-dive series, let’s talk about state management and reactivity. This is where the differences between React and Svelte can ‘feel’ much different.

React’s State Ceremony

In React, state requires a specific ritual. You declare state with useState, which gives you a getter and a setter:
```
const [count, setCount] = useState(0);

function increment() {
  setCount(count + 1);
}
```
Want to update a variable? You have to call a function. You can’t just reassign count. React won’t know anything changed. This is fine once you internalize it, but it adds ceremony to what should be a simple operation.

Then there’s useEffect, which is where things get tricky. You need to understand dependency arrays, and if you get them wrong, you’re looking at infinite loops or stale data:
```
useEffect(() => {
  document.title = `Count: ${count}`;
}, [count]); // forget this array and enjoy your infinite loop
```
Some of useEffect usage is actually unnecessary and likely using it wrong. If you’re using it for data transformations, derived values from state or props, or responding to user events, you’re probably reaching for the wrong tool.

The React docs themselves will tell you that you might not need an effect. It’s a common source of bugs and confusion, especially for developers who are still building their mental model of React’s render cycle.

Svelte: Reactivity Through the Language Itself

Svelte takes a fundamentally different approach. Reactivity is baked into the language semantics. Want to declare state? Just declare a variable:
```
<script>
  let count = $state(0);

  function increment() {
    count += 1;
  }
</script>

<button onclick={increment}>{count}</button>
```
That’s it. You assign a new value, and the DOM updates. The Svelte compiler sees your assignments and automatically generates the code to update exactly the parts of the DOM that depend on that variable. No virtual DOM diffing, no setter functions, no dependency arrays to manage.

Need a derived value? Svelte has you covered with $derived:
```
<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

<p>{count} doubled is {doubled}</p>
```
In React, you’d either compute this inline, use useMemo with a dependency array, or… if you didn’t know better reach for useEffect and a second piece of state (please don’t do this).

Svelte’s $effect rune exists for side effects like updating document.title or logging, but you should reach for it far less often than useEffect in React. The compiler handles most of what useEffect gets used for automatically.

More Svelte comparisons coming as I keep digging in. Thanks for Svelting with me.
Apr 7, 2026 / javascript / svelte / React / Web development

Enjoyed this?
Svelte vs React: The Virtual DOM Tax You Might Not Need

I’m diving more into Svelte and SvelteKit lately, and I’m going to be writing a few posts about it as I learn. Fair warning: some of these will be general knowledge posts, but writing things out helps me internalize the details.

The Virtual DOM Question

It’s well known that React relies on a virtual DOM. The basic idea is that React maintains a copy of the DOM in memory, diffs it against the actual DOM, and then batches the changes to update the real thing. This works, but having to maintain this virtual DOM can lead to complications and confusion around what triggers a render or a re-render. If you’ve ever stared at a useEffect dependency array wondering why your component is re-rendering, you know what I mean.

Svelte takes a completely different approach. It’s not a library you ship to the browser, it’s a compiler step. You write Svelte code, and it compiles down to highly optimized vanilla JavaScript that surgically updates the DOM directly. No virtual DOM to maintain. No diffing algorithm running in the background. The framework essentially disappears at build time, and what you’re left with is just… JavaScript.

Templating That Feels Like the Web

I like how Svelte handles the relationship between HTML, CSS, and JavaScript. React forces you to write HTML inside JavaScript using JSX. You get used to it, sure, but it’s a specific way of thinking about your UI that can take some getting used to.

Svelte flips this around. Your .svelte files are structured more like traditional web pages — you’ve got <script> tags for your JavaScript, regular HTML for markup, and <style> tags for CSS. Everything lives in one file, but there’s a clear separation between the three concerns.

If you’ve ever worked with Django templates, Laravel Blade, or Ruby on Rails views, this will feel immediately familiar. It’s a lot closer to how the web actually works than JSX’s “everything is JavaScript” approach. For someone coming from those backgrounds, the learning curve is noticeably gentler.

More Svelte posts coming as I dig deeper. That’s all for now!

Apr 7, 2026 / javascript / svelte / React / Web development

Enjoyed this?
jQuery 4.0 was released on the 17th and they removed IE10 support. IE10 was first deprecated by Microsoft in January 2016 and fully retired in 2020. You might wonder, “What are they doing still supporting Internet Explorer?” They did say they were going to fully remove support in version 5.

😆: blog.jquery.com/2026/01/1…

Jan 28, 2026 / Web-development / javascript
Twenty Years of DevOps: What's Changed and What Hasn't
I’ve been thinking about how much our industry has transformed over the past two decades. It’s wild to realize that 20 years ago, DevOps as we know it didn’t even exist. We were deploying to production using FTP. Yes, FTP. You use the best tool that is available to you and that’s what we had.

So what’s actually changed, and what’s stayed stubbornly the same?

The Constants

JavaScript is still king. Although to be fair, the JavaScript of 2005 and the JavaScript of today are almost unrecognizable. We’ve gone from jQuery spaghetti to sophisticated module systems, TypeScript, and frameworks that would have seemed like science fiction back then.

And yet, we’re still centering that div.

Certainly, HTML5 and semantic tags have genuinely helped, and I’m certainly grateful we’re not building everything out of tables and spans anymore.

What’s Different

The list of things we didn’t have 20 years ago is endless but here are some of the big ones:
- WebSockets
- HTTP/2
- SSL certificates as a default (most sites were running plain HTTP)
- Git and GitOps
- Containers and Kubernetes
- CI/CD pipelines as we know them
- Jenkins didn’t exist
- Docker wasn’t even a concept
The framework landscape is unrecognizable. You might call it a proliferation … We went from a handful of options to, well, a new JavaScript framework every week, so the joke goes.

Git adoption has been one of the best things to happen to our industry. (RIP SVN) Although I hear rumors that some industries are still clinging to some truly Bazaar version control systems. Mecurial anyone?

The Bigger Picture

Here’s the thing that really gets me: our entire discipline didn’t exist. DevOps, SRE, platform engineering… these weren’t job titles. They weren’t even concepts people were discussing.

We had developers in their hole and operations in their walled gardens. Now we have infrastructure as code, GitOps workflows, observability platforms, and the expectation that you can deploy to production multiple times a day without breaking a sweat.

The cultural shift from “ops handles production” to “you build it, you run it” fundamentally changed how we think about software.

What Stays the Same

Despite all the tooling changes, some things remain constant. We’re still trying to ship reliable software faster. We’re still balancing speed with stability.

Twenty years from now, I wonder what we’ll be reminiscing about. Remember when we used to actually write software ourselves and complain about testing?

What seems cutting-edge is the new legacy before you know it.
Jan 9, 2026 / DevOps / Web-development / Career / Retrospective

Enjoyed this?

Web development

Svelte vs React: State Management Without the Ceremony

React’s State Ceremony

Svelte: Reactivity Through the Language Itself

Svelte vs React: The Virtual DOM Tax You Might Not Need

The Virtual DOM Question

Templating That Feels Like the Web

Svelte vs React: State Management Without the Ceremony

React’s State Ceremony

Svelte: Reactivity Through the Language Itself

Svelte vs React: The Virtual DOM Tax You Might Not Need

The Virtual DOM Question

Templating That Feels Like the Web

Twenty Years of DevOps: What's Changed and What Hasn't

The Constants

What’s Different

The Bigger Picture

What Stays the Same