21 ms·

What I wish I knew about React

236 points by ire 6y ago

prodave 6y ago
Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.
- foota 6y ago
  Imo, hooks present an API that is much less difficult to internalize, but maybe holds your hand less? I used react for a few months on a sideish project and had trouble knowing which component method I needed for something, whereas with react now it's all covered by hooks.
- awestroke 6y ago
  No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.
  - batiste 6y ago
    Would it be possible to have a single method on a class that behaves like whatever useEffect is doing?
    - lindskogen 6y ago
      Not in a single method, no. Watch this talk for more details! https://www.youtube.com/watch?v=wXLf18DsV-I https://www.youtube.com/watch?v=wXLf18DsV-I
      - batiste 6y ago
        Well, I did something a bit similar my own language: https://github.com/batiste/blop-language/commit/90e7704e125ffb3c1fe6b4de2446680d3819ab7e https://github.com/batiste/blop-language/commit/90e7704e125f... Not sure where classes are an issue with doing anything like this
  - TechBro8615 6y ago
    Adding to this, hooks make it much easier to pull related state management code out of the component. They help make state logic just as composable as UI logic.
- fabian2k 6y ago
  My superficial understanding is that React components as classes are far more complicated than they might seem at first. You're not in control of creating the class instances, rendering them or destroying them. React is in control of that. The constructor is the wrong place for data fetching in React class components as far as I remember anyway. I don't remember the exact reason, but it always has been somewhat non-obvious and you always needed to understand the React lifecycle to avoid bugs in that kind of code.
- ng12 6y ago
  > And anyone who has used classes in Java or other languages would feel at home. Not really because there's nothing object oriented about React.Component. It's just a wrapper for a function implemented as a class.
  - cmckn 6y ago
    THIS is what I wish I knew about React. As a Java user, I made incredibly wrong and damaging assumptions because "classes, I know what these are"! I still can't make heads or tails of hooks, but in due time!
- deviantfero 6y ago
  I've worked with both extensively, hooks are way easier to grasp, they allow you to avoid numerous ifs and comparing manually to previous states, you can separate actions according to what properties you're listening changes on, which would be cobbled together in a traditional life-cycle method, and the best part? They can be reused between components
- Bahamut 6y ago
  In my 1.5 years or so of using hooks, I'm finding components with hooks subtly more buggy than their class counterparts - there are a lot of gotchas with that dependency array for hooks, I have encountered nasty bugs both with explicitly declaring all of the dependencies in the array and declaring less than them. It is much easier to accidentally create infinite loops with useEffect that you would never create with class components, and some of the code you write turns out to be more verbose and less expressive, such as when trying to diff previous and current values of state & needing to create extra state variables with useState for each such value you need to react on. Hooks seem very appealing at first (I lean more FP than OOP in general), but the bugs and slipshod initial rollout out of beta really does not inspire much confidence. Even today I still encounter weird issues.
- efdee 6y ago
  Classes in React are confusing because they aren't actually classes, just something shoehorned into classes. For example you wouldn't write your initialization code in the constructor, you would do it in componentDidMount. Classes in React generate false expectations.
  - 7777fps 6y ago
    I liked that model because as an ASP webforms developer the class lifecycle is easy to reason about, like a page lifecycle. In ASP you wouldn't put initialisation code in the page constructor either, it would go in Page_Init, Page_Load, etc. Of course the tooling there made it both easier to put in the right place and harder to edit the page constructor to stick it in the wrong place.
    - efdee 6y ago
      I remember ASP.NET Webforms, and the reason most of the community moved towards MVC-ish frameworks is exactly that most of the time, you ended up shoehorning functionality into different lifecycle methods, which made them much harder to reason about. Most of the time, for anything more complex than just performing the initial databinding, you'd just be looking at the lifecycle chart and trying to figure out which place would be best to put which part of your code. Page_Init? Page_Load? Page_PreRender? I remember the pain of trying to add dynamic controls to a site right in time before ViewState was hydrated but AFTER something else had happened. I agree that for the easiest of use cases, lifecycle methods make sense. But you very quickly leave that comfortable zone and then it just becomes painful and confusing.
      - 7777fps 6y ago
        Don't worry, I'm not espousing lifecycles as a panacea or solution for the modern programmer, I just wanted to share that experience with lifecycle methods meant that I was less tripped up by the pitfalls of react lifecycles. Less so than I've been tripped up by react hooks certainly so it's been a surprise that many here are describing them as being much easier and simpler than classes. Classes had limits and some pitfalls but it's been frustrating that lifecycle methods have been retired and deprecated because sometimes they felt like the natural place to do something.
- superice 6y ago
  The biggest difference is that the class based components are an older iteration of the API into React, one that lies closer with how React internally works (or worked), but one that is not necessarily useful for writing correctly working components. Say you have a component that renders some data it fetches from the backend, and it received the ID via a prop. In a class based component you might be inclined to write the fetching logic in the componentDidMount or maybe the constructor. However, if you change the ID you feed the component, the component will update instead of being recreated. In the naive class based version it won't refetch the data, and won't behave correctly. With useEffect hooks you don't really care anymore, you can reason about side effects in the same declarative way. You express the fact that fetching new data is a dependency of the prop changing, which holds true both on first render and later on update. The hooks API fixed a handful of these 'mistakes' that were still present in the class based API. I agree that the syntax might look awkward at first, but the hooks API is much better thought out than the class based one. (Some anecdata: almost any component that I rewrote in hooks-style has been halved in number of lines of code, the concepts have been much less spread out over the file. See this tweet for an example: https://twitter.com/threepointone/status/1056594421079261185 https://twitter.com/threepointone/status/1056594421079261185)
- conmigo 6y ago
  Hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc.. What's maybe the most stupid thing about hooks is that it's overruling the const type declaration: const [count, setCount] = useState(0); You think count is a const? Not with hooks, because hooks are f!@#ng with your core language rules! And all those React + Hooks + Typescript fanatics that live in their type safe bubble fail to even notice it! Even Typescript doesn't complain about it.. Hooks make React a f'ing joke, they've given Dan way too much freedom at FB, IMAO.
  - arvinsim 6y ago
    const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change. const is not "constant". In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.
    - conmigo 6y ago
      > It's not for assuring that variable cannot change. Please tell me how you'd change a to 1 in this example: const a = 0;
      - sunaurus 6y ago
        You can't do that. Just like you can't do: const [count, setCount] = useState(0); count = 1; In both cases, const is const. The fact that `setState` modifies state outside of the local scope does not mean that a local variable is not const. This is really basic programming, it doesn't have anything to do with React. Here's the exact same scenario without React to show why you're wrong in your original comment: const foo = () => { const bar = getBarFromDatabase(); } Imagine that this is a typical database where values can change, so that every time `foo()` is called, `bar` can have a different value. Do you think that this is a dirty hack that is overruling the const type declaration as well?
