redonkulus

We developed an internal library, but there are similar libraries in open source (although I can't remember their names).

Nope, not all. Yahoo homepage, News, Entertainment, Weather all use this architecture. Yahoo Mail uses a React/Reduct architecture on the client. Other Yahoo properties with more complex client-side UX requirements are using things like Svelte or React. It's not a one size fits all architecture at Yahoo, we let teams determine the right tools for the job.

Hmm, I haven't used an RSS reader in many years. Thanks for the tip though.

We've been using similar architecture at Yahoo for many years now. We tried to go all in on a React framework that worked on the server and client, but the client was extremely slow to bootstrap due to downloading/parsing lots of React components, then React needing to rehydrate all the data and re-render the client. Not to mention rendering an entire React app on the server is a huge bottleneck for performance (can't wait for Server Components / Suspense which are supposed to make this better ... aside: we had to make this architecture ourselves to split up one giant React render tree into multiple separate ones that we can then rehydrate and attach to on the client)

We've moved back to an MPA structure with decorated markup to add interactivity like scroll views, fetching data, tabs and other common UX use cases. If you view the source on yahoo.com and look for "wafer," you can see some examples of how this works. It helps to avoid bundle size bloat from having to download and compile tons of JS for functionality to work.

For a more complex, data-driven site, I still think the SPA architecture or "islands" approach is ideal instead of MPA. For our largely static site, going full MPA with a simple client-side library based on HTML decorations has worked really well for us.

Essentially it’s because new developers cycle in every decade and do not have all the context of the previous generation of developers.

Real life Yellowstone but instead of ski resorts and casino's, its data centers.

The clicking on the photo title or description to inline edit blew my mind as a young web developer starting out.

We have used a similar css utility library (Atomizer) at Yahoo for 8+ years. This has been used across many sites with a large group of developers touching the code. It has saved a ton on CSS size and duplication. We never force only atomic classes, for more complex use cases we push developers to write vanilla CSS.

Some of his points are valid about maintainability and complexity, but that can be resolved by building smaller components to share markup and classes. All depends on the use-case.

Disclaimer: Maintainer of Atomizer.

Is it easy to support other CSS frameworks? I haven’t checked the docs yet.

Also no kids or family

Easy ... money

ELI5 how do you know it’s being downvoted?

Happy cake day

I know it goes against the merits of the site, but it would be great if there was a fallback option to output CSS for browsers that do not support grids.

Talk about burying the lead. That wasn’t mentioned in the matrix blog post at all. Only that Gitter would be using matrix natively. Doesn’t matter either way but weird to not mention it.

Is this generally the progression through the years?

Backend dev -> Angular -> Vue?

I primarily do frontend and I never found the Angular/Vue frameworks to compelling to learn. I like React more but don’t have to use it with every project. I’m curious if the Angular/Vue audience is of a certain type of engineer.

Just downloaded it. Great app. Lots of useful info. Thanks!

How is tailwind different than Atomic CSS? https://acss.io

Small utility classes without writing CSS, seems like the same thing.

Disclaimer: I worked with the devs that created it.

Yup I had a whole UI to add the MIDI’s and apply a genre. Plus I would get the time and size etc from the file when I uploaded it. Much of it was manual. Also the reason why I never got to 100k :(

The tricky part with the 100k downloads is that you do not have all the meta data for each file. You just have the filename, so some are just called “index.mid”. Which I guess is nice for a random surprise when you play it.

My shameless plug is my old MIDI site called MIDI Delight. I had user registration, ratings, comments, top 10 lists, etc. I always wanted to get it working again like you did. It would be cool to see more user features added on your site.

I’m glad there is a new MIDI site carry the torch.

100kb is light weight? That’s a typo, the website says 12kb min/gzipped which is still kind of large uncompressed.

This solution for loading the scripts is great. We have been experimenting with this and browser sniffing was our approach. Will start testing this new approach. Really makes integration and fallback much easier to manage.

You could use replaceState instead to change the URL but leave the history intact. https://developer.mozilla.org/en-US/docs/Web/API/History_API...

This avoids having to click back through each slide.

This is basically everything that Dan Abramov has contributed. Good work by him!

You can see an example of Fluxible with react-router: https://github.com/yahoo/flux-examples/tree/master/react-rou...

(fluxible dev here)

Which part of Fluxible feels verbose?

That's not true. We get the ads too :)

Also, don't forget https://github.com/yahoo/flux-examples which ties all of these together.