Preact Vs React JS

Поделиться
HTML-код
  • Опубликовано: 25 авг 2024
  • Preact JS offers more power and speed than the regular React JS framework. The idea behind Preact is that it's much faster and smaller. But when I compared the minified file sizes of React and Preact, they seemed similar.
    It's a bit tricky, but to my eyes, it does seem like both minified JavaScript files appear almost the same. That's, however, more than three kilobytes of JavaScript. The gzipped version of both files even looks identical, and when unzipped, Preact is slightly larger.
    I haven't been able to validate the claim of Preact being just three kilobytes. I've tried looking from various perspectives, but I always ended up with 11 kilobytes, which is more than what React.js measures. Despite not seeing a notable decrease in file size while using Preact, there are still advantages in terms of virtual DOM use.
    Unlike heavy-handed React and other frameworks, Preact strikes the right balance by using the exact amount of virtual DOM, which is beneficial as overuse can cause performance hits. Preact is also advertised as one of the fastest virtual DOM libraries available, and it doesn't skimp on portability, functioning almost everywhere React works, save for a few exceptions. Analyzing example codes of Preact, it's functionally similar to React but supposedly faster.
    React tends to have one common flaw: it lets you create a slow-running web app and a bulky payload. While it's great for facilitating teamwork, the output often involves a sluggish render that paves the way for poor user experience, especially on battery-operated devices or even high-performance desktops. You could adopt some patterns to enhance user experience, but the difficulty lies in the extra work you will need to put into optimizing your app.
    Enter Preact, a faster alternative to React. Preact aims to resolve the problems stemming from the cumbersome React framework. The concept behind Preact was to minimize its footprint while dealing with the troublesome aspects of virtual DOM. If you're struggling with React’s slowness and an oversized footprint, it's better to switch to a more efficient framework rather than waste time trying to optimize the existing app.
    Another standout aspect of Preact is its synthetic events feature, a part of React that Preact has avoided, opting for browser's event listeners instead. This feature simplifies the coding process. It reduces the amount of code you have to write, depending more on the browser. while comparing Preact.js and React.js, some issues have sprung up.
    I've discovered that both Preact and React have the same file size, despite the latter’s claims of being three kilobytes. Tackling this problem, I've considered tree shaking or eliminating redundant parts of the libraries. Preact also lacks certain components present in React, like hooks, which have to be imported separately.
    This move can lead to the negation of Preact’s claim of having a small library footprint, as extra parts need to be imported. Although Preact still remains one of the quickest virtual DOM libraries for rendering, it'd be appreciable if Preact could incorporate these advancements, which might just be in the works. In terms of usability, Preact takes the edge as it does not require extra steps for setting up your app as React does.
    With Preact, you don't need to create different attribute names like in React. Preact also goes easy on the SVG, supporting its native attribute styles, unlike React, which insists on camel-casing. So while exploring Preact versus React, their similarities are apparent, and Preact offers a few extra benefits and a slightly smaller file size.
    Whichever framework you choose, React or Preact, you are investing in a solid framework that allows you to provide a great user experience. If you're looking at enhancing the performance of your existing of React app, Preact could be a good option for you. The transition is generally smooth, with minor changes here and there.
    If you’re starting afresh and need a framework to build an advanced UI, Preact is a great place to commence. With React being a popular choice, it is expected to see performance upgrades baked into its core, which makes it a worthwhile contender as well. Being fundamentally the same, choosing either Preact or React won't make much of a difference.
    Preact looks to be a good choice, but in time, React may catch up and even incorporate these advancements by default.