- cwhiz 6y ago
  Class components feel like a spaghetti mess to me whereas Hooks are obvious, straightforward, and clean. I understand that others feel differently but I personally cannot stand working with class components.
rubyn00bie 6y ago
tldr; React is a view renderer. It renders views. Getting data to and from those views not included. Navigation? Not included. Persistence? Not included. Styling? Not included. Why? It's just a view renderer, that is to say, it renders templates. When the only thing your application shares with its dependencies is its view renderer, you're going to feel a lot of pain. This is one of the big reasons why I use Ember.js for complex web-frontends (though holla to phoenix live views). It's a framework-- it has all them pieces you need included in a sane way that's consistent. Just my two cents... P.S. If you write JavaScript UI code, and you want to like be better at it, go write native UI code. You'll learn soooo god damn much, write better JS, and understand a lot more about what the fuck all these pieces (like react) are actually doing (rendering UI, managing state, networking etc) in a sane curated (thanks Googs, Microsofties, and Apples) way.
- Scarblac 6y ago
  Except that it's not only a view renderer, it reacts to changes in state, and it has ways to do stateful thing after a component is rendered or stops being rendered or at other times. And in practice some state is specific to some component or group of components and some state is global or the group of components doesn't translate to a subtree of HTML's tree structure. Also the kind of thing that has to happen based on what happens in the app is often deeply async. And it all becomes a mess. But it's still not as bad as a mess as without React, I believe at this moment.
- ibero 6y ago
  agreed. using ember has been instrumental in getting my projects up and running quickly, and then, maintaining them as they grow from mvp to enterprise level.
dvt 6y ago
(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior. "Everything an HTML tag" is an insane mantra to have. As author points out, what in the world does a <Query> tag even do? It might make sense to us because we're used to it now, but the semantics of a tag is completely lost in this "new way" of using them (don't call it declarative because that's not what it technically is; it's markup). These days I'm creating HOCs on top of HOCs to support different behavior (from redux stores, to authentication HOCs, to "don't render this thing on the server" async components). It's, simply put, a terrible idea. And everyone just bought into it because the guys at Facebook must be really smart. The lifecycle hooks are just confusing and unnecessary. They are side-effects of over-engineering. And to add insult to injury, they change every few versions (so old code will inevitably break on new React versions). SSR. I've brought this point up on HN before, but doing server-side rendering in React is absolutely ridiculous. Every time I need to implement it, I'm constantly battling async stuff, state management, webpack/babel, hot module reloading issues, shimming `window` or `document` on the server side, etc. Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing. It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.
- veeralpatel979 6y ago
  I love reading about people's first principles technqiues of different technologies on HN! What do you think React will be supplanted by?
  - onlydeadheroes 6y ago
    jQuery, when people stop fucking around and start making sites that work again.
  - Thorncorona 6y ago
    I've gotten by using a templating engine like Handlebars along with jQuery for async behavior for pretty much all of my apps. Reduced the time I spent building UIs a huge amount. There are actually very few websites that 'require' an app-in-browser experience. And for many of those, clever usage of jQuery plugins works well enough.
zappo2938 6y ago
To understand React, it is important to understand the difference between imperative and declarative coding. [0] React is a way to write declarative code that use life cycle hooks or effects to do imperative "stuff". The best explanation oh how useEffect works is by Dan Abramov [1] It is also worth reading his article on React as a UI Runtime as it is a good explanation of React conceptually under the hood. [0] https://courses.reacttraining.com/courses/250055/lectures/3897343 https://courses.reacttraining.com/courses/250055/lectures/38... (Can sign in for free to watch this one video.) [1] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/
- andrewstuart 6y ago
  This is a critical point to understand. If you're not doing declarative programming with React then you're swimming upstream. Problem is that the concept of declarative programming would be very difficult to get beginners to grasp. Once you grasp it though, it's absolutely incredibly powerful and importantly - simple. And this is where React loses beginners who jump to more intuitive programming models.
  - radiator 6y ago
    Are you implying that only beginners can dislike React?
  - 7777fps 6y ago
    But that's great until it isn't. You can design all the declarative things you want, but someone will eventually come up with a requirement that doesn't appear to fit a declarative structure, such as an event that fires 2 seconds after something else happens. And so to resolve that you can construct state machines with transition states to get back to a declarative model, but those state machines can quickly become a bigger headache to maintain (yes, even with redux) than if you'd just been able to setTimeout from the component in the first place. And you start with the best of intentions of re-usable components but find more things that ought to be owned by the component pushed up to the store and suddenly there isn't a neatly re-usable component but an empty shell of something that still needs the other half plumbed in manually every time. I love the idea that you can abstract everything happening in an application to state and render reproducibly from that, but the reality is that it's really hard and time-expensive to do compared to jquery. But that would be fine if the tooling was there. If React had a CLI like the AngularCLI it wouldn't be such a problem to add new actions, or new pieces of state, or new components. But it doesn't, so each new component ends up adding a little more state into the state machine which ends up breaking types in far off places. Now there's probably an assumption about how state is built up or how reducers are typed or how actions are defined that I'm missing some reason why this shouldn't be happening. But it is happening, it's the reality for the project I've been working on and it's a real headache.
cryptica 6y ago
>> React is a library, not a framework They say it often but it's not true. React forces you into an entire workflow with JSX, bundling, source mapping, babel transpilation and often restricts you to using components that are designed specifically for React; accessing the raw DOM is nasty business. If it was a library, it would not hijack the DOM and override it with its own; that fact alone is more than enough to call it a framework. Any tool which takes over the execution environment is a framework by definition. A library is something you use, a framework is something you work inside. You could argue that react could be used to target only specific components but this would be missing the point that 99.9% of the time, React is not used like this; as soon as you have a hierarchy of components, it's a framework, not a library.
- robjan 6y ago
  You don't need to use JSX in order to use React; it's just syntactic sugar. https://reactjs.org/docs/react-api.html#createelement https://reactjs.org/docs/react-api.html#createelement
  - ergo14 6y ago
    And who uses react without JSX at any scale?
