To get a better understanding of what Svelte brings us, it helps to step back and look at how we got here:

Back in the 90s, in the original version of the web, there was only HTML. Browsers displayed static documents without any interactivity. The only way to get updated information, was by reloading the page, or navigating to a new page.

, making it possible to execute code on the end-user's machine. 

As developers began experimenting with this newfangled JavaScript thing, they found one aspect really tough: dealing with the differences between browsers. Both Netscape Navigator and Internet Explorer did things in their own way, making developers' responsible for handling those inconsistencies.

var isNetscape, isIE

// figure out which browser this is
if (parseInt(navigator.appVersion) >= 4) {
  isNetscape = (navigator.appName == "Netscape");
  isIE = (navigator.appName.indexOf("Microsoft") != -1);
}

// branch based on browser type
if (isIE) {
  // The Internet Explorer Way™
} else if (isNetscape)
  // The Netscape Way™
}

This kind of browser detection code littered codebases everywhere. The extra branching was a nuisance, like a cognitive tax, making code harder to read and maintain. Translation: not fun.

In 2006, John Resig released a compatibility layer called 

. It was a way to interact with the DOM without being an expert on browser feature matrices. It completely solved the inconsistency issue. No more 

Instead, we could interact with the page using CSS selectors, and jQuery dealt with the browser on our behalf.

// read state
$('form input#email').val()

// write state
$('h1').text('Hello World!')

// get notified when something changes
$('button').on('click', function() {
  alert(2006)
})

, a framework that helps with state management.

Expressions (called bindings) could be embedded directly inside the HTML:

and Angular would sync those bindings for us.

Later, if we change our HTML, say by switching an 

, nothing breaks with the Angular version. There's no CSS selectors to update.

<div ng-app="myApp" ng-controller="myCtrl">
  
  <h1>{{year}}</h1>
</div>

<script>
// declare a module
var app = angular.module('myApp', []);

// declare a controller
app.controller('myCtrl', function($scope) {
  // update a variable and trigger syncing
  $scope.year = 2010;
});
</script>

The magic was that anytime you changed something on the 

 variable, Angular would go thru a "digestion cycle", that recursively updated all the bindings.

It solved some issues that AngularJS 1.x had. It's isomorphic, it can render HTML both on the server and in the browser, fixing the SEO problem. It also implemented a more efficient syncing algorithm called 