Комментарии • 26

  • @robethrahmatullah7779
    @robethrahmatullah7779 8 месяцев назад +15

    5:19 You actually need "react-dom" (42 KB minified + gzipped) to render something in the browser
    10 KB "react" library only contains the core runtime so it could be used for other platforms (react native, ink, etc.)

    • @StephenBlum
      @StephenBlum  8 месяцев назад +2

      @robethrahmatullah7779 ah good catch! This is noteworthy in that case. Since react-dom a masive 42KB minified and gzipped. Preact is a much smaller library in comparison.

  • @lifeofcode
    @lifeofcode 8 месяцев назад +1

    Good stuff as always bro. LOL! I believed preact at face value when they said they were 3kb. Never looked into it! I've heard people using the preact signals package though in react. Seems like it could be cool.

    • @StephenBlum
      @StephenBlum  8 месяцев назад

      😄 It was funny to see that the two libraries were the same size! Both about 10kb minified. You are right, the signal package can help improve the performance. It seems like the largest advantage that Preact can offer

    • @dereksniper
      @dereksniper 7 месяцев назад +1

      was looking into this and seems like a better alternative. However would you make a project in vite in react and just import signals or just go preact?

    • @lifeofcode
      @lifeofcode 7 месяцев назад

      @@dereksniper vite + react with signals is how I've seen most taking advantage of it.

    • @StephenBlum
      @StephenBlum  7 месяцев назад +1

      @@dereksniper excellent question. I would go with the simplest approach. Fewer dependencies. I tend towards liking things simple and performant 😄 using preact directly would be a great choice

  • @ramsey2155
    @ramsey2155 4 месяца назад +2

    You need to use the deployment configuration for the actual optimization...

    • @StephenBlum
      @StephenBlum  4 месяца назад

      Nice! that explains the optimization opportunity. Thank you! 😊

  • @damiangilz
    @damiangilz 4 месяца назад +1

    What i find weird of Preact is that the docs still push class components hard.

    • @StephenBlum
      @StephenBlum  4 месяца назад

      good point! Yes class components are push for compatibility focus. That may be due to docs that should be updated to push harder on "hooks". PreactJS supports hooks and this can be a better approach

  • @LazyDesigner65
    @LazyDesigner65 11 дней назад +1

    😮

  • @einfacherkerl3279
    @einfacherkerl3279 7 месяцев назад +1

    the real problem is that everyone is trying to fix react. Solidjs, qwik, Preact etc. they are trying to create solution for which problem needs to be invented. what is needed is the application framework that helps build app logic. this is not fully solved by redux, xstate , mobx etc.

    • @StephenBlum
      @StephenBlum  7 месяцев назад

      good point yes that React itself is already provides the most common needs for the majority of apps. today React does have a few missing or unoptimized capabilities. Things like redux, xstate, mobx can be standardized directly in React core itself as optional recommended additions. We could benefit from the performance boosts that Preact promises if React would make the needed adjustments to provide a faster user experience

  • @nexovec
    @nexovec 2 месяца назад +1

    I don't like this, not only because you don't understand react-dom, which means you have never used react as an actual js library in the browser, else you'd know you can't even render anything this way, but more importantly, because the way react makes you program results in larger bundles than strictly necessary.
    How is it possible you feel confident talking about this? Waste of time.

    • @StephenBlum
      @StephenBlum  2 месяца назад

      You are right 😄 The miss in the video, it is exactly as you describe. React + React-dom is massive compared to Preact. This is a big aspect to choosing Preact and improving your user's experience by providing a faster and smaller web framework library.

    • @nexovec
      @nexovec 2 месяца назад +1

      @@StephenBlum That was already pointed out by others too.
      What I want to know is if it's possible to ship a client-side SPA under say 500kb using something that can leverage the existing React components ecosystem. Preferably without multiple build steps too. Can't get an answer anywhere on the internet.
      Maybe no-one has tried... maybe react devs don't care about bundle size and performance until they receive complaints from customers, and then what they do is offload something to SSR and call it a day.

    • @StephenBlum
      @StephenBlum  2 месяца назад

      @@nexovec looking around there does appear to be a way to reduce SPA JS size using React + Ecosystem. If I can get it to work I'll add this to the planned upcoming videos as a tutorial walkthrough! 🙌

    • @StephenBlum
      @StephenBlum  2 месяца назад

      @@nexovec this actually looks like a pretty good option for existing-projects: preactjs.com/guide/v10/getting-started#integrating-into-an-existing-pipeline it requires editing your build files with Babel and Webpack. If you are not using those, then it is a necessary step to get as much as possible from PreactJS. The aliasing is need to replace react core and react-dom. Also Preact +10 includes hooks. Which is a problem I ran into when getting it to eventually work.

    • @nexovec
      @nexovec 2 месяца назад +1

      ​@@StephenBlum Do show some benchmarks and comparisons of a react app ported into preact, if you go that far, in which case count me interested 🙌