genezeta 6y ago
React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework. It's not a complete Application Framework, sure, and you may mix it with other stuff. In fact, you will generally mix it with other stuff. But I don't think that the difference library vs framework lies in providing for all of the aspects of the application or just for some parts of it. In this particular case, the author seems to have overstepped that somewhat, saying "With a framework, you’re essentially given all the materials to build that house, and it’s up to you in what arrangement you put them in." And in there lies the problem. That is not a framework. That's Home Depot. A framework does indeed tell you in what arrangement you're supposed to put the materials. It's in fact this that makes it a framework. It gives you structure. Or at least, the basis for the structure. You put your materials into the arrangement the framework suggests. React is only concerned with UI, sure. But then again it does give you quite a bit of structure. It does tell you how you're supposed to arrange and build your UI. You extend this class with these methods, or you create this kind of function using these functions in this way. You put your rendering here, and return it in this way... and then the framework will run it. What is correct is that React is for UI. So, sure, it will not tell you how you should do your API calls. But not because it's not a framework, but because API calls are not a UI concern.
- capableweb 6y ago
  I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as both. If you ever call `ReactDOM.render()` just once and then live in React land, with all the lifecycle hooks and whatnot, you're essentially treating React as a framework, as React calls everything after the first initialize. If you call `ReactDOM.render` in multiple places or have something around that handles that for you, then you're using React as a library.
valera_rozuvan 6y ago
If you look at it from one side, React doesn't have technical problems or the way it's built. If you look at it from another side - React opens up a wide range of possibilities - you can simply drown in them. Adequate things you have done all your life - suddenly feel not so adequate anymore :) For example, it would be fine to use plain old CSS, but with React it just feels wrong. If you look at the number of libraries that try to evolve CSS, there are many. But there is just no winner in sight. Pretty much the same situation is happening in state handling. The number of possibilities! It's amazing. Eventually, though, something gains momentum, like Redux did. This has consequences for React ecosystem, but also everywhere else in JS world. It slowly migrates to Angular, and other frameworks - as the cool kid on the block. Elegant, simple concepts of React - they are outweighed by the environment they live in. React allows for rapid prototyping, provokes ideas which sometimes break traditional ways. Anyways, I will leave these thoughts with saying that personally I don't have issues with it. I adapt React to what I want - it doesn't adapt my thinking ;)
gherkinnn 6y ago
A nice side effect of the article: by reading the inverse of it, I get a better understanding of Angular which I haven't used since 1.x.
pjmlp 6y ago
The more I read about React, the happier I am to use VanilaJS alongside SSR and web components friendly frameworks.
- DeathArrow 6y ago
  I can agree. I'd take a bit of SSR and JS + jQuery any day over big and heavy JS frameworks. Even if I'd write the backend as an API without no SSR, I would prefer to write the frontend in HTML + CSS + vanilla JS + jQuery. It feels more intuitive to me as there are no abstractions to complicate things, no opinionated framework to force me do things its predefined way.
- aylmao 6y ago
  You should try to use it too! If you discover you don't like anything about it, all the better, you can say you've experienced it and not just read about it. If you happen to like at least parts of it, you've just expanded your knowledge and arsenal of tools for UI development.
  - pjmlp 6y ago
    But I have, it just had a different name, https://www.bitquabit.com/post/the-more-things-change/ https://www.bitquabit.com/post/the-more-things-change/ https://wiki.haskell.org/Functional_Reactive_Programming https://wiki.haskell.org/Functional_Reactive_Programming
  - doublerabbit 6y ago
    I just can't get myself around to use anything by FANG just due to their licenses. Using a framework means your project will never purely be yours. React license: > The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.
DeathArrow 6y ago
I'd rather use no JS framework at all. But, if forced to use one, I'd pick Vue, as that seems the less opinionated and simple framework.
- redis_mlc 6y ago
  Writing Vanilla-JS as we speak - don't be jealous! :)
dvcrn 6y ago
I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class components only to learn that hooks are now a thing and they remove a lot of boilerplate code. Even with redux, redux supports hooks as well so you can scrap that entire connect() stuff alltogether. Just back to simple function components.
- jchw 6y ago
  It’s the price of success. Similarly, a lot of people now vehemently hate Go, and in a few years they’ll be complaining about the problems with Rust. (No idea about frontend because as far as I’m concerned React is still on top.) I don’t think it’s really too big of a deal, but I wish people would be more realistic and use less hyperbole. Everything has trade-offs, one’s own personal honey moon ending does not mean we were all blind and/or ignoring the faults with things.
  - saagarjha 6y ago
    I don’t think it’s necessarily success, but novelty. C++ and Java are immensely popular and get nowhere near the vitriol that the thing you mentioned do. Often there’s a number of people on the opposite side cheerleading the thing as well, which underlines the apparent conflict. (Rust is already being complained about, by the way.)
    - christophilus 6y ago
      Really? I would have put C++ and Java near the top of the “most ridiculed languages” list.
      - majewsky 6y ago
        As the old mantra goes, "there are two types of languages, the ones that everyone complains about, and the ones that nobody uses".
AJRF 6y ago
React is a framework though, not a library. I don't mean to be disparaging but this is an article about how someone thought react was one thing, found it was another and then wrote a post of random tidbits about things in react you could learn from its homepage?
- karatestomp 6y ago
  React's marketing (such as it is) has pushed the "it's just a library" and "it's just the V in MVC" hard. I think folks can be forgiven for thinking those notions won't entirely fail to describe the real world experience and use of React in ~100% of actual projects (and even more so now that ditching legitimately-actually-quite-portable Redux for hook-centric logic is trendy) and being a more than a little surprised and perplexed when they do.
andrewstuart 6y ago
I love React. In fact I recently gave plain vanilla JavaScript a go and it was so painful that I was glad to get back to React's way of organising a large application. I don't use Redux or server side rendering - they're not needed. The only thing that I think it should do differently is leave styles to be handled natively.
- Vinnl 6y ago
  That's perfectly possible in React; I've done that to great satisfaction in a number of projects :)