Refresher: Virtual DOM keeps a copy of the DOM in memory. It uses the copy to figure out what changes (the delta), while limiting potentially slow interactions with the browser DOM. (Though it's been pointed out that 

It's still conceptually similar to AngularJS, from a state management perspective. React's 

 hook, is roughly equivalent to Angular's 

// React state with hooks
const [year, setYear] = useState(null)

// setting state
// functionally equivalent to AngularJS's
// `$scope.year = 2017`
setYear(2017)

React relies on developers to signal when things change. That  means writing lots of Hook code. But Hooks aren't trivial to write, they come with a bunch of 

 released Svelte3. The idea behind Svelte is: 

What if a compiler could determine when state changes?


That could save developers a lot of time.

. Being a compiler, Svelte can find all the places where our code changes state, and update the UI for us.

Say we assign a variable inside a Svelte component:

<script>
// assign a value
let year = 2019
</script>


<h1>Hello {year}!</h1>

 statement and starts tracking the variable. If we change it later, say 

 as a state change and updates all the places in the UI that depend on that binding. 

Svelte is writing all the Hooks code for us! 

If you think about it, a big part of a developer's job is organizing state, moving state back and forth between the UI and the model. It takes effort, and it's tricky to get right. By offloading some of that work to compile-time tools, we can 

. That makes our programs smaller, clearer to read, 

, cheaper to build, and most importantly: 

 This post is part of a new course called "Svelte for React Devs"

<h1 data-node-type="titlePlaceholder" class="titlePlaceholder">How is Svelte different than React?</h1><p>To get a better understanding of what Svelte brings us, it helps to step back and look at how we got here:</p><p>Back in the 90s, in the original version of the web, there was only HTML. Browsers displayed static documents without any interactivity. The only way to get updated information, was by reloading the page, or navigating to a new page.</p><h2 class="heading-anchor-text" id="netscape-and-internet-explorer"><span>Netscape and Internet Explorer</span><a class="d-inline" href="#netscape-and-internet-explorer">#</a></h2><p>In 1995, <a href="https://en.wikipedia.org/wiki/JavaScript#History" rel="noopener noreferrer nofollow">Netscape released JavaScript</a>, making it possible to execute code on the end-user's machine. </p><p>Now we could do things like: </p><ul><li><p>Read a value from the DOM<code>document.getElementById(...).innerText</code></p></li><li><p>Write a value to the DOM: <code>document.getElemetById(...).innerText = ...</code></p></li><li><p>Get notified when something happens: <code>&lt;button onclick="alert(1995)"&gt;</code>.</p></li></ul><p>As developers began experimenting with this newfangled JavaScript thing, they found one aspect really tough: dealing with the differences between browsers. Both Netscape Navigator and Internet Explorer did things in their own way, making developers' responsible for handling those inconsistencies.</p><p>The result was code like:</p><textarea data-iscodemirror="true" data-mode="text/javascript" data-uniqueid="cm-2HYiNHpdXEeI_ty7mbniy" id="cm-2HYiNHpdXEeI_ty7mbniy">var isNetscape, isIE

// figure out which browser this is
if (parseInt(navigator.appVersion) &gt;= 4) {
  isNetscape = (navigator.appName == "Netscape");
  isIE = (navigator.appName.indexOf("Microsoft") != -1);
}

// branch based on browser type
if (isIE) {
  // The Internet Explorer Way™
} else if (isNetscape)
  // The Netscape Way™
}</textarea><p>This kind of browser detection code littered codebases everywhere. The extra branching was a nuisance, like a cognitive tax, making code harder to read and maintain. Translation: not fun.</p><h2 class="heading-anchor-text" id="jquery"><span>jQuery</span><a class="d-inline" href="#jquery">#</a></h2><p>In 2006, John Resig released a compatibility layer called <a href="https://en.wikipedia.org/wiki/JQuery#History" rel="noopener noreferrer nofollow">jQuery</a>. It was a way to interact with the DOM without being an expert on browser feature matrices. It completely solved the inconsistency issue. No more <code>if (isNetscape)</code> or <code>if (isIE)</code> conditions!</p><p>Instead, we could interact with the page using CSS selectors, and jQuery dealt with the browser on our behalf.</p><p>It looked like this:</p><textarea data-iscodemirror="true" data-mode="text/javascript" data-uniqueid="cm-0z6jvYcT_CXhFcDiJUy37" id="cm-0z6jvYcT_CXhFcDiJUy37">// read state
$('form input#email').val()

// write state
$('h1').text('Hello World!')

// get notified when something changes
$('button').on('click', function() {
  alert(2006)
})</textarea><p>But there were some challenges here too:</p><ol><li><p><strong>Selectors</strong>: If the structure of the markup changed - which happens a lot - it can break the CSS selector. For example, if you had a selector <code>$('h1')..</code>, then you change the markup from <code>&lt;h1&gt;</code> to an <code>&lt;h2&gt;</code>, your selector just silently stops working, and you won't know until a user complains. </p></li><li><p><strong>Syncing state</strong>: State changes happen in 2 directions, DOM-to-model and model-to-DOM. jQuery didn't provide any tooling here, leaving developers responsible for managing the synchronization logic on their own.  </p></li></ol><h2 class="heading-anchor-text" id="angularjs"><span>AngularJS</span><a class="d-inline" href="#angularjs">#</a></h2><p>In 2010, Google launched <a href="https://en.wikipedia.org/wiki/AngularJS" rel="noopener noreferrer nofollow">AngularJS 1.x</a>, a framework that helps with state management.</p><p>Instead of writing jQuery code, like:</p><textarea data-iscodemirror="true" data-mode="text/html" data-uniqueid="cm-DnHwW-8Z6PPaVKW-MgryO" id="cm-DnHwW-8Z6PPaVKW-MgryO">&lt;script&gt;
  $('h1').text(someExpression)
