Tomáš Horáček heracek

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

https://twitter.com/snookca/status/1073299331262889984?s=21

‪“‬In what way is JS any more maintainable than CSS? How does writing CSS in JS make it any more maintainable?”

‪Happy to chat about this. There’s an obvious disclaimer that there’s a cost to css-in-js solutions, but that cost is paid specifically for the benefits it brings; as such it’s useful for some usecases, and not meant as a replacement for all workflows. ‬

‪(These conversations always get heated on twitter, so please believe that I’m here to converse, not to convince. In return, I promise to listen to you too and change my opinions; I’ve had mad respect for you for years and would consider your feedback a gift. Also, some of the stuff I’m writing might seem obvious to you; I’m not trying to tell you if all people of some of the details, but it might be useful to someone else who bumps into this who doesn’t have context)‬

So the big deal about css-in-js (cij) is selectors.

2019 update: this essay has been updated on my personal site, together with a followup on how to get started

2020 update: I'm now writing a book with updated versions of all these essays and 35 other chapters!!!!

1. Learn in public

If there's a golden rule, it's this one, so I put it first. All the other rules are more or less elaborations of this rule #1.

You already know that you will never be done learning. But most people "learn in private", and lurk. They consume content without creating any themselves. Again, that's fine, but we're here to talk about being in the top quintile. What you do here is to have a habit of creating learning exhaust. Write blogs and tutorials and cheatsheets. Speak at meetups and conferences. Ask and answer things on Stackoverflow or Reddit. (Avoid the walled gardens like Slack and Discourse, they're not public). Make Youtube videos

In the project directory:

Install global dependencies https://streamable.com/era9s
- yarn global add [email protected] psc-package pulp
Generate an example project in the current directory https://streamable.com/gcjih
- pulp --psc-package init
Install web application bundler https://streamable.com/f9l56
- yarn add parcel
Call purescript from JavaScript https://streamable.com/u5s49
- yarn dev and pulp --watch build

A vision for data interchange in Elm

How do you send information between clients and servers? What format should that information be in? What happens when the server changes the format, but the client has not been updated yet? What happens when the server changes the format, but the database cannot be updated?

These are difficult questions. It is not just about picking a format, but rather picking a format that can evolve as your application evolves.

Literature Review

By now there are many approaches to communicating between client and server. These approaches tend to be known within specific companies and language communities, but the techniques do not cross borders. I will outline JSON, ProtoBuf, and GraphQL here so we can learn from them all.

This is the response to lightning talk CFP at ReactiveConf.

Sharing code between web and mobile using React + ReactNative + Redux

When you stand in front of the project that aims to come with mobile and web application, going for combo React.js & ReactNative is easy choice. But to decide how to handle the data flow is a different story.

My team made this decision and after couple of talks and earlier experience with graphQL + Relay, we went for Redux. Redux enabled us to share most of the bussines logic even though the apps differ in usecases. I would like to share the challenges we had to overcome with you.

Demo: Coordinating async React with non-React views

tl;dr I built a demo illustrating what it might look like to add async rendering to Facebook's commenting interface, while ensuring it appears on the screen simultaneous to the server-rendered story.

A key benefit of async rendering is that large updates don't block the main thread; instead, the work is spread out and performed during idle periods using cooperative scheduling.

But once you make something async, you introduce the possibility that things may appear on the screen at separate times. Especially when you're dealing with multiple UI frameworks, as is often the case at Facebook.

How do we solve this with React?

	//
	// Combine+WithLatestFrom.swift
	//
	// Created by Shai Mishali on 29/08/2019.
	// Copyright © 2019 Shai Mishali. All rights reserved.
	//

	import Combine

	// MARK: - Operator methods

	# Remove previous installations
	sudo apt-get remove vim vim-runtime vim-tiny vim-common

	# Install dependencies
	sudo apt-get install libncurses5-dev python-dev liblua5.3-dev lua5.3 python3-dev

	# Fix liblua paths
	# You have to compile luajit for yourself.
	sudo ln -s /usr/include/lua5.3 /usr/include/lua
	sudo ln -s /usr/lib/x86_64-linux-gnu/liblua5.3.so /usr/local/lib/liblua.so

	let cache = new Map();
	let pending = new Map();

	function fetchTextSync(url) {
	if (cache.has(url)) {
	return cache.get(url);
	}
	if (pending.has(url)) {
	throw pending.get(url);
	}