- ncallaway 6y ago
  You absolutely can, and I almost always do, styles things with native css (well, I use sass compiled to css) to style your react application (or widget!). To my knowledge, React itself has no opinion on styling. It's more the ecosystem around React that's gone css-in-js. But, yes, if you want to do your styling natively that's really not a problem.
- gitgud 6y ago
  Well, for me it was the opposite. Trying vanilla js was empowering! There was no; tool chain, bundling, virtual DOM, render function, countless layers of library abstraction, sourcemaps, node_modules... etc. Just a simple index.html file Some projects don't require a state of the art virtual-DOM-diffing-machine, just to display a list of ToDo items...
choicenotchance 6y ago
Compared to React, can anyone tell me how Vue is? Should I give it a try for my next big project (freelance)?
ivanstame 6y ago
Do you wish you knew VueJS? :D
pferdone 6y ago
tldr; RTFM
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]
tarkin2 6y ago
React isn't a library. You can't drop a bit of it into your project. It distorts how you build the webapp. jQueryUI is a library. You can add it in and your code is still vaguely the same. React is a framework pretending to be a library so people can't say "Oh, what? another framework?" As soon as you use React, you're in the react universe, not the normal webdev universe. With a normal webapp, I can just import an external js library. With react, I must look for projects that translate those library into the react universe (react-bootstrap etc).
- skrtskrt 6y ago
  You can just add the bootstrap CDN in the head of your index.html and use bootstrap without installing ‘react-bootstrap’ (I don’t disagree with anything else you said)
  - gvjddbnvdrbv 6y ago
    Not if you want to use e.g. Bootstrap models without a lot of work.
  - tarkin2 6y ago
    If you want to use the javascript components, rather than just the styles, you need the react library version. There are various other UI libraries as well that require you use the react conversion library, which sadly lag behind the vanilla js versions. Fair enough if you love react then this is acceptable. But it pushes the definition of a library, when just using react means that other libraries need to conform to react to properly work with it. React does some things nicely. But it's not "It's just a library. Drop it into your existing project. And you're done."
jarym 6y ago
I write a lot of enterprise apps and I’ve seen many many frameworks come and go over the years. I personally am not impressed with React and don’t get what all the fuss is about. We’ve had Angular, jQuery and a whole bunch of stuff over the years and each one managed to become a ‘a thing’ for a while
- koonsolo 6y ago
  React introduced a whole new way of writing GUI's. I come from a game development background, and there we had Immediate GUI's for some time now (https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutorial-part-1/ https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutor...). React basically translates this concept to the web, and does some optimizations to not rebuild the entire DOM from scratch, and only rebuild when state changes and not every frame. Writing a 'render function' is simpler and easier than building a structure of widgets and letting them handle events. (I like simple and easy) Anyway, it seems both react and flutter are also gaining on the mobile apps developments, and web developers are very happy using React. Of course frameworks come and go, but React introduced a shift of mind when programming GUI's.
  - buboard 6y ago
    > React introduced a whole new way What will happen to this way when React is "outroduced" ?
    - koonsolo 6y ago
      Flutter uses the same concept, and it probably won't be the last. But who knows, things go really fast in the web world.
  - jarym 6y ago
    React introduced this concept ‘to you’ perhaps but it wasn’t the first. The framework I used has been doing this in the very early 2000s. Don’t get me wrong it has a lot to like about it - but the only revolution is that Facebook’s might propelled this in the minds of developers all over.
programmarchy 6y ago
Off topic, but the yellow border on the page kept drawing my eyes away from the text to the edge of the screen.
c-smile 6y ago
Big picture: React (especially with JSX) can be thought as PHP running on client side. We can replace mentally any <div> or <span> on the page with <iframe src="someScriptFunction()"/>. When the application state (fuzzy term but still) changes we request these content generating functions to re-execute. The VDOM is just an implementation detail - agreement on what these someScriptFunction()'s shall return. Conceptually they may return just html and so we can use: function onDataModelChange(model) { element.html = provideHtmlRenderingOf(model); } can be used instead of reconciliation (diffing). Performance of such updates will be the same, if not better than React's, BTW. The only problem of element.html = ... approach is that such updates will loose runtime state. For example, if you have <textarea> replaced that way you will loose its current editing state - undo/redo stack, caret positioning, etc. So VDOM and reconciliation mechanism is a palliative - to do not loose runtime states on updates. But, again, it is not a panacea. Think about <div contenteditable/> based editors, their content cannot be reactive in principle. That update-only-what-is-needed reasoning frequently used by React people to promote "speed" hypothesis is a bit misleading - it was introduced for different reasons really.
temporallobe 6y ago
I tried React and hated it, especially JSX, but I made some decent money working on React projects in the past. I much prefer libraries/frameworks where the view is completely separate and is more “pure” HTML. I ended up creating my own framework that was much easier to understand and manage, but is obviously not generic enough to publish. Maybe one day I’ll clean it up and push it to a Github repo, but then again, does the world need yet another MVC framework? I think not.
- hombre_fatal 6y ago
  > I ended up creating my own framework that was much easier to understand and manage, but is obviously not generic enough to publish. You lost me there. Cute for a solo/learning project, but when other people are touching the project or you're trying to build a business, you have to answer for why your project was so special that it needed its own ad hoc framework. As opposed to, say, a framework with real documentation. Or one with an ecosystem so you can escape this culture of NIH. When I hear someone building their own JS framework, I see someone who wanted to procrastinate the hard part (building a business, shipping a product, appealing to users). Like when game developers decide to build an engine and never make the game, aka the hard part (https://www.voxelquest.com/ https://www.voxelquest.com/).
  - temporallobe 6y ago
    Gatekeeping much?
- petilon 6y ago
  You could use an existing MVC framework such as this one: https://github.com/theabdulbari/mvc-router https://github.com/theabdulbari/mvc-router
peter_d_sherman 6y ago
Excerpt: "The way I like to think of it in comparison to Angular is this: Angular is a framework for architecting and building applications. It, for the most part, doesn’t change the way you write your HTML or CSS, but it heavily controls the way you write Javascript. React, on the other hand, is a library for building user interfaces. It, for the most part, doesn’t change the way you write Javascript that isn’t directly related to your UI, but it heavily controls the way you write HTML and CSS (or the equivalent of it). And this brings me to the next point…"

