9 ms·

I think hooks aren't really making React more of a black box, but just that it's invalidating a lot of people's incorrect mental models on how React works. (It'

• 3np 6y ago
  I feel similarly with Nomad vs Kubernetes
• ethbr0 6y ago
  Good old XKCD 927 applies [1]. "This system is hard to work with" -> {Abstraction created} -> {Abstracted extended to support new features} -> GOTO 10 Now you have n+1 systems to learn & reason through. [1] https://xkcd.com/927/ https://xkcd.com/927/
  • JadoJodo 6y ago
    This was my thought as I counted 9+ React alternatives mention in this thread alone.
    • msie 6y ago
      This is the stuff I've counted so far (I know they are not all React alternatives): Preact, Mithril, Crank.js, Hyperscript, Reagent, Closurescript, Elm, Cycle.js, Lit-html, Haml, Slim, Jsx, Meiosis, Svelte, Formik, Vue...
• fouc 6y ago
  I took a quick look at the docs and I'd say the API looks to be pretty similar to mithril.js. Not sure why you think mithril would have a thicker abstraction in comparison.
• hoorayimhelping 6y ago
  >I think hooks aren't really making React more of a black box, but just that it's invalidating a lot of people's incorrect mental models on how React works. Isn't that exactly the point that the big image on the front page is making? If most people have a mental model of a technology that doesn't match what the company is putting out, it makes very little sense to blame the people who have the 'incorrect' mental model. If it wasn't so widespread, your point would be much stronger. But the fact that the core pieces of react are misunderstood, especially when React publishes documents explaining how all of this is supposed to work and how you're supposed to think about this is an indication that something is wrong with React, not the people who use it.
  • lucideer 6y ago
    > If most people have a mental model of a technology that doesn't match what the company is putting out, it makes very little sense to blame the people who have the 'incorrect' mental model. While you're right that we shouldn't "blame the people", I think blaming the company / library in this case doesn't fly either, given the specifics. The "incorrect mental model" people have about React is based on two things: 1. the prevalence of OO concepts in programming education and in practice in most engineering teams 2. the introduction of class abstractions onto JS prototypes by the ES spec. followed by: 3. React bundling things like `createReactClass` and encouraging class abstractions in their docs in the pre-hooks days While the 3rd point above may have been a mistake on the part of the React team, I do think points 1 & 2 are much bigger factors here. > something is wrong with React The only thing "wrong" with modern React is that they're challenging the status quo in popular programming concepts with something they believe is a conceptual improvement. You can disagree with them on whether it represents a true improvement, but saying they're "wrong" because their conceptual model is a departure from the status quo is pretty reductive.
    • varrock 6y ago
      > 1. the prevalence of OO concepts in programming education and in practice in most engineering teams What makes this point tricky is that React did initially introduce their library with OO concepts for years.
• azangru 6y ago
  Hooks are fine. The approaching ConcurrentMode though is scary. Most of the global state solutions are suffering from various kinds of incompatibility with the concurrent mode that opens the door to various kinds of bugs: https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-mode https://github.com/dai-shi/will-this-react-global-state-work...
  • mlsarecmg 6y ago
    useMutableSource fixes these concerns. they all will light up green. some have it already as a draft or experimental, for instance zustand: https://github.com/react-spring/zustand/pull/160 https://github.com/react-spring/zustand/pull/160 with concurrent mode i think of what could be, web applications that can compete against native for the first time. as well as making making components that are resilient to async issues / making async a high level concept. there's a little churn for sure (for library devs, and a specific subset), but imo completely worth it.
    • untog 6y ago
      > with concurrent mode i think of what could be, web applications that can compete against native for the first time Native apps feel better than web apps because they have robust UI libraries that web apps do not. React concurrent mode will have zero effect on that. If the argument is "React concurrent mode will make web apps faster so that they feel more native", my response would be to use something like Svelte, which is available today and is considerably faster than React. React is slow. Concurrent mode may make React faster but it'll just be making up for React's past mistakes, not the web's.
      • api 6y ago
        It's really unfortunate that Web Components are utterly useless. They simply are not components. It's insane.
        • azangru 6y ago
          I am not sure what you mean. Youtube is built on web components. Github is using web components. There are various libraries that can do web components, including Preact, Vue, or Svelte: https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/ https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...
