MatthewPhillips

This is why engineers shouldn't pick tools. They prioritize their resume over the quality of the product.

The reason why you don't know is that you've decided in advance that it's not actually needed.

.astro is not actually like MDX at all. MDX extends Markdown, Astro does not, it extends HTML. MDX is a variant of JSX, Astro is not, it supports things that JSX does not like void elements. Astro supports text inside of script and style tags, JSX does not.

If you think you can rebuild Astro with "a few extra preprocessor rules", then by all means go for it. But you're going to fail.

Here's a good SEO component: https://www.npmjs.com/package/simple-astro-seo

It uses it to know what JS is needed for the client. If it sees <Section /> that means that no-JS is needed. But if it sees <Counter client:load /> it knows to build + bundle the Counter component and attach its JS to the page.

No. Svelte are big proponents of the SPA pattern so I'm doubtful they would ever build something like this.

Most of those tools are focused on giving you a full SPA on the client (and therefore load a lot of JS). Astro is focused on sites that are mostly static with "islands" of interactivity. To that end every component is server rendered only, by default, and you opt-in to client render when you need it (with different loading strategies).

Stencil support is being worked on too: https://github.com/snowpackjs/astro/pull/266

I can't speak for every frameworks' SSG tool but most of them load a full SPA on the client and have poor performance. Go pick out a random website for Gatsby's showcase page and see how much JS is loaded (spoiler: a lot).

Astro focuses on partial hydration where you only load the JS for the specific components that need to run in the client. Very few tools and none of the framework SSG's that I'm aware of do this.

There's also a variety of other features that Astro brings, the blog post talks about them.

Currently you build a static site like you do with Gatsby or Jekyll or any other static site generator. In the future it will support dynamic server rendering.

Not yet, Lit has support for SSR in prerelease and we've experimented with supporting it. Once it's ready it will be included. In the meantime you can of course use web components (with any framework) like you normally would, just without SSR.

Tracking issue for Lit support: https://github.com/snowpackjs/astro/issues/109

TB has a vaccine. Covid is novel, hence getting all the attention.

Your book does an excellent job explaining the single-table design pattern of DynamoDB. This pattern literally saves you money. So at a certain point you will earn back the $79 from a lower AWS bill (plus your applications will be much faster!)

I love the blog post. Great to see some people out there that are still questioning the status quo and not simply giving in to appeals of authority. The author saw things they disliked about React and didn't let the hand-wavy reasoning silence those criticisms.

Well done

I absolutely don't have that expectation. I built a comic reader app that I use on my Android tablet, which saves files to IndexedDB. I've been using this for over a year and no files have ever been deleted, even after I stopped using the app for a month or so.

If Apple provided an alternative this would be ok. An alternative such as the native file access API (still a WIP). Or a prompt so that the user can allow long-term storage. Or supporting the web app manifest so that users confirm they want to "install" a web app, granting it greater permissions.

But they've offered no alternatives here, that I can see. They've determined that client-side web apps are simply not important.

They listed SPA capabilities as a requirement when choosing a framework.

Every framework allows only rendering to part of the screen, but all of them also allow and encourage the building of SPAs, including Vue. Building SPAs is the overwhelming norm when using any of these frameworks.

If they are bucking the trend here, that's great, I encouraged using a declarative library for the truly dynamic parts in my above post. However this post contains a lot of red flags such as the term "Server-Side Rendering" that are unnecessary if using it not for a SPA. So it's worth pointing out the risk.

This is a bad idea. If you look at the list of advantages to doing this only 1 is user-centric (things would be reactive). The rest are all related to how it makes development easier. When you choose a developer-centric workflow your users will suffer.

You only have to look at the numerous server to SPA conversions to see how consistently bad of a choice this tends to be; Reddit is a big and obvious example.

They could take a half-measure and move away from the brittle jQuery based front-end they are currently using by adapting those to use something like Preact, while leaving the rest of the page alone. This would give you more dynamic and more maintainable page widgets without the sacrifices that inevitably occur when you move the entire site to being front-end rendered.

They're right, it was unprofessional... but since the maintainer is not being paid this is not a professional project. It's a personal project. And this seems like a perfectly personal thing to do with something that's preventing happiness.

Yeah, I've been looking into wasm and am finding similar issues (not with Rust specifically). Languages designed for desktop/server usages are not a great fit in small places (embedded and the web).

