• yyy

  • Theory

    • directives
      • ~ 1.2.3 up to, but not including, 1.3.0.
      • ^ 1.2.3 up to, but not including, 2.0.0.
  • Tools to evaluate -

  • General evaluation tool

    • tldr
      • does it solve the problem?
      • longevity
      • popularity
    • Basic questions
      • Open source
      • license
      • self hostable
    • Start writing criterias like this. Have goals.
    • Ask AI
    • google & reddit - popular options & reputation
    • check past knowledge - lCode, Notes
    • Mentors
      • Theo
      • Webcody
      • 2
        • webdevsimplified
        • fireship
    • Popularity
      • general
        • npm/docker
      • starts
      • active branches
    • Longevity
      • general
        • Language - is it so niche that no much contributors?
        • Mantainers popular and w good rep?
      • Pulse - only owner making changes?
      • Lines of code - the less, the more secure
      • issues - might signal a lot of problems or great issue reports
  • analytics

    • posthog - fonte
    • plausible - fonte
    • no
      • google analytics
        • seems like they’re doing bad stuff + illegal in eu (included Italy) because of GDPR
  • Architecture

  • Performance

    • partytown
      • cos’è?
        • fa le stesse cose dei service workers ma è meglio di loro solo quando usi builder.io
          • let’s say I don’t use builder.io. Would partytown be useful compared to standard service worker? as far as I understand the main takeoff is that you can put some scripts in another thread to reduce block time but I can do it with both partytown and default service workers

          • chat GPT answer

            • If you’re not using Builder.io or its content editor, the benefits of Partytown over standard service workers may be limited. The primary advantage of Partytown is its integration with Builder.io’s server-side rendering (SSR) and dynamic content capabilities. If you’re looking for general offline capabilities, caching, and background scripting in a web application, standard service workers are a more appropriate choice. Service workers are a core web platform feature and offer more flexibility for implementing various offline and caching strategies.

            Service workers can handle tasks such as caching static assets, intercepting network requests, handling push notifications, and performing background syncing. They operate on a separate thread, allowing for asynchronous processing and reducing blocking time.

            While Partytown provides the ability to execute scripts in a separate thread to avoid blocking the main thread, achieving similar functionality with service workers is also possible. Service workers can perform background tasks and handle network requests, effectively offloading processing from the main thread and improving performance.

            In summary, if you’re not using Builder.io or its content editor, and your focus is on general offline capabilities and caching, standard service workers would be a more suitable choice. They offer broader functionality and can be used to optimize the performance and offline experience of your web application.

    • Optimization
      • webGPU - to make anything faster (low support)
      • npm install @next/bundle-analyzer
  • DX

  • UI

    • tailwind typography plugin
      • transitions problem
        • plugin defaults transitions to 0
        • so I tried
          .prose * {
           
          transition-duration: 1000ms !important;
           
          }
           
          .prose > * {
           
          transition-duration: 1000ms !important;
           
          }
          	```
          - and noticed meaningful differences in the timing. The paragraphs and header text were so much slower to change color.
        • conclusion
        • transitions goes hard on GPUs escpecially when so many of them are trigghered at the same time and it may create inconsistencies
        • so I just used the .prose > * and I was ok with stuff not being consistent (it’s almost cool at the end)
    • tremor for dashboards
    • VFX
      • particles.js
      • 3D stuff
      • Rendering
      • Animation
  • features

    • Drag & drop

    • NLP - Natural Language Processing

    • Markdown

      • MDX

      • Unified.js

      • markmap

        • it asks for 3rd-party-requests over the internet

        • markmap-cli - less flexibility but simpler

          • can also manage 3rd-party-requests
        • render vs view

          • render - SSR
          • view - CSR
            • the only way to support markmap-toolbar
        • markmap-toolbar

        • “use client”

        import { useEffect } from ‘react’;

        import { Toolbar } from ‘markmap-toolbar’;

        import { Markmap } from ‘markmap-view’; // Import Markmap from markmap-view

        const C_MarkmapToolbar = () {

          useEffect(() {

            const container = document.querySelector(“.markmap-container”)

            const mm = Markmap.create(container);

            const { el } = Toolbar.create(mm);

            el.style.position = ‘absolute’;

            el.style.bottom = ‘0.5rem’;

            el.style.right = ‘0.5rem’;

            container.appendChild(el)

          }, []);

          return (<>

          </>)

        }

        export default C_MarkmapToolbar

    • MDX rabbit hole

    • Carousel swiper vs embla carousel swiper - embla

    • echarts examples

    • driver.js - unmaintained 22k

      • unmaintained sadly
    • revealjs

    • react email - e-mail crafter, not sender

    • for next.js

  • API

    • graph base
  • non-website