5 ms·

I think we have, for better or worse. When I think of frontend JS these days, what comes to mind is Angular, React, Vue, Svelte, etc. jQuery feels (and is) simp

I think we have, for better or worse. When I think of frontend JS these days, what comes to mind is Angular, React, Vue, Svelte, etc. jQuery feels (and is) simple in comparison. All the more surprising - I've been building frontend UIs from the late 90s, starting with plain JS, to prototype, to jQuery and onwards. I'm kinda amazed over how my perception of 'what is normal/acceptable in JS' has slowly but steadily changed over time.

lucideer 7y ago
I'm a big fan of a lot of new frameworks, but one of the reasons I prefer React* to Angular is its simple feel. The React library is usable "with" idiomatic plain javascript, rather than instead of (sure chained jQuery api calls are technically JS, but they're more akin to another language/convention within. Angular html directives are a whole nuther thing). The React library itself is small (~7kb to jQuery's ~30kb), and simple. So conceptually simple in fact that it lends itself to reimplementations like preact. The added weight of the somewhat over engineered react-dom renderer needed for browser rendering is regrettable, but still the modular approach is elegant in its simplicity and there's no reason you couldn't swap out the renderer. What I'm getting at here is: I much prefer using plain vanilla JS as I did when I started in the early 00s, but even when it does makes sense to jump on the library bandwagon, it's possible to take a critical approach and avoid unnecessary extra complexity. jQuery has never been that. At any point. * Important to clarify I'm referring to the React library, not React's ecosystem
- stepbeek 7y ago
  I thought that idiomatic react involved using JS render functions to turn JSX + Data into HTML; and using css-in-js to handle styles? I'm somewhat wary of React because I feel like it pushes developers to work with non-standard tools rather than the HTML + CSS + JS that browsers handle just fine. I agree wholeheartedly on the ecosystem. I think global state stores will have a reckoning in the next 10 years where we collectively realize that maintaining a large amount of client-side state is not required for 90% of sites.
  - lucideer 7y ago
    You're right about idiomatic React + JSX; I was incredibly wary of React at first because of the apparent requirement of a JSX preprocessor, to the extent that I went out of my way to use non-JSX React. It was very easy—the ease of opting to do that gave me a bit of extra appreciation of the modularity of React (JSX is 100% a separate thing). That said, Typescript got me (maybe a little too) comfortable with having a preprocessor: I still use JSX-less React but in Typescript I've actually started using React-less JSX... CSS-in-JS is silly. I put that idea into the same bucket as a lot of other nonsense in the React ecosystem. Don't.
    - npsomaratna 7y ago
      Thanks for the explanation. I tried out React a while ago, didn't like the idea of JSX, then saw the complexity of the React ecosystem, and then decided "nope, too much complexity." I ended up using Vue, although from that I'm seeing, Vue is going down the "let's add complexity" route with Vue 3. I'll look at React again and reassess in this new light.

lucideer 7y ago

I'm a big fan of a lot of new frameworks, but one of the reasons I prefer React* to Angular is its simple feel. The React library is usable "with" idiomatic plain javascript, rather than instead of (sure chained jQuery api calls are technically JS, but they're more akin to another language/convention within. Angular html directives are a whole nuther thing). The React library itself is small (~7kb to jQuery's ~30kb), and simple. So conceptually simple in fact that it lends itself to reimplementations like preact. The added weight of the somewhat over engineered react-dom renderer needed for browser rendering is regrettable, but still the modular approach is elegant in its simplicity and there's no reason you couldn't swap out the renderer. What I'm getting at here is: I much prefer using plain vanilla JS as I did when I started in the early 00s, but even when it does makes sense to jump on the library bandwagon, it's possible to take a critical approach and avoid unnecessary extra complexity. jQuery has never been that. At any point. * Important to clarify I'm referring to the React library, not React's ecosystem

stepbeek 7y ago
I thought that idiomatic react involved using JS render functions to turn JSX + Data into HTML; and using css-in-js to handle styles? I'm somewhat wary of React because I feel like it pushes developers to work with non-standard tools rather than the HTML + CSS + JS that browsers handle just fine. I agree wholeheartedly on the ecosystem. I think global state stores will have a reckoning in the next 10 years where we collectively realize that maintaining a large amount of client-side state is not required for 90% of sites.
- lucideer 7y ago
  You're right about idiomatic React + JSX; I was incredibly wary of React at first because of the apparent requirement of a JSX preprocessor, to the extent that I went out of my way to use non-JSX React. It was very easy—the ease of opting to do that gave me a bit of extra appreciation of the modularity of React (JSX is 100% a separate thing). That said, Typescript got me (maybe a little too) comfortable with having a preprocessor: I still use JSX-less React but in Typescript I've actually started using React-less JSX... CSS-in-JS is silly. I put that idea into the same bucket as a lot of other nonsense in the React ecosystem. Don't.
  - npsomaratna 7y ago
    Thanks for the explanation. I tried out React a while ago, didn't like the idea of JSX, then saw the complexity of the React ecosystem, and then decided "nope, too much complexity." I ended up using Vue, although from that I'm seeing, Vue is going down the "let's add complexity" route with Vue 3. I'll look at React again and reassess in this new light.