With Go there's TinyGo which solves this problem (note, I haven't used it so can't speak to how well). I wonder if something similar for Rust is possible, a compiler targeting embedded systems?

Don't attempt to build a SPA if you are support browsers that old (even IE8 imo). Give them a traditional server-rendered app and they'll be happy.

Since you've already built with React, the good news is that it's easy to build a React app that you deploy as a server-rendered app. Just make sure you are doing things in normal HTML, like forms, and not relying on xhr/fetch.

That depends on the provider and the database. For AWS Lambda with DynamoDB connection pooling is handled "behind the scenes", and you don't have to worry about it. AWS supports SQL databases as well, I would assume it also is pooled for you.

NOW currently doesn't have databases and tells you to use cloud DBs. So more than likely the connection is dropped when the lambda shuts down.

But if you'll let me go a little bit meta, the idea of serverless is that you shouldn't even be thinking about things like connection pooling. If you just use the databases that your provide supports those types of concerns are their concerns now, not yours.

In other words, if you want to pick your own tech stack then serverless is not for you (yet). If you're willing to surrender your opinions and just use what the platform provides you (if you're using AWS just use DynamoDB) then you can stop thinking about these problems and focus on your business logic.

Without knowing the specifics of this project, more than likely they do not attempt to solve the problem you describe. Simply don't make changes to the real DOM, or use 2 workers on the same subset of actual DOM. Each worker owns its own DOM (most likely the entire page).

I worked on a similar project a few years ago: https://github.com/canjs/worker-render. It could render jQuery apps in a web worker, it was pretty neat.

The problems I ran into, and I suspect this project will run into many of the same things were:

1. Events are synchronous so to make them async you have to preventDefault them, send to the worker, and then send back and re-dispatch them (if the worker didn't preventDefault). This works ok for many events like 'click' but not at all for things like touch events.

2. The debugging experience in the worker is not very good. Things you take for granted like being able to do `document.querySelector('.app')` and get a pretty-printed DOM object in the debugger do not work when that object is a fake DOM-like object.

3. There are a lot of DOM APIs and they continuously grow. Trying to implement everything is impossible. Many things can't (like events described above) be implemented 1 to 1. So it's a constant game of whack-a-mole.

Of these problems #2 is the biggest though. Devtools has a lot of really nice integrations with the DOM that you just lose when you're not using the actual DOM. So users have to decide if the tradeoffs are worth it. AMP might have an advantage in this regard, since you literally have no other choice; use their worker DOM or you can't run your app at all.

Images and videos are less important though.

I'm not a React dev, but both approaches seem like they would make testing harder. Prop drilling must be the most testable approach. Am I wrong?

I don't know where you get that it can't be fast, that's certainly not true. Gambit Scheme is just one example of a fast lisp.

People like lisps because they are written as ASTs. So you can manipulate programs (ASTs) to create DSLs very easily.

That's great, but 1.3mb as a baseline is just too big for most common DOM manipulation type of use cases. You want your UI drawn within a couple of seconds or the experience becomes bad. Even if they were able to cut it in half I'm not sure I'd be comfortable using it. I'd really want to profile and see how fast you can get to interactive using something like this.

Now for heavier applications like graphics or video editing, this would be fine to use.

You know something has to perform low level DOM operations, right?

Criticizing a language that just got wasm support last week for not having mature high level solutions yet is a bit ridiculous.

Great article! I attempted something very similar and wrote about it here: https://matthewphillips.info/programming/wasm-golang-ce.html

Like the author I'm pretty enthusiastic about using Go for web development. The interop story is quite strong.

My biggest concern is the binary size. 1.3mb for what is essentially a hello world. Given that Go needs to include garbage collection I'm a tad worried they won't be able to cut down the size enough to make it worthwhile to use.

Yeah, this is a UI bug in devtools for a feature not a lot of people use. Plus web worker bugs always get pushed to the bottom of the queue for every browser. So I don't have any problem with how long my weird issues take to get fixed.

It's more about comparing to Firefox where you usually get a quick response which at least conveys that the person on the other end understands what is being reported. I'm fine with the eventual outcome here. A comment acknowledging that it's a real bug (or not) would have been better, but being assigned to someone sort of acknowledges that, I guess.