5 ms·

> The choice isn’t between JavaScript frameworks, it’s whether SPA-oriented tools should be entertained at all. For most sites, the answer is a clearly “no”. “

by qudat 2y ago

> The choice isn’t between JavaScript frameworks, it’s whether SPA-oriented tools should be entertained at all. For most sites, the answer is a clearly “no”. “Most sites” sit in the world of marketing, ecommerce, blogs. True, they don’t need an SPA. Then there are businesses that “require” highly dynamic websites with tons of data funneling through them. I use require here in the sense of business requirements set by the various Product teams. These products benefit from being an SPA. Preload and fetch is such an incredible paradigm for speed and interactivity that every company I’ve worked for has appreciated. Company employees are not trying to run their work browsers without JS nor do they even have to particularly worry about mobile support. It’s a very predictable environment: office, work laptop, internet that can support video calls, and a modern browser. That’s the operational stack that many businesses require. > The predictable consequence are NPM-algamated bundles full of redundancies like core-js, lodash, underscore, polyfills for browsers that no longer exist, userland ECC libraries, moment.js, and a hundred other horrors. People really love to hate on npm without trying to understand the reason why it exists in its current form: https://bower.sh/my-love-letter-to-front-end-web-development https://bower.sh/my-love-letter-to-front-end-web-development As a semantic aside, I wince when people call React a framework. If we think of an SPA in terms of an MVC framework, it primarily handles the V. So really it’s a view library since developers can use whatever M and C they want. Next.js is a react framework and as a React expert it’s something I have zero interest in using. I could keep going but these arguments have been argued and counter-argued before. For a different spin on the success of react: https://bower.sh/react-is-bad-because-its-great https://bower.sh/react-is-bad-because-its-great

johnfn 2y ago
I agree with most of what you said. As a minor nit, my understanding is that you call into a library, whereas a framework calls into you. Since React typically does most of the calling into my components I think it’s fair enough to call it a framework.
- qudat 2y ago
  That’s a nice description but it is not perfect. React does one thing well: view = func(state) It doesn’t have a great story for virtually anything outside of that single function which means for many large apps it is never enough.
  - hasanhaja 2y ago
    But most people don't use it for the only thing it does well and pick appropriate approaches for the other parts; they use it for everything and this has transpired into the reinventing of browser mechanisms like CSS in user land. This is the real problem. Not the tool "React" (or others like it) but the cult that vehemently denies their bets were wrong and doesn't take responsibility for the real damage it's caused.
  - johnfn 2y ago
    I didn't say it does? I am just spliting hairs over the definition of framework.
  - proto-n 2y ago
    It seems you only want to call MVC frameworks frameworks? But there's millions of other types of frameworks for thousands of purposes. Framework is a generic term (for which the definition is usually the calls into you/you call into it thing). What it does and whether it's a framework is two completely orthogonal things.
    - qudat 2y ago
      > It seems you only want to call MVC frameworks frameworks? No, I'm illustrating the limited scope of React. I wouldn't call a chunk of code that handles the V in MVC a framework. > for which the definition is usually the calls into you/you call into it thing Again there's nuance here: import { useEffect, useState } from "react"; import { createRoot } from 'react-dom/client'; document.body.innerHTML = '<div id="app"></div>'; const root = createRoot(document.getElementById('app')); root.render(<App />); function App() { const counter = useState(0); useEffect(() => { console.log('effect') }, []); return <h1>hello world: {counter}</h1> } I'm "calling into" react (3) times here, while react is calling "into me" (1) time. Are we saying any external source code that accepts a function as a parameter is considered a framework? All react does is render/diff/patch your dom, everything else is up to the end-developer. Would you call `express` a framework? Again this is semantics but look at all the react frameworks that exist on top of react, why do those exist?
lmm 2y ago
> As a semantic aside, I wince when people call React a framework. If we think of an SPA in terms of an MVC framework, it primarily handles the V. So really it’s a view library since developers can use whatever M and C they want. React isn't a library, it's a framework. A narrowly focused framework perhaps, but a framework nonetheless: it has to control the event loop and you have to follow its special rules (hooks), you can't just call into it like vanilla code.

by qudat 2y ago

johnfn 2y ago

I agree with most of what you said. As a minor nit, my understanding is that you call into a library, whereas a framework calls into you. Since React typically does most of the calling into my components I think it’s fair enough to call it a framework.

qudat 2y ago
That’s a nice description but it is not perfect. React does one thing well: view = func(state) It doesn’t have a great story for virtually anything outside of that single function which means for many large apps it is never enough.
- hasanhaja 2y ago
  But most people don't use it for the only thing it does well and pick appropriate approaches for the other parts; they use it for everything and this has transpired into the reinventing of browser mechanisms like CSS in user land. This is the real problem. Not the tool "React" (or others like it) but the cult that vehemently denies their bets were wrong and doesn't take responsibility for the real damage it's caused.
- johnfn 2y ago
  I didn't say it does? I am just spliting hairs over the definition of framework.
- proto-n 2y ago
  It seems you only want to call MVC frameworks frameworks? But there's millions of other types of frameworks for thousands of purposes. Framework is a generic term (for which the definition is usually the calls into you/you call into it thing). What it does and whether it's a framework is two completely orthogonal things.
  - qudat 2y ago
    > It seems you only want to call MVC frameworks frameworks? No, I'm illustrating the limited scope of React. I wouldn't call a chunk of code that handles the V in MVC a framework. > for which the definition is usually the calls into you/you call into it thing Again there's nuance here: import { useEffect, useState } from "react"; import { createRoot } from 'react-dom/client'; document.body.innerHTML = '<div id="app"></div>'; const root = createRoot(document.getElementById('app')); root.render(<App />); function App() { const counter = useState(0); useEffect(() => { console.log('effect') }, []); return <h1>hello world: {counter}</h1> } I'm "calling into" react (3) times here, while react is calling "into me" (1) time. Are we saying any external source code that accepts a function as a parameter is considered a framework? All react does is render/diff/patch your dom, everything else is up to the end-developer. Would you call `express` a framework? Again this is semantics but look at all the react frameworks that exist on top of react, why do those exist?

lmm 2y ago

> As a semantic aside, I wince when people call React a framework. If we think of an SPA in terms of an MVC framework, it primarily handles the V. So really it’s a view library since developers can use whatever M and C they want. React isn't a library, it's a framework. A narrowly focused framework perhaps, but a framework nonetheless: it has to control the event loop and you have to follow its special rules (hooks), you can't just call into it like vanilla code.