• candiddevmike 6y ago
  After using hyperscript via Mithril, I don't think I can go back to writing JSX. Hyperscript should be the defacto way to template HTML in JavaScript in my opinion, it's just so much cleaner and readable.
  • azangru 6y ago
    It's been the way Elm describes its components; and I believe Andre Staltz has been criticizing jsx in favor of hyperscript since forever [0], and included hyperscript in cycle.js. Lit-html, which is using template literals, is another good option. [0] - https://staltz.com/some-problems-with-react-redux.html https://staltz.com/some-problems-with-react-redux.html
  • nsonha 6y ago
    Back when jsx was introduced people said so too but they weren't as loud as the other group. When you look at a completely new language, reasonml where they're still of the mindset that jsx bring familiarity it makes nosense. Just an excuse for some abitrary preference.
    • searchableguy 6y ago
      Someone might find these issues interesting on flutter regarding jsx: https://github.com/flutter/flutter/issues/11609 https://github.com/flutter/flutter/issues/11609 https://github.com/flutter/flutter/issues/15922 https://github.com/flutter/flutter/issues/15922
      • nsonha 6y ago
        I remember getting excited learning that I could do Xamarin Form in plain function calls in F#. Android is going similar journey simplify UI programming with Jetpack Compose. Jsx is backward and purely stylistic.
  • pier25 6y ago
    I love Mithril but I find hs to be noisy to read and tedious to write. It's probably because I've been reading and writing HTML for +20 years though.
• aidenn0 6y ago
  It's funny you mention Mithril, because to me, that was the "minimum level of whiteness" box. I tried react fairly early, and when I did something wrong, it was completely unobvious to figure out by debugging the non-minimized code. Mithril was sufficiently thin for me to drop into the debugger, say "oh, that's how it works" and fix. I'll take a look at crank though. I do frontend dev only to make my hobby projects accessible to friends and family, so the less to remember, the better.
• aboodman 6y ago
  Crank looks super cool, thanks for sharing. Using generators for stateful components makes a lot of sense.
• matt42 6y ago
  I love the way crank is using generators to get rid of the react complexity.... Did not know about crank, thanks for the link.
