developit

This sounds fun

my unhelpful take is that I like both

<3

Nit: 212kb, the rest is a YouTube embed that I seem to recall is loaded lazily.

We are working on a new renderer that started out life as a way of addressing the specific corner cases that can lead to this. It will be released in early 2021.

It already does this. Only for .cjs files and things in node_modules.

The tooling space isn't broad enough to allow for differentiation across the board, so we have a number of tools that are working to validate/popularize a subset of functionality on top of the basics.

WMR's unique take is basically to be instant in every possible way, and to provide an ideal substrate for us to build and show Preact features that rely on bundler semantics. We have maintained a Webpack-based build tool for Preact for a while, and wanted to explore what a total re-think would look like. We also spent a while building out new pieces of the bundler that fit this model better than repurposing existing generalized tooling. This is one of the reasons WMR builds as fast as it does despite doing so much optimization work - it's designed around a singular goal and we allowed for very limited compromise.

I think that after a few years we will see a corresponding consolidation of the tools you mentioned, as the dust settles on this newer dev/prod split paradigm and it's effect on the bundler plugin ecosystem.

Oh I totally agree it's strange, haha. The cost tends to be magnified in Node land since everything is a million files.

You need to change the HTML to point to the tsx file too:

<script type="module" src="./index.tsx"></script>

There are ambient TS definitions for CSS Modules, it just had a bug in 1.0.0 - fix is merged and will be released shortly.

We've only shipped a helper library for Preact, but the Prerendering is actually generic. Some folks are working on helpers for other frameworks. The "API" is just a function exported from your first script tag:

export async function prerender(data) { return { html: "<h1>hi</h1>", links: ["/other-page"] } }

Hot reloading is a similar story, it's the same API as Vite and Snowpack:

if (import.meta.hot) import.meta.hot.accept(({ module }) => { do stuff }));

It's built-in, just change the file extension to `.tsx` or create a new file with that extension.

It's designed for rapid prototyping. You can just use npm or yarn and ignore this feature though, it's entirely optional.

FWIW the surface area for security issues here is far smaller than npx or similar tools, because WMR only writes JS/CSS/TS files to disk, and doesn't execute package scripts (where most vulnerabilities reside).

Hmm - it's not actually specific to Preact, it's just built by the Preact team and we use Preact in the docs. We are missing a bunch of documentation that would have made this clearer though, which I apologize for. While there are some optimizations for Preact in WMR, it can be used for vanilla JavaScript / Lit / Vue / Svelte / etc just fine.

tbh I think a good chunk of that size is babel-parser, which we're looking into removing from the preact ESLint preset. Still quite a difference though.

There are a few cases where syntax compilation is split up cleanly, but when you dig into the internals of preset-env, transforms are rarely that isolated. That being said, "watch this space"...

Most specs have a small number of authors (1-3) and a much wider group of people who have influenced the spec. This is as true for Import Maps and kv-storage as any other. FWIW I think "the web's first built-in module" is a reference to the name of the spec, which is called "built-in modules", not a claim to originality.

Not a great example, since "independent" is the important bit there: browsers just shipped sqlite, and you can't have a spec that says "just ship sqlite".

It's more than memory use - it causes tree traversals to take longer, which means unbounded style recalculations (common) and side-effecting DOM changes take longer.

Preact and Hoodie/PouchDB. Frontend hosted on Netlify, backend on literally anywhere ($5 Dokku one-click installation on a DigitalOcean VM, Heroku, whatever). Hoodie/PouchDB gets you a pretty easy fix for the "whole DB on page load" issue and pretty good realtime sync across clients.

It's possible now! https://developers.google.com/web/fundamentals/app-install-b...

It has a dark mode with different colors. Let's not villify blue in general though :P

For slow writers but quick typists, an app is always going to win out over a physical journal. Also interested in an event call export + parse.

It's true, the example could be better. However - adding any form of data pruning to the example would immediately show the benefit. JSON parsing happens in the worker, and only a small subset of data is actually serialized and sent back to the main thread.

Agreed! There's an open issue to address this - the single letter names are silly, since they get uglified anyway.

It's unlikely Preact infringes on a theoretical React patent. It's not a reverse-engineered reimplementation of React, but rather a library that happens to have a similar public API. APIs are not patentable, thus Preact's implementation is no more likely to infringe than Angular or Vue's.

Understandable, and agreed about my point being for copyright as opposed to patents. It's interesting to note that, since the majority of DOM rendering libraries now employ some variant of Virtual DOM (react, preact, mithril, glimmer/ember, angular, even polymer!), a patent claim covering the concept of Virtual DOM itself would likely be invalid - the presence of so many prior and contemporary implementations of that paradigm make would invalidate it on the grounds that it cannot be "Non-obvious" or "non-novel". My knowledge of this stuff is largely gleaned from Wikipedia and thus not to be trusted, but it seems like there would be little grounds for a patent suit over VDOM. Also interesting to note: there are few (if any?) other companies directly associated with any of the other VDOM implementations - can a patent claim even be made against an Open Source project?

Also impossible because JSX is independent of React. The specification is only subject to a standard Copyright and is released under the Creative Commons Attribution 4.0 International license.

I'd be curious to hear about this too - I don't see any issues filed or commented on by him, perhaps the bugs are more perceptual mismatches with his React experience as opposed to actual bugs. We only recently released preact/debug, which brings with it some of the guardrails React ships by default - maybe without those people run into issues.

FWIW there are hundreds of companies (some very very large) using Preact in production. If there were showstopper bugs, they'd be fixed immediately.

We've begun work on a NativeScript integration that would meet this need. It's early stage though.

This is not true, since Preact only implements the same software interface. Its internals are fundamentally different and not a derivative work.

Software interfaces cannot be patented - this has been upheld in every court, most recently in Google V Oracle.