How it feels to learn JS in ~~2016~~ 2023 - eviltoast

I learned “pure” JS back in 2013, when HTML5 was brand new, and I still don’t get most of the stuff going on nowadays.

  • SavvyWolf@pawb.social
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    1
    ·
    1 year ago

    I stepped out of webdev like 5 years ago. Now every time I try to get back into things to work on an open source project or whatever I just give up because I do not understand things.

    Everything seems to be based on React which is some kind of magic templating library that does everything? And also dynamically updates thing in response to changes and talks to the server?

    I much prefer the days of just using vanilla js to manipulate a DOM and talk to a well defined API.

    • Mars@beehaw.org
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 year ago

      I’m sorry but framework and library in this post are going to be used loosely, because even React, Vue, Angular, Svelte, etc devs use the terms loosely.

      React is mostly a UI library like you would find in most native app development. Of them all them JS frameworks/libraries is one of the less opinionated and with less batteries included. By design it does not does everything. Most other frameworks do way more.

      It lets you define custom components. The components can have properties that their parent component defines and internal state. If the state or the properties change the component gets redrawn (magically). There are some lifetime functionalities (things to do on first render for example) and performance improving stuff (memoization) but mostly that’s it.

      All the other features you talk about are third party libraries or frameworks that can operate with react or are build on top of and cover the bases, like routing, fetching, caches, server side rendering, styling utility libraries, component libraries, animation libraries, global state management, etc.

      The big difference with the vanilla way is that the approach is mostly declarative. The runtime takes charge of updating the DOM when your components state or properties change.

      You take a big performance hit, and an even bigger bundle size one, but the speed of development and huge ecosystem of readymade solutions can be really important for some use cases.

      Other frameworks take different approaches to solve the same problems:

      • Component system for code reuse and organization.
      • Some way to manage state
      • Some way to decide what to re-render and when.
      • Extra stuff. Some frameworks end here, some have tools for everything you would need for a web app.
    • gornius@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      The thing is, they look like too much for a simple app with near none interactive elements.

      But once app starts growing, concepts like reusable components, reactivity and state management become such an important tool.

      Imagine tracking shopping cart’s total value. With these frameworks it’s just one store containing total value, exposing the value as reactive state. Once the value changes, all components using directly or indirectly that value update immediately. In vanilla you would have to keep track of every instance where that value is used manually.

      Additionally, if you decide keeping total value of cart in frontend is stupid (because it is), you just modify your store to provide only readonly value, and create setters that require you to pass item or item id. Then that setter would hit up backend keeping your cart’s total value, add an item, and backend would return new total, which would now be set as that store’s new total value.

      These frameworks are kind of SOLID principles applied to chaotic world of user interfaces.