&lt;/script&gt;
&lt;h1&gt;</textarea><p>Expressions (called bindings) could be embedded directly inside the HTML:</p><textarea data-iscodemirror="true" data-mode="text/html" data-uniqueid="cm-38od4HTC7FDpqeO7gq16l" id="cm-38od4HTC7FDpqeO7gq16l">&lt;h1&gt;{{someExpression}}&lt;h1&gt;</textarea><p>and Angular would sync those bindings for us.</p><p>Later, if we change our HTML, say by switching an <code>&lt;h1&gt;</code> to an <code>&lt;h2&gt;</code>, nothing breaks with the Angular version. There's no CSS selectors to update.</p><p>AngularJS components looked like this:</p><textarea data-iscodemirror="true" data-mode="text/html" data-uniqueid="cm-F2taxQc7yfTDisCtPOZMN" id="cm-F2taxQc7yfTDisCtPOZMN">&lt;!-- specify where our controller/component mounts to --&gt;
&lt;div ng-app="myApp" ng-controller="myCtrl"&gt;
  &lt;!-- binding to a variable --&gt;
  &lt;h1&gt;{{year}}&lt;/h1&gt;
&lt;/div&gt;

&lt;script&gt;
// declare a module
var app = angular.module('myApp', []);

// declare a controller
app.controller('myCtrl', function($scope) {
  // update a variable and trigger syncing
  $scope.year = 2010;
});
&lt;/script&gt;</textarea><p>The magic was that anytime you changed something on the <code>$scope</code> variable, Angular would go thru a "digestion cycle", that recursively updated all the bindings.</p><p>But there were some problems here too:</p><ul><li><p><strong>It only worked in the browser</strong>: If a search engine crawled the page, it would see <code>&lt;h1&gt;{{someExpression}}&lt;/h1&gt;</code>. Unless you're trying to rank high for <code>{{someExpression}}</code>, that's not great.</p></li><li><p><strong>The digestion loop was inefficient</strong>: It takes time to walk the DOM tree and apply changes. Sometimes it could take multiple passes for all the values to settle.</p></li></ul><h2 class="heading-anchor-text" id="react"><span>React</span><a class="d-inline" href="#react">#</a></h2><p>In 2013, Facebook <a href="https://en.wikipedia.org/wiki/React_(JavaScript_library)#History" rel="noopener noreferrer nofollow">launched React</a>, a library for syncing state with UI.</p><p>It solved some issues that AngularJS 1.x had. It's isomorphic, it can render HTML both on the server and in the browser, fixing the SEO problem. It also implemented a more efficient syncing algorithm called <a href="https://reactjs.org/docs/faq-internals.html" rel="noopener noreferrer nofollow">Virtual DOM</a>.</p><p>Refresher: Virtual DOM keeps a copy of the DOM in memory. It uses the copy to figure out what changes (the delta), while limiting potentially slow interactions with the browser DOM. (Though it's been pointed out that <a href="https://svelte.dev/blog/virtual-dom-is-pure-overhead" rel="noopener noreferrer nofollow">this may be overhead</a>.)</p><p>It's still conceptually similar to AngularJS, from a state management perspective. React's <code>setState({value})</code> or in more recently, the <code>useState()</code> hook, is roughly equivalent to Angular's <code>$scope.value = value</code>.</p><p>Hook example:</p><textarea data-iscodemirror="true" data-mode="text/javascript" data-uniqueid="cm-0dxLqvpNC_EumEi6BqvFb" id="cm-0dxLqvpNC_EumEi6BqvFb">// React state with hooks
const [year, setYear] = useState(null)

// setting state
// functionally equivalent to AngularJS's
// `$scope.year = 2017`
setYear(2017)</textarea><h3 class="heading-anchor-text" id="the-problem"><span>The problem</span><a class="d-inline" href="#the-problem">#</a></h3><p>React relies on developers to signal when things change. That  means writing lots of Hook code. But Hooks aren't trivial to write, they come with a bunch of <a href="https://reactjs.org/docs/hooks-rules.html" rel="noopener noreferrer nofollow">rules</a>, and those rules introduce a <a href="https://github.com/joshnuss/react-hooks-in-svelte" rel="noopener noreferrer nofollow">extra cognitive load into our codebases</a>.</p><h2 class="heading-anchor-text" id="svelte"><span>Svelte</span><a class="d-inline" href="#svelte">#</a></h2><p>In 2019, <a href="https://github.com/Rich-Harris" rel="noopener noreferrer nofollow">Rich Harris</a> released Svelte3. The idea behind Svelte is: </p><p><strong>What if a compiler could determine when state changes?</strong>
That could save developers a lot of time.</p><p>It turns out to be a <strong>really good idea</strong>. Being a compiler, Svelte can find all the places where our code changes state, and update the UI for us.</p><h3 class="heading-anchor-text" id="example"><span>Example</span><a class="d-inline" href="#example">#</a></h3><p>Say we assign a variable inside a Svelte component:</p><textarea data-iscodemirror="true" data-mode="text/html" data-uniqueid="cm-2n8NsfrEmHdrXRICo_d2V" id="cm-2n8NsfrEmHdrXRICo_d2V">&lt;!-- a .svelte component --&gt;
&lt;script&gt;
// assign a value
let year = 2019
&lt;/script&gt;

