This series of posts will make up a tutorial for Preact that does not assume knowledge in React, or any other application framework. I found this specific area lacking when it comes to tutorials, as myself someone who has never used React.

The tutorial assumes that you know the basics of JavaScript, and know how to install npm packages. We'll use the Parcel bundler to bundle and serve our code during development, though you do not need to know Parcel as I'll explain everything as we go. We'll use Babel to allow us to actually use JSX in the browser. You don't need to know it either, though I won't spend a lot of time on it. Finally, I'll use TypeScript for the code snippets as I believe static typing offers educational value both reading the code snippets, and also while writing code. You may absolutely want to stick to JavaScript, in which case just strip the types off of the code and be on your way. As with Babel, I will not spend a lot of time on TypeScript either; if you want to dive deeper on any of these, feel free to go learn more about any (or all) of these projects before going back here to follow the tutorial.

Contents

1. Introduction
2. DOM Garderning
3. JSX, or as it should be called: XML-in-JS
4. First steps with Preact
5. Components, props, state, and context
6. Testing components
7. Get hooked, Capt'n!
8. To CSS and not to CSS
9. Route it, link it, match it - technologic
10. Manual Server-side Rendering
11. Workshop: A music catalog application

A dive into modern JavaScript application development

JavaScript was not really designed as the main foundation atop which the modern web would be built. In fact, the web itself was never designed as an application framework - This is all evident in the way we interact with it: we request and visualize documents, which are described by a particular subset of XML: HTML. They provide the semantic view of the document, that is what the text means and how it is structured. HTML defines hierarchy much like a book can have parts, chapters, headings and paragraphs - because the web was designed to be a digital equivalent to a library, where websites were books you could peek in.

This is where the "modern" view of the web clashes with its implementation. The modern web of web applications view a website as an application, from which its web pages are the multiple entry points. HTML, then, define the elements which compose the particular application, and how it is structured.

Alleviating the pain from the document-centric workflow

There is a way to, if not resolve, at least help bridge the gap between the early design and modern use of the web. By taking a step back from the HTML itself, and focusing instead on composing "elements" which render themselves into HTML. We can then stop thinking about "how will I write HTML in order to build my application?", and start thinking about "How can I break down my application into manageable chunks?", and this is the first step towards building applications that scale while staying maintainable.

However, this is not a perfect solution, as the technicalities of the document-centric workflow tend to creep up into these elements quite quickly (one being the "cascade" I mentioned earlier, which you'll understand if you have any experience with CSS, however styling is outside the scope of this series).

The solution: JS frameworks by the dozen

This very thinking led to the popularization of JS frameworks promising to implement this abstraction of HTML into reusable elements in a way that would benefit the developer. React, Angular, Vue, Elm, Svelte, dozens of frameworks each try to innovate on the above recipe in their own way.

Conclusion

This sets the stage and hopefully the mindset towards understanding the thought process behind the design of the technologies we are going to use throughout the series.

In the next part, we are going to look at the first layer of abstraction over HTML that has become standard for JavaScript application development. I hope you're hyper-excited!