• jonahx 6y ago
  For something even more "clear box" (it's not even a framework) that you can understand in a single sitting, check out Meiosis: https://meiosis.js.org/ https://meiosis.js.org/
• dinoreic 6y ago
  I cant understand how a developer can be aware of existence of Svelte (https://svelte.dev/ https://svelte.dev/) and still have React problems. Just start with creating web components in Svelte, include them in existing React code, and slowly phase out slow, and old tech that React is. This is just frontend lib, why are people so religious about this. You still use Node, JS/TS, etc. Im I troll? Don't know, but that is just what I did year ago. Now I just laugh when I see articles like this, buy I also feel sad for small entrepreneurs that have to pay big $ for code in "dated tech" - thinking "they are on the edge".
  • regularfry 6y ago
    React's big enough that large dev orgs have made big investments into it and can't switch to Svelte on a dime.
    • chrisco255 6y ago
      It's not only that, but there's always dragons in scaling a framework to accommodate teams of hundreds of devs and supporting millions of users. Svelte is less known in this regard. Marginally better along one or two dimensions is not enough to justify the risk.
  • mmmeff 6y ago
    I'm interested in this - do you recommend any documentation or writing on mixing React and Svelte codebases?
  • protonimitate 6y ago
    Svelte is be recommended left and right as the "solution to React" but I think it's still way too young of a project to be the cure-all that people think it is. It's promising, especially for smaller projects/MVPs, but I still have no idea how well it will scale with app size/team size (and have yet to see good evidence that it does it well). I just find it ironic that people dog on React for being the "default", but then also can't recommend Svelte fast enough, seemingly because its just "not React".
  • qmmmur 6y ago
• johnghanks 6y ago
  is this a thinly veiled ad?
• ogre_codes 6y ago
  As with every issue around javascript front end library, the solution is of course... a new javascript front end library. - jQuery - Backbone - Ember - React - ???
  • rapind 6y ago
    javascript /s/java/churn
  • marban 6y ago
    MooTools!
  • xmprt 6y ago
    The only two that I'd put on the same level are jQuery and React. And people are still happily using jQuery to this day (maybe happy is the wrong word). So I don't think React is going anywhere for a long time but if something better comes out then why is that a bad thing?
    • ogre_codes 6y ago
      It is more about the relative instability of Javascript as a platform versus nearly any other platform out there. Skills I learned in college about writing SQL are still relevant today, several decades later. Skills I learned coding for iOS (even Swift!) years ago are still relevant today. CSS and HTML skills I learned decades ago are still relevant, etc etc. Python/ Django knowledge from 10 years ago is still largely relevant. React/ jQuery/ EmberJS/ Vue/ Angular/ Grunt/ Gulp/ Webpack/ Underscore/ CoffeeScript/ etc... damned near every Javascript library I've ever worked on has an extremely limited lifespan in terms of relevance. Even within React, it's hard to keep relevant. Class based React? We're doing Hooks now! > why is that a bad thing? It's only bad if you have to try and maintain 10 year old Javascript and in order to do it, you have to learn a whole new paradigm. IMO it's doubly bad right now since so many people are abandoning semantic HTML and more or less rolling everything as their own custom components.
      • Semiapies 6y ago
• palmdeezy 6y ago
  Hi, it's Jared (the OP)... Well said. Perhaps my deeper point is that hooks and soon Concurrent Mode force devs to come to terms with the fact that they _don't_ understand React internals (hence my usage of black box) and that their mental models were wrong this whole time (although some might argue still pretty productive). I also think Crank is SUPER interesting on so many levels. I built a few demos with it and am fairly impressed. However, practically speaking (and I'm putting my developer relations hat on), I think its generator API is just too intimidating to junior developers.
  • ng12 6y ago
    I usually explicitly tell devs to not worry about React internals. Let React decide when to re-render or how to batch state updates. React's API is small, developer time is better spent understanding the API than wondering how React works under the hood. That said it's still a mental shift. Sometimes I feel like I'm writing React and not writing JavaScript.
  • nikkwong 6y ago
    I noticed at the end of the blog post you stated that you're very excited about the debut of the upcoming Concurrent Mode (CM) in React. I've read about the problem that Concurrent Mode is working to address; but I'm confused as to why React needs this additional feature set when I'm unaware of any other UI frameworks which have a feature set that seem to mirror that of CM. Vue or Svelte do not seem to need these additional features to achieve comparative rendering benchmark speeds to React, and I'm unaware of any holes in these frameworks that something like CM would adequately address. (?). Is Concurrent Mode basically a way of addressing performance problems in React, or is this in some way a feature that adds something novel? Or is it just a side effect of an unwillingness to move away from functional programming? I write React at work, but write Svelte or Vue at home, and I've always found React's abstractions to be the most hard to reason about, and from the looks of it CM will make this more challenging (??). Thanks.
  • supermatt 6y ago
    Isn't the wider problem that people don't try to understand the internals? Some of us may read the code of modules we "require", but experience tells me this is a rarity. For those that do, this isn't an issue, and for those that don't, this isn't an issue either. Their mental model may be flawed, but as long as the IO is the same, do they really care? Concurrent mode isn't really a black box. Its just a shortcut to throw away work that would otherwise be invalidated.
• lhorie 6y ago
  (disclaimer: mithril author here) The point of an abstraction is to create a "black box" of sorts around some primitive. I think all it boils down to with what the author is saying is that the React team is changing how things work under the abstraction, and therefore some assumptions people made about leaked semantics are no longer true. Mithril rendering semantics have always been more or less this: on an event, redraw everything. React semantics started that way too, but now there are a whole lot of other semantics under the hood (for example, the rule of hooks provides some semantic guarantees that enable a hot reload implementation to be more robust). Concurrent mode is another example of semantics that benefit from rule of hooks guarantees. I think when I see people complain about the rule of hooks is that there's a dissonance between the strict semantics of hooks and the expectations of what the semantics should be (for some definition of "should", usually related to ability to reason about stuff in some specific way) I'd say that overlapping several different compatible underlying functional semantics under one umbrella of very strict API semantics is an interesting and somewhat novel approach to supporting some cool infrastructure (i.e. ability to do deep hot reloading stuff, animate in IoT devices in a renderer-agnostic way, React Native, granular reactivity via memo, and the list goes on). Where I think React missed the ball a bit is that the API semantics don't always feel ergonomic for the use case they're meant to serve (for example, I've seen a few occasions where nested hooks ended up w/ long code review threads debating obscure minutiae) When I see people praise Svelte, I think the reason is similar: since it doesn't need to artificially create constraints to support every use case under the sun, its API semantics are able to align very closely to people's expectations.
• bfuclusion 6y ago
  Omg, a promise based render chain? I'm in love.
• fuzzythinker 6y ago
  Crank looks interesting, thank you! I was going to try solidjs[1] (which feels pretty close to crank) in my next project, will look more into crank first. [1] https://github.com/ryansolid/solid https://github.com/ryansolid/solid