236 points by ire 6y ago

Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.

foota 6y ago
Imo, hooks present an API that is much less difficult to internalize, but maybe holds your hand less? I used react for a few months on a sideish project and had trouble knowing which component method I needed for something, whereas with react now it's all covered by hooks.
awestroke 6y ago
No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.
- batiste 6y ago
  Would it be possible to have a single method on a class that behaves like whatever useEffect is doing?
  - lindskogen 6y ago
    Not in a single method, no. Watch this talk for more details! https://www.youtube.com/watch?v=wXLf18DsV-I https://www.youtube.com/watch?v=wXLf18DsV-I
    - batiste 6y ago
      Well, I did something a bit similar my own language: https://github.com/batiste/blop-language/commit/90e7704e125ffb3c1fe6b4de2446680d3819ab7e https://github.com/batiste/blop-language/commit/90e7704e125f... Not sure where classes are an issue with doing anything like this
- TechBro8615 6y ago
  Adding to this, hooks make it much easier to pull related state management code out of the component. They help make state logic just as composable as UI logic.
fabian2k 6y ago
My superficial understanding is that React components as classes are far more complicated than they might seem at first. You're not in control of creating the class instances, rendering them or destroying them. React is in control of that. The constructor is the wrong place for data fetching in React class components as far as I remember anyway. I don't remember the exact reason, but it always has been somewhat non-obvious and you always needed to understand the React lifecycle to avoid bugs in that kind of code.
ng12 6y ago
> And anyone who has used classes in Java or other languages would feel at home. Not really because there's nothing object oriented about React.Component. It's just a wrapper for a function implemented as a class.
- cmckn 6y ago
  THIS is what I wish I knew about React. As a Java user, I made incredibly wrong and damaging assumptions because "classes, I know what these are"! I still can't make heads or tails of hooks, but in due time!
deviantfero 6y ago
I've worked with both extensively, hooks are way easier to grasp, they allow you to avoid numerous ifs and comparing manually to previous states, you can separate actions according to what properties you're listening changes on, which would be cobbled together in a traditional life-cycle method, and the best part? They can be reused between components
Bahamut 6y ago
In my 1.5 years or so of using hooks, I'm finding components with hooks subtly more buggy than their class counterparts - there are a lot of gotchas with that dependency array for hooks, I have encountered nasty bugs both with explicitly declaring all of the dependencies in the array and declaring less than them. It is much easier to accidentally create infinite loops with useEffect that you would never create with class components, and some of the code you write turns out to be more verbose and less expressive, such as when trying to diff previous and current values of state & needing to create extra state variables with useState for each such value you need to react on. Hooks seem very appealing at first (I lean more FP than OOP in general), but the bugs and slipshod initial rollout out of beta really does not inspire much confidence. Even today I still encounter weird issues.
efdee 6y ago
Classes in React are confusing because they aren't actually classes, just something shoehorned into classes. For example you wouldn't write your initialization code in the constructor, you would do it in componentDidMount. Classes in React generate false expectations.
- 7777fps 6y ago
  I liked that model because as an ASP webforms developer the class lifecycle is easy to reason about, like a page lifecycle. In ASP you wouldn't put initialisation code in the page constructor either, it would go in Page_Init, Page_Load, etc. Of course the tooling there made it both easier to put in the right place and harder to edit the page constructor to stick it in the wrong place.
  - efdee 6y ago
    I remember ASP.NET Webforms, and the reason most of the community moved towards MVC-ish frameworks is exactly that most of the time, you ended up shoehorning functionality into different lifecycle methods, which made them much harder to reason about. Most of the time, for anything more complex than just performing the initial databinding, you'd just be looking at the lifecycle chart and trying to figure out which place would be best to put which part of your code. Page_Init? Page_Load? Page_PreRender? I remember the pain of trying to add dynamic controls to a site right in time before ViewState was hydrated but AFTER something else had happened. I agree that for the easiest of use cases, lifecycle methods make sense. But you very quickly leave that comfortable zone and then it just becomes painful and confusing.
    - 7777fps 6y ago
      Don't worry, I'm not espousing lifecycles as a panacea or solution for the modern programmer, I just wanted to share that experience with lifecycle methods meant that I was less tripped up by the pitfalls of react lifecycles. Less so than I've been tripped up by react hooks certainly so it's been a surprise that many here are describing them as being much easier and simpler than classes. Classes had limits and some pitfalls but it's been frustrating that lifecycle methods have been retired and deprecated because sometimes they felt like the natural place to do something.
superice 6y ago
The biggest difference is that the class based components are an older iteration of the API into React, one that lies closer with how React internally works (or worked), but one that is not necessarily useful for writing correctly working components. Say you have a component that renders some data it fetches from the backend, and it received the ID via a prop. In a class based component you might be inclined to write the fetching logic in the componentDidMount or maybe the constructor. However, if you change the ID you feed the component, the component will update instead of being recreated. In the naive class based version it won't refetch the data, and won't behave correctly. With useEffect hooks you don't really care anymore, you can reason about side effects in the same declarative way. You express the fact that fetching new data is a dependency of the prop changing, which holds true both on first render and later on update. The hooks API fixed a handful of these 'mistakes' that were still present in the class based API. I agree that the syntax might look awkward at first, but the hooks API is much better thought out than the class based one. (Some anecdata: almost any component that I rewrote in hooks-style has been halved in number of lines of code, the concepts have been much less spread out over the file. See this tweet for an example: https://twitter.com/threepointone/status/1056594421079261185 https://twitter.com/threepointone/status/1056594421079261185)
conmigo 6y ago
Hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc.. What's maybe the most stupid thing about hooks is that it's overruling the const type declaration: const [count, setCount] = useState(0); You think count is a const? Not with hooks, because hooks are f!@#ng with your core language rules! And all those React + Hooks + Typescript fanatics that live in their type safe bubble fail to even notice it! Even Typescript doesn't complain about it.. Hooks make React a f'ing joke, they've given Dan way too much freedom at FB, IMAO.
- arvinsim 6y ago
  const is for assuring that the variable is never reassigned. It's not for assuring that variable cannot change. const is not "constant". In any case, in the useState hooks, if the value is changed via the set function, the component will be diffed and re-rendered. There is no value change happening while it is running in that scope.
  - conmigo 6y ago
    > It's not for assuring that variable cannot change. Please tell me how you'd change a to 1 in this example: const a = 0;
    - sunaurus 6y ago
      You can't do that. Just like you can't do: const [count, setCount] = useState(0); count = 1; In both cases, const is const. The fact that `setState` modifies state outside of the local scope does not mean that a local variable is not const. This is really basic programming, it doesn't have anything to do with React. Here's the exact same scenario without React to show why you're wrong in your original comment: const foo = () => { const bar = getBarFromDatabase(); } Imagine that this is a typical database where values can change, so that every time `foo()` is called, `bar` can have a different value. Do you think that this is a dirty hack that is overruling the const type declaration as well?