&lt;!-- this &lt;h1&gt; depends on `year` state --&gt;
&lt;h1&gt;Hello {year}!&lt;/h1&gt;</textarea><p>Svelte detects the <code>let</code> statement and starts tracking the variable. If we change it later, say <code>year = 2021</code>, Svelte sees the assignment <code>=</code> as a state change and updates all the places in the UI that depend on that binding. </p><p>Svelte is writing all the Hooks code for us! </p><h1 class="heading-anchor-text" id="conclusion"><span>Conclusion</span><a class="d-inline" href="#conclusion">#</a></h1><p>If you think about it, a big part of a developer's job is organizing state, moving state back and forth between the UI and the model. It takes effort, and it's tricky to get right. By offloading some of that work to compile-time tools, we can <strong>save a lot of time and energy</strong>.</p><p>Another side effect is, we end up with <strong>less code</strong>. That makes our programs smaller, clearer to read, <strong>easier to maintain</strong>, cheaper to build, and most importantly: <strong>more fun</strong> to work with.</p><p><strong>P.S.</strong> This post is part of a new course called "Svelte for React Devs"</p><p>So stay tuned! </p><h1 data-node-type="titlePlaceholder" class="titlePlaceholder"></h1><p></p>

AUTHOR

Joshua Nussbaum

 This post is part of an upcoming course called "Svelte for React Devs"

<h1 data-node-type="titlePlaceholder" class="titlePlaceholder">How is Svelte different than React?</h1><p>To get a better understanding of what Svelte brings us, it helps to step back and look at how we got here:</p><p>Back in the 90s, in the original version of the web, there was only HTML. Browsers displayed static documents without any interactivity. The only way to get updated information, was by reloading the page, or navigating to a new page.</p><h2 class="heading-anchor-text" id="netscape-and-internet-explorer"><span>Netscape and Internet Explorer</span><a class="d-inline" href="#netscape-and-internet-explorer">#</a></h2><p>In 1995, <a href="https://en.wikipedia.org/wiki/JavaScript#History" rel="noopener noreferrer nofollow">Netscape released JavaScript</a>, making it possible to execute code on the end-user's machine. </p><p>Now we could do things like: </p><ul><li><p>Read a value from the DOM<code>document.getElementById(...).innerText</code></p></li><li><p>Write a value to the DOM: <code>document.getElemetById(...).innerText = ...</code></p></li><li><p>Get notified when something happens: <code>&lt;button onclick="alert(1995)"&gt;</code>.</p></li></ul><p>As developers began experimenting with this newfangled JavaScript thing, they found one aspect really tough: dealing with the differences between browsers. Both Netscape Navigator and Internet Explorer did things in their own way, making developers' responsible for handling those inconsistencies.</p><p>The result was code like:</p><textarea data-iscodemirror="true" data-mode="text/javascript" data-uniqueid="cm-2HYiNHpdXEeI_ty7mbniy" id="cm-2HYiNHpdXEeI_ty7mbniy">var isNetscape, isIE

// figure out which browser this is
if (parseInt(navigator.appVersion) &gt;= 4) {
  isNetscape = (navigator.appName == "Netscape");
  isIE = (navigator.appName.indexOf("Microsoft") != -1);
}

