• 10 Posts
  • 98 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle













  • The windows 11 teams runs better, but if you’re using a school or work account, you need to use the old AngularJS+Electron version, or the new React+Webview2 version.

    So for the time being, the Windows 11 teams is more catered for personal use only. It’s kind of like a modern reboot of Microsoft’s old MSN Messenger. It was included in Windows 11 (rebranded as “Chat”) but it’s been unbundled from Windows 11 installs and I think rebranded again. But not having the school/work account support means not a lot of people use it.

    The transition between the AngularJS+Electron version and the React+Webview2 versions is happening now. At some point soon, anyone who is running an OS too old to run the new teams will be forced to use the browser version.

    So after their transition, we’ll have to wait and see if they add the school/work account support to the native version because everyone using teams right now only uses those accounts.


  • There’s a reason Teams is/was shit.

    The first teams was written in AngularJS (which is a slow to run resource hog, but fast to develop) wrapped in Electron. It was kind of a minimum viable product, just to build something quickly to get some feedback and stats on what people needed.

    The plan was to build a new native version of teams and build it into the next windows while having an web fallback (built on react) for everyone else.

    They stopped working on the original teams and started working on the new versions.

    They got half-way through working on the native and react versions when suddenly, covid happened.

    They couldn’t keep working on the new versions because they wouldn’t be ready for a while, so they had to go back and resume development on the old one, introducing patch after patch to quickly get more features in there (like more than 2 webcam streams per call).

    Eventually covid subsided and they were able to resume development on the new teams versions.

    Windows 11 launched with a native teams version (which has less features but runs super quick), and the new react based teams (which can now be downloaded in a webview2 wrapper) has been in open beta since late last year (if you’ve seen the “Try the new Teams” toggle, then you’ve seen this). The React+Webview2 teams will replace the AngularJS+Electron version as the default on July 7th.



  • Tailwind is only feels like a successor to CSS to developers writing css like it was 10 years ago (or using frameworks that write it like that, e.g. bootstrap), or projects not using visual regression testing.

    Modern css is so much better.

    • Want to position, overlap, or align things? Use CSS Grid.
    • Are you using a CMS or component system and want to change the order that CSS is applied? Use Cascade Layers.
    • Want to have resizeable components? Use component queries.
    • Want to make a change all through your site? Use custom properties.
    • Want to style things differently based on how many other elements are inside or around it? Use :has(), +, ~, nth-..., … selectors.

    If you’re using something like BEM, or bootstrap to make columns, your knowledge is way out of date and you’re doing it wrong.


  • There’s absolutely a massive internal bias people have where they naturally believe that others develop the same kinds of content, when really it’s half working on page based content, and half working on component based content.

    • Page developers know that putting their styles in the content itself is a disaster when you want to make a global change.
    • Component developers know that putting their styles external to their components is a dx nightmare because developers keep making changes that they think only affects one component when it actually impacts a different component (and that change might not be found until months or years later).

    Both are correct.

    The real problem is developers thinking that there are only two methods for making styles: external css files, and tailwind/atomic styles in class names.

    Component developers should have their styles inside their components, but not inlined in style attributes (like in tailwind).

    Component developers should instead place a style tag inside their component that is scoped to just that component.

    So let’s say you’re making an accordion component.

    Make your html+js/jsx like you already do, and add an “accordion” class to your component’s root element. Now add a style tag in your component with a single selector targetting the .accordion class. Now you can use nesting to style anything in the accordion exactly how you want. Want to style something based on whether an element is open or not? Use an attribute selector. Want to style something based on whether it’s child is doing something? Use the :has() selector. etc…

    If you’re making a widget system, use container queries. If you’re making a card system, use subgrid.

    There’s so many obvious use cases that modern css provides for, so use modern css! and not any of this BEM or tailwind nonsense. Now your css is so much smaller, robust and more maintainable.


    Follow up questions:

    Q: But I don’t know modern CSS

    A: Learn, it’ll be much better for you in the long run compared to using tailwind, then needing to learn something else once people switch off tailwind for something else.

    Q: But wouldn’t putting a style tag in every component mean that there’s going to be two style tags on the page if I put two of the same component on the page?

    A: It’ll only do that if you make it do that. Most component based frameworks are already set up to reduce repetition, check your framework’s docs. (e.g. react’s many css-in-js solutions, web component’s :host selector, vue’s <style> and <style scoped> elements, SSGs like Eleventy have Asset Bucketing, and even native html is getting it’s own solution this year with @scope).