I’ve been thinking back to my time as a core member of the original team that built the “blue bird” web app. I learned a great many lessons there and thinking through them: How would I rebuild a similar web app today, like a Mastodon frontend or an Activity Pub web client?

https://paularmstrong.dev/blog/2022/11/28/lessons-learned-how-i-would-rebuild-twitter-today/

Lessons learned: how I’d rebuild a social web app like Twitter today • Paul Armstrong

I’ve been thinking back to my time as a core member of the original team that built the Twitter web app. I learned a great many lessons there and thinking through them: How would I rebuild something similar to the Twitter web app today, like a Mastodon or Activity Pub web client?

@paularmstrong Do you have opinions about less mainstream frameworks like Svelte?
@choong Really not a fan of the element directives and pseudo-language syntaxes, eg `on:click={}` &and `bind:group={}` and `{#if …}`. JavaScript is great and we should embrace it over templating directives for better control and performance engineering.

@choong We’ve been there before with templating languages and it made sense at the time, but not as much anymore.

I’d rather be trusted to know how to write performant logic than have it abstracted away from me.

@paularmstrong I highly recommend Parcel as an alternative to both Vite and Turbopack. Parcel is a much more viable replacement for Webpack today. Turbopack in particular is very half-baked for even simple use cases
@jamiebuilds I’ve used it but there wasn’t a very strong server-side story when I did. Has it evolved much in the past year?
@paularmstrong Parcel v2 reached stable just a little over a year ago, it has improved in a lot of ways since. What exactly was bad though, I just threw this together and it's working well:
@jamiebuilds it’s been a while. I’ll have to try it again!
@jamiebuilds I did use it for my wedding RSVP website that I built on top of firebase. Worked great for that, but I didn’t go too much further than two static pages with client side rendering only. https://paularmstrong.dev/blog/2022/06/04/custom-wedding-website-part-1/
Creating a modern wedding website in 2022 Part 1: Choosing the tools • Paul Armstrong

This part of the modern wedding website series will cover tools chosen to satisfy requirements of creating a modern wedding website in 2022.

@paularmstrong I've used it for some larger apps and it's been excellent. When things don't work the way I want them to there tends to be a very straightforward answer. It works a bit different than other tools in that it leaves other tools' config files as their source of truth and not having layers of config indirection is nice

@jamiebuilds Maybe the problem I had is that the documentation seems to hide the fact that I can point it at anything other than an HTML file.

It’s almost like just an asterisk/extra note that “oh yeah I guess you could also do this”: https://parceljs.org/features/targets/#package.json%23targets.*.source

Targets

Parcel can compile your source code in multiple different ways simultaneously. These are called targets. For example, you could have a “modern” target that targets newer browsers and a “legacy” target for older browsers.

@paularmstrong Nice post. Sounds like I need to check out Solid. I’d like to hear your NextJS thoughts too :)
@kpk thanks! I’m just afraid the Next.js one would turn into an incoherent rant 🤣
@paularmstrong @kpk Putting another request into the hat for your thoughts on Next.js :) Over the years I heard some perspectives that if the site was being rebuilt today, Next would be preferred to raw React/CRA, but you likely have more nuance.

@addyosmani @kpk I don't think I have deep enough experience in Next to really give a thorough argument against it. However, off the top of my head I can think of a few problems:

* routing was feature-switch/exp dependent. Next's file-based router would be difficult to manage on top of that
* over-prescriptive patterns may be difficult to scale
* low control over some server-side things – there were a lot of perf-related middleware, tracing, and logging – may be more difficult in Next

@addyosmani @kpk On a personal note, the CEO of the company that controls Next once wanted to "chat" with me about "performance" that I had worked on for Twitter under the guise of being able to work together openly – and then spent the entire conversation trying to sell me on converting Twitter to Next.js barely 6 months after we launched. It felt slimey to me and has since left me skeptical of the entire platform.

@addyosmani @kpk I also worry about the long-term with Next.js. Sure, it’s open source and maybe it’ll live on, but at what point does Vercel decide that their paid services need to make more money and start blocking features behind needing to host on their infrastructure?

I look at Apollo GraphQL as a similar model where you can’t get metrics for individual queries unless you’re paying them.

@paularmstrong @addyosmani makes sense. I think the new SSR story could’ve been pretty amazing for twitter, but agree that some of the patterns feel restrictive right now.
@kpk @paularmstrong Thanks Paul. Requiring lower-level control for SSR and scaling up file-based routing to meet your experimentation needs are fair reasons for sure. Also ack on there being long-term questions about the funding model worth keeping in mind.
@paularmstrong good read. I'm going to read your linked article about breaking up with CSS-in-JS because I've been VERY bearish on Tailwind.
@paularmstrong just an FYI, link to deno.land is broken!

@paularmstrong Thanks for sharing ✌️

I remember considering React Native for web at SoundCloud. This was part of a major rebranding and it would've been great to share components between web and mobile. Plus, the benefit of having web and mobile devs working together.

Lucky we didn't go that route because the mobile devs did not want to integrate React Native at all, like ever 😅 (they had good reasons, though)

cc @bruderstein

@thedeftone @bruderstein It’s still an excellent framework! I know a lot of work is being done to make it more web-native, both on components and StyleSheets. It also _may_ be possible to start compiling to CSS files (soon?) with some of the newer big refactors.
@paularmstrong Kudos for considering #deno over #nodejs! It's a runtime that's moving forward at warp speed.