Comment by qudat | Hacker News Reader

Comment by qudat | Hacker News Reader

> 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

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

> 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.

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.

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.

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.

I didn't say it does? I am just spliting hairs over the definition of framework.

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.

> 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?

> I'm "calling into" react (3) times here, while react is calling "into me" (1) time.

It's calling into you three or more times, invisibly, if I remember the details of what useEffect and useState actually do at runtime correctly. Which rather illustrates the point.

> Are we saying any external source code that accepts a function as a parameter is considered a framework?

Code that accepts a function for narrowly scoped use where the control flow is still under your control (e.g. map/reduce/filter libraries) is probably not a framework. But external code where you register a callback that gets called some time later, not under your control, is pretty much the definition of a framework.

> It's calling into you three or more times, invisibly, if I remember the details of what useEffect and useState actually do at runtime correctly. Which rather illustrates the point.

If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that second argument is "only run the passed-in function once on mount").

> If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that second argument is "only run the passed-in function once on mount").

As I understand it both the useState and useEffect create points where their code will be suspended and resumed as a coroutine, even if everything only gets run once? But yeah, the more important point is that in the general case React will run it multiple times in ways that are not really under the user's control (at least not without understanding the internal details of React quite deeply).

Nope:

The first run through, useState() returns the default value and your code runs to completion. When the update function is called, that entire React function is run again, but this time useState() returns the new value instead of the default value.

Likewise useEffect(), your React function runs all the way through and the callback passed to it is run afterwards at various times depending on the dependencies array. First run is immediately after, on component mount, then every time the dependencies change (if dependencies are specified), or every rerender (if null/undefined instead of an empty array).

> The first run through, useState() returns the default value and your code runs to completion.

Your function was still sliced into the part before and the continuation (Dispatch) after though, right? The React runtime calls that continuation immediately with the default value, so you don't notice the suspension, but control flow wise it's still React calling your code twice rather than once.

Nope, it's a normal function that updates some variables in the React module then returns two values. There's a little bit of magic going on, with how it knows which component it's in, but that's happening outside of the individual hooks.

Reply on news.ycombinator.com