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.
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.
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.
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.
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.