cwhiz 6y ago
Class components feel like a spaghetti mess to me whereas Hooks are obvious, straightforward, and clean. I understand that others feel differently but I personally cannot stand working with class components.

rubyn00bie 6y ago

tldr; React is a view renderer. It renders views. Getting data to and from those views not included. Navigation? Not included. Persistence? Not included. Styling? Not included. Why? It's just a view renderer, that is to say, it renders templates. When the only thing your application shares with its dependencies is its view renderer, you're going to feel a lot of pain. This is one of the big reasons why I use Ember.js for complex web-frontends (though holla to phoenix live views). It's a framework-- it has all them pieces you need included in a sane way that's consistent. Just my two cents... P.S. If you write JavaScript UI code, and you want to like be better at it, go write native UI code. You'll learn soooo god damn much, write better JS, and understand a lot more about what the fuck all these pieces (like react) are actually doing (rendering UI, managing state, networking etc) in a sane curated (thanks Googs, Microsofties, and Apples) way.

Scarblac 6y ago
Except that it's not only a view renderer, it reacts to changes in state, and it has ways to do stateful thing after a component is rendered or stops being rendered or at other times. And in practice some state is specific to some component or group of components and some state is global or the group of components doesn't translate to a subtree of HTML's tree structure. Also the kind of thing that has to happen based on what happens in the app is often deeply async. And it all becomes a mess. But it's still not as bad as a mess as without React, I believe at this moment.
ibero 6y ago
agreed. using ember has been instrumental in getting my projects up and running quickly, and then, maintaining them as they grow from mvp to enterprise level.

dvt 6y ago

(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior. "Everything an HTML tag" is an insane mantra to have. As author points out, what in the world does a <Query> tag even do? It might make sense to us because we're used to it now, but the semantics of a tag is completely lost in this "new way" of using them (don't call it declarative because that's not what it technically is; it's markup). These days I'm creating HOCs on top of HOCs to support different behavior (from redux stores, to authentication HOCs, to "don't render this thing on the server" async components). It's, simply put, a terrible idea. And everyone just bought into it because the guys at Facebook must be really smart. The lifecycle hooks are just confusing and unnecessary. They are side-effects of over-engineering. And to add insult to injury, they change every few versions (so old code will inevitably break on new React versions). SSR. I've brought this point up on HN before, but doing server-side rendering in React is absolutely ridiculous. Every time I need to implement it, I'm constantly battling async stuff, state management, webpack/babel, hot module reloading issues, shimming `window` or `document` on the server side, etc. Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing. It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.

veeralpatel979 6y ago
I love reading about people's first principles technqiues of different technologies on HN! What do you think React will be supplanted by?
- onlydeadheroes 6y ago
  jQuery, when people stop fucking around and start making sites that work again.
- Thorncorona 6y ago
  I've gotten by using a templating engine like Handlebars along with jQuery for async behavior for pretty much all of my apps. Reduced the time I spent building UIs a huge amount. There are actually very few websites that 'require' an app-in-browser experience. And for many of those, clever usage of jQuery plugins works well enough.

zappo2938 6y ago

To understand React, it is important to understand the difference between imperative and declarative coding. [0] React is a way to write declarative code that use life cycle hooks or effects to do imperative "stuff". The best explanation oh how useEffect works is by Dan Abramov [1] It is also worth reading his article on React as a UI Runtime as it is a good explanation of React conceptually under the hood. [0] https://courses.reacttraining.com/courses/250055/lectures/3897343 https://courses.reacttraining.com/courses/250055/lectures/38... (Can sign in for free to watch this one video.) [1] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/

andrewstuart 6y ago
This is a critical point to understand. If you're not doing declarative programming with React then you're swimming upstream. Problem is that the concept of declarative programming would be very difficult to get beginners to grasp. Once you grasp it though, it's absolutely incredibly powerful and importantly - simple. And this is where React loses beginners who jump to more intuitive programming models.
- radiator 6y ago
  Are you implying that only beginners can dislike React?
- 7777fps 6y ago
  But that's great until it isn't. You can design all the declarative things you want, but someone will eventually come up with a requirement that doesn't appear to fit a declarative structure, such as an event that fires 2 seconds after something else happens. And so to resolve that you can construct state machines with transition states to get back to a declarative model, but those state machines can quickly become a bigger headache to maintain (yes, even with redux) than if you'd just been able to setTimeout from the component in the first place. And you start with the best of intentions of re-usable components but find more things that ought to be owned by the component pushed up to the store and suddenly there isn't a neatly re-usable component but an empty shell of something that still needs the other half plumbed in manually every time. I love the idea that you can abstract everything happening in an application to state and render reproducibly from that, but the reality is that it's really hard and time-expensive to do compared to jquery. But that would be fine if the tooling was there. If React had a CLI like the AngularCLI it wouldn't be such a problem to add new actions, or new pieces of state, or new components. But it doesn't, so each new component ends up adding a little more state into the state machine which ends up breaking types in far off places. Now there's probably an assumption about how state is built up or how reducers are typed or how actions are defined that I'm missing some reason why this shouldn't be happening. But it is happening, it's the reality for the project I've been working on and it's a real headache.

cryptica 6y ago

>> React is a library, not a framework They say it often but it's not true. React forces you into an entire workflow with JSX, bundling, source mapping, babel transpilation and often restricts you to using components that are designed specifically for React; accessing the raw DOM is nasty business. If it was a library, it would not hijack the DOM and override it with its own; that fact alone is more than enough to call it a framework. Any tool which takes over the execution environment is a framework by definition. A library is something you use, a framework is something you work inside. You could argue that react could be used to target only specific components but this would be missing the point that 99.9% of the time, React is not used like this; as soon as you have a hierarchy of components, it's a framework, not a library.