// branch based on browser type
if (isIE) {
  // The Internet Explorer Way™
} else if (isNetscape)
  // The Netscape Way™
}</textarea><p>This kind of browser detection code littered codebases everywhere. The extra branching was a nuisance, like a cognitive tax, making code harder to read and maintain. Translation: not fun.</p><h2 class="heading-anchor-text" id="jquery"><span>jQuery</span><a class="d-inline" href="#jquery">#</a></h2><p>In 2006, John Resig released a compatibility layer called <a href="https://en.wikipedia.org/wiki/JQuery#History" rel="noopener noreferrer nofollow">jQuery</a>. It was a way to interact with the DOM without being an expert on browser feature matrices. It completely solved the inconsistency issue. No more <code>if (isNetscape)</code> or <code>if (isIE)</code> conditions!</p><p>Instead, we could interact with the page using CSS selectors, and jQuery dealt with the browser on our behalf.</p><p>It looked like this:</p><textarea data-iscodemirror="true" data-mode="text/javascript" data-uniqueid="cm-0z6jvYcT_CXhFcDiJUy37" id="cm-0z6jvYcT_CXhFcDiJUy37">// read state
$('form input#email').val()

// write state
$('h1').text('Hello World!')

// get notified when something changes
$('button').on('click', function() {
  alert(2006)
})</textarea><p>But there were some challenges here too:</p><ol><li><p><strong>Selectors</strong>: If the structure of the markup changed - which happens a lot - it can break the CSS selector. For example, if you had a selector <code>$('h1')..</code>, then you change the markup from <code>&lt;h1&gt;</code> to an <code>&lt;h2&gt;</code>, your selector just silently stops working, and you won't know until a user complains. </p></li><li><p><strong>Syncing state</strong>: State changes happen in 2 directions, DOM-to-model and model-to-DOM. jQuery didn't provide any tooling here, leaving developers responsible for managing the synchronization logic on their own.  </p></li></ol><h2 class="heading-anchor-text" id="angularjs"><span>AngularJS</span><a class="d-inline" href="#angularjs">#</a></h2><p>In 2010, Google launched <a href="https://en.wikipedia.org/wiki/AngularJS" rel="noopener noreferrer nofollow">AngularJS 1.x</a>, a framework that helps with state management.</p><p>Instead of writing jQuery code, like:</p><textarea data-iscodemirror="true" data-mode="text/html" data-uniqueid="cm-DnHwW-8Z6PPaVKW-MgryO" id="cm-DnHwW-8Z6PPaVKW-MgryO">&lt;script&gt;
  $('h1').text(someExpression)
&lt;/script&gt;
&lt;h1&gt;</textarea><p>Expressions (called bindings) could be embedded directly inside the HTML:</p><textarea data-iscodemirror="true" data-mode="text/html" data-uniqueid="cm-38od4HTC7FDpqeO7gq16l" id="cm-38od4HTC7FDpqeO7gq16l">&lt;h1&gt;{{someExpression}}&lt;h1&gt;</textarea><p>and Angular would sync those bindings for us.</p><p>Later, if we change our HTML, say by switching an <code>&lt;h1&gt;</code> to an <code>&lt;h2&gt;</code>, nothing breaks with the Angular version. There's no CSS selectors to update.</p><p>AngularJS components looked like this:</p><textarea data-iscodemirror="true" data-mode="text/html" data-uniqueid="cm-F2taxQc7yfTDisCtPOZMN" id="cm-F2taxQc7yfTDisCtPOZMN">&lt;!-- specify where our controller/component mounts to --&gt;
&lt;div ng-app="myApp" ng-controller="myCtrl"&gt;
  &lt;!-- binding to a variable --&gt;
  &lt;h1&gt;{{year}}&lt;/h1&gt;
&lt;/div&gt;

&lt;script&gt;
// declare a module
var app = angular.module('myApp', []);