robjan 6y ago
You don't need to use JSX in order to use React; it's just syntactic sugar. https://reactjs.org/docs/react-api.html#createelement https://reactjs.org/docs/react-api.html#createelement
- ergo14 6y ago
  And who uses react without JSX at any scale?

genezeta 6y ago

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework. It's not a complete Application Framework, sure, and you may mix it with other stuff. In fact, you will generally mix it with other stuff. But I don't think that the difference library vs framework lies in providing for all of the aspects of the application or just for some parts of it. In this particular case, the author seems to have overstepped that somewhat, saying "With a framework, you’re essentially given all the materials to build that house, and it’s up to you in what arrangement you put them in." And in there lies the problem. That is not a framework. That's Home Depot. A framework does indeed tell you in what arrangement you're supposed to put the materials. It's in fact this that makes it a framework. It gives you structure. Or at least, the basis for the structure. You put your materials into the arrangement the framework suggests. React is only concerned with UI, sure. But then again it does give you quite a bit of structure. It does tell you how you're supposed to arrange and build your UI. You extend this class with these methods, or you create this kind of function using these functions in this way. You put your rendering here, and return it in this way... and then the framework will run it. What is correct is that React is for UI. So, sure, it will not tell you how you should do your API calls. But not because it's not a framework, but because API calls are not a UI concern.

capableweb 6y ago
I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as both. If you ever call `ReactDOM.render()` just once and then live in React land, with all the lifecycle hooks and whatnot, you're essentially treating React as a framework, as React calls everything after the first initialize. If you call `ReactDOM.render` in multiple places or have something around that handles that for you, then you're using React as a library.

valera_rozuvan 6y ago

If you look at it from one side, React doesn't have technical problems or the way it's built. If you look at it from another side - React opens up a wide range of possibilities - you can simply drown in them. Adequate things you have done all your life - suddenly feel not so adequate anymore :) For example, it would be fine to use plain old CSS, but with React it just feels wrong. If you look at the number of libraries that try to evolve CSS, there are many. But there is just no winner in sight. Pretty much the same situation is happening in state handling. The number of possibilities! It's amazing. Eventually, though, something gains momentum, like Redux did. This has consequences for React ecosystem, but also everywhere else in JS world. It slowly migrates to Angular, and other frameworks - as the cool kid on the block. Elegant, simple concepts of React - they are outweighed by the environment they live in. React allows for rapid prototyping, provokes ideas which sometimes break traditional ways. Anyways, I will leave these thoughts with saying that personally I don't have issues with it. I adapt React to what I want - it doesn't adapt my thinking ;)

gherkinnn 6y ago

A nice side effect of the article: by reading the inverse of it, I get a better understanding of Angular which I haven't used since 1.x.

pjmlp 6y ago

The more I read about React, the happier I am to use VanilaJS alongside SSR and web components friendly frameworks.

DeathArrow 6y ago
I can agree. I'd take a bit of SSR and JS + jQuery any day over big and heavy JS frameworks. Even if I'd write the backend as an API without no SSR, I would prefer to write the frontend in HTML + CSS + vanilla JS + jQuery. It feels more intuitive to me as there are no abstractions to complicate things, no opinionated framework to force me do things its predefined way.
aylmao 6y ago
You should try to use it too! If you discover you don't like anything about it, all the better, you can say you've experienced it and not just read about it. If you happen to like at least parts of it, you've just expanded your knowledge and arsenal of tools for UI development.
- pjmlp 6y ago
  But I have, it just had a different name, https://www.bitquabit.com/post/the-more-things-change/ https://www.bitquabit.com/post/the-more-things-change/ https://wiki.haskell.org/Functional_Reactive_Programming https://wiki.haskell.org/Functional_Reactive_Programming
- doublerabbit 6y ago
  I just can't get myself around to use anything by FANG just due to their licenses. Using a framework means your project will never purely be yours. React license: > The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.

DeathArrow 6y ago

I'd rather use no JS framework at all. But, if forced to use one, I'd pick Vue, as that seems the less opinionated and simple framework.

redis_mlc 6y ago
Writing Vanilla-JS as we speak - don't be jealous! :)

dvcrn 6y ago

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class components only to learn that hooks are now a thing and they remove a lot of boilerplate code. Even with redux, redux supports hooks as well so you can scrap that entire connect() stuff alltogether. Just back to simple function components.

jchw 6y ago
It’s the price of success. Similarly, a lot of people now vehemently hate Go, and in a few years they’ll be complaining about the problems with Rust. (No idea about frontend because as far as I’m concerned React is still on top.) I don’t think it’s really too big of a deal, but I wish people would be more realistic and use less hyperbole. Everything has trade-offs, one’s own personal honey moon ending does not mean we were all blind and/or ignoring the faults with things.
- saagarjha 6y ago
  I don’t think it’s necessarily success, but novelty. C++ and Java are immensely popular and get nowhere near the vitriol that the thing you mentioned do. Often there’s a number of people on the opposite side cheerleading the thing as well, which underlines the apparent conflict. (Rust is already being complained about, by the way.)
  - christophilus 6y ago
    Really? I would have put C++ and Java near the top of the “most ridiculed languages” list.
    - majewsky 6y ago
      As the old mantra goes, "there are two types of languages, the ones that everyone complains about, and the ones that nobody uses".

AJRF 6y ago

React is a framework though, not a library. I don't mean to be disparaging but this is an article about how someone thought react was one thing, found it was another and then wrote a post of random tidbits about things in react you could learn from its homepage?

karatestomp 6y ago
React's marketing (such as it is) has pushed the "it's just a library" and "it's just the V in MVC" hard. I think folks can be forgiven for thinking those notions won't entirely fail to describe the real world experience and use of React in ~100% of actual projects (and even more so now that ditching legitimately-actually-quite-portable Redux for hook-centric logic is trendy) and being a more than a little surprised and perplexed when they do.

andrewstuart 6y ago

I love React. In fact I recently gave plain vanilla JavaScript a go and it was so painful that I was glad to get back to React's way of organising a large application. I don't use Redux or server side rendering - they're not needed. The only thing that I think it should do differently is leave styles to be handled natively.

Vinnl 6y ago
That's perfectly possible in React; I've done that to great satisfaction in a number of projects :)
ncallaway 6y ago
You absolutely can, and I almost always do, styles things with native css (well, I use sass compiled to css) to style your react application (or widget!). To my knowledge, React itself has no opinion on styling. It's more the ecosystem around React that's gone css-in-js. But, yes, if you want to do your styling natively that's really not a problem.
gitgud 6y ago
Well, for me it was the opposite. Trying vanilla js was empowering! There was no; tool chain, bundling, virtual DOM, render function, countless layers of library abstraction, sourcemaps, node_modules... etc. Just a simple index.html file Some projects don't require a state of the art virtual-DOM-diffing-machine, just to display a list of ToDo items...

choicenotchance 6y ago

Compared to React, can anyone tell me how Vue is? Should I give it a try for my next big project (freelance)?

ivanstame 6y ago

Do you wish you knew VueJS? :D

pferdone 6y ago

tldr; RTFM

deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

tarkin2 6y ago

React isn't a library. You can't drop a bit of it into your project. It distorts how you build the webapp. jQueryUI is a library. You can add it in and your code is still vaguely the same. React is a framework pretending to be a library so people can't say "Oh, what? another framework?" As soon as you use React, you're in the react universe, not the normal webdev universe. With a normal webapp, I can just import an external js library. With react, I must look for projects that translate those library into the react universe (react-bootstrap etc).

skrtskrt 6y ago
You can just add the bootstrap CDN in the head of your index.html and use bootstrap without installing ‘react-bootstrap’ (I don’t disagree with anything else you said)
- gvjddbnvdrbv 6y ago
  Not if you want to use e.g. Bootstrap models without a lot of work.
- tarkin2 6y ago
  If you want to use the javascript components, rather than just the styles, you need the react library version. There are various other UI libraries as well that require you use the react conversion library, which sadly lag behind the vanilla js versions. Fair enough if you love react then this is acceptable. But it pushes the definition of a library, when just using react means that other libraries need to conform to react to properly work with it. React does some things nicely. But it's not "It's just a library. Drop it into your existing project. And you're done."

jarym 6y ago

I write a lot of enterprise apps and I’ve seen many many frameworks come and go over the years. I personally am not impressed with React and don’t get what all the fuss is about. We’ve had Angular, jQuery and a whole bunch of stuff over the years and each one managed to become a ‘a thing’ for a while

koonsolo 6y ago
React introduced a whole new way of writing GUI's. I come from a game development background, and there we had Immediate GUI's for some time now (https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutorial-part-1/ https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutor...). React basically translates this concept to the web, and does some optimizations to not rebuild the entire DOM from scratch, and only rebuild when state changes and not every frame. Writing a 'render function' is simpler and easier than building a structure of widgets and letting them handle events. (I like simple and easy) Anyway, it seems both react and flutter are also gaining on the mobile apps developments, and web developers are very happy using React. Of course frameworks come and go, but React introduced a shift of mind when programming GUI's.
- buboard 6y ago
  > React introduced a whole new way What will happen to this way when React is "outroduced" ?
  - koonsolo 6y ago
    Flutter uses the same concept, and it probably won't be the last. But who knows, things go really fast in the web world.
- jarym 6y ago
  React introduced this concept ‘to you’ perhaps but it wasn’t the first. The framework I used has been doing this in the very early 2000s. Don’t get me wrong it has a lot to like about it - but the only revolution is that Facebook’s might propelled this in the minds of developers all over.

programmarchy 6y ago

Off topic, but the yellow border on the page kept drawing my eyes away from the text to the edge of the screen.

c-smile 6y ago

Big picture: React (especially with JSX) can be thought as PHP running on client side. We can replace mentally any <div> or <span> on the page with <iframe src="someScriptFunction()"/>. When the application state (fuzzy term but still) changes we request these content generating functions to re-execute. The VDOM is just an implementation detail - agreement on what these someScriptFunction()'s shall return. Conceptually they may return just html and so we can use: function onDataModelChange(model) { element.html = provideHtmlRenderingOf(model); } can be used instead of reconciliation (diffing). Performance of such updates will be the same, if not better than React's, BTW. The only problem of element.html = ... approach is that such updates will loose runtime state. For example, if you have <textarea> replaced that way you will loose its current editing state - undo/redo stack, caret positioning, etc. So VDOM and reconciliation mechanism is a palliative - to do not loose runtime states on updates. But, again, it is not a panacea. Think about <div contenteditable/> based editors, their content cannot be reactive in principle. That update-only-what-is-needed reasoning frequently used by React people to promote "speed" hypothesis is a bit misleading - it was introduced for different reasons really.

temporallobe 6y ago

I tried React and hated it, especially JSX, but I made some decent money working on React projects in the past. I much prefer libraries/frameworks where the view is completely separate and is more “pure” HTML. I ended up creating my own framework that was much easier to understand and manage, but is obviously not generic enough to publish. Maybe one day I’ll clean it up and push it to a Github repo, but then again, does the world need yet another MVC framework? I think not.

hombre_fatal 6y ago
> I ended up creating my own framework that was much easier to understand and manage, but is obviously not generic enough to publish. You lost me there. Cute for a solo/learning project, but when other people are touching the project or you're trying to build a business, you have to answer for why your project was so special that it needed its own ad hoc framework. As opposed to, say, a framework with real documentation. Or one with an ecosystem so you can escape this culture of NIH. When I hear someone building their own JS framework, I see someone who wanted to procrastinate the hard part (building a business, shipping a product, appealing to users). Like when game developers decide to build an engine and never make the game, aka the hard part (https://www.voxelquest.com/ https://www.voxelquest.com/).
- temporallobe 6y ago
  Gatekeeping much?
petilon 6y ago
You could use an existing MVC framework such as this one: https://github.com/theabdulbari/mvc-router https://github.com/theabdulbari/mvc-router

peter_d_sherman 6y ago

Excerpt: "The way I like to think of it in comparison to Angular is this: Angular is a framework for architecting and building applications. It, for the most part, doesn’t change the way you write your HTML or CSS, but it heavily controls the way you write Javascript. React, on the other hand, is a library for building user interfaces. It, for the most part, doesn’t change the way you write Javascript that isn’t directly related to your UI, but it heavily controls the way you write HTML and CSS (or the equivalent of it). And this brings me to the next point…"