// declare a controller
app.controller('myCtrl', function($scope) {
  // update a variable and trigger syncing
  $scope.year = 2010;
});
&lt;/script&gt;</textarea><p>The magic was that anytime you changed something on the <code>$scope</code> variable, Angular would go thru a "digestion cycle", that recursively updated all the bindings.</p><p>But there were some problems here too:</p><ul><li><p><strong>It only worked in the browser</strong>: If a search engine crawled the page, it would see <code>&lt;h1&gt;{{someExpression}}&lt;/h1&gt;</code>. Unless you're trying to rank high for <code>{{someExpression}}</code>, that's not great.</p></li><li><p><strong>The digestion loop was inefficient</strong>: It takes time to walk the DOM tree and apply changes. Sometimes it could take multiple passes for all the values to settle.</p></li></ul><h2 class="heading-anchor-text" id="react"><span>React</span><a class="d-inline" href="#react">#</a></h2><p>In 2013, Facebook <a href="https://en.wikipedia.org/wiki/React_(JavaScript_library)#History" rel="noopener noreferrer nofollow">launched React</a>, a library for syncing state with UI.</p><p>It solved some issues that AngularJS 1.x had. It's isomorphic, it can render HTML both on the server and in the browser, fixing the SEO problem. It also implemented a more efficient syncing algorithm called <a href="https://reactjs.org/docs/faq-internals.html" rel="noopener noreferrer nofollow">Virtual DOM</a>.</p><p>Refresher: Virtual DOM keeps a copy of the DOM in memory. It uses the copy to figure out what changes (the delta), while limiting potentially slow interactions with the browser DOM. (Though it's been pointed out that <a href="https://svelte.dev/blog/virtual-dom-is-pure-overhead" rel="noopener noreferrer nofollow">this may be overhead</a>.)</p><p>It's still conceptually similar to AngularJS, from a state management perspective. React's <code>setState({value})</code> or in more recently, the <code>useState()</code> hook, is roughly equivalent to Angular's <code>$scope.value = value</code>.</p><p>Hook example:</p><textarea data-iscodemirror="true" data-mode="text/javascript" data-uniqueid="cm-0dxLqvpNC_EumEi6BqvFb" id="cm-0dxLqvpNC_EumEi6BqvFb">// React state with hooks
const [year, setYear] = useState(null)

// setting state
// functionally equivalent to AngularJS's
// `$scope.year = 2017`
setYear(2017)</textarea><h3 class="heading-anchor-text" id="the-problem"><span>The problem</span><a class="d-inline" href="#the-problem">#</a></h3><p>React relies on developers to signal when things change. That  means writing lots of Hook code. But Hooks aren't trivial to write, they come with a bunch of <a href="https://reactjs.org/docs/hooks-rules.html" rel="noopener noreferrer nofollow">rules</a>, and those rules introduce a <a href="https://github.com/joshnuss/react-hooks-in-svelte" rel="noopener noreferrer nofollow">extra cognitive load into our codebases</a>.</p><h2 class="heading-anchor-text" id="svelte"><span>Svelte</span><a class="d-inline" href="#svelte">#</a></h2><p>In 2019, <a href="https://github.com/Rich-Harris" rel="noopener noreferrer nofollow">Rich Harris</a> released Svelte3. The idea behind Svelte is: </p><p><strong>What if a compiler could determine when state changes?</strong>
That could save developers a lot of time.</p><p>It turns out to be a <strong>really good idea</strong>. Being a compiler, Svelte can find all the places where our code changes state, and update the UI for us.</p><h3 class="heading-anchor-text" id="example"><span>Example</span><a class="d-inline" href="#example">#</a></h3><p>Say we assign a variable inside a Svelte component:</p><textarea data-iscodemirror="true" data-mode="text/html" data-uniqueid="cm-2n8NsfrEmHdrXRICo_d2V" id="cm-2n8NsfrEmHdrXRICo_d2V">&lt;!-- a .svelte component --&gt;
&lt;script&gt;
// assign a value
let year = 2019
&lt;/script&gt;

&lt;!-- this &lt;h1&gt; depends on `year` state --&gt;
&lt;h1&gt;Hello {year}!&lt;/h1&gt;</textarea><p>Svelte detects the <code>let</code> statement and starts tracking the variable. If we change it later, say <code>year = 2021</code>, Svelte sees the assignment <code>=</code> as a state change and updates all the places in the UI that depend on that binding. </p><p>Svelte is writing all the Hooks code for us! </p><h1 class="heading-anchor-text" id="conclusion"><span>Conclusion</span><a class="d-inline" href="#conclusion">#</a></h1><p>If you think about it, a big part of a developer's job is organizing state, moving state back and forth between the UI and the model. It takes effort, and it's tricky to get right. By offloading some of that work to compile-time tools, we can <strong>save a lot of time and energy</strong>.</p><p>Another side effect is, we end up with <strong>less code</strong>. That makes our programs smaller, clearer to read, <strong>easier to maintain</strong>, cheaper to build, and most importantly: <strong>more fun</strong> to work with.</p><p><strong>P.S.</strong> This post is part of an upcoming course called "Svelte for React Devs"</p><p>So stay tuned! </p><p></p>

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

How is Svelte different than React?

Tags

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript