81–90 of 157 posts
React itself is actually really simple and a nice way to make complicated UI.
Earlier quoted context omitted.
If your web-app has even a modicum of complexity on the client side, the vanilla DOM based solution is going to get unwieldy real fast. Consider a simple list of elements to which you can add or delete items. With vanilla DOM, you’ll have to write handlers that will `$.find` the particular element, and then run a `$.remove` to remove it. To insert something, you’ll have to do a manual `$.appendHTML`. And when you hav…
No adding/removing/modifying elements in a list is very simple and fast, even with thousands of elements. Example: https://pastebin.com/Fu39i47z
The bad part is that React has a lot of code on its own, and somewhat strongly suggest use of even more. It's orders of magnitude more than that your `{add,update,remove}Message` snippet has. While React tries its best to hide all that complexity, it's still there. Designing, writing, reading, debugging and rewriting (if necessary) those few functions is all trivial (but somewhat routine) - not so much with React.
I don't think the `className` argument sticks. `class` is reserved so you can't use it. It's annoying but not a difficult concept The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state? I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN…
I've found that with small React apps, you normally organise each component to be responsible for handling its own state.
If you need a global shared state but your app isn't large enough for Redux then lots of people pass callbacks down to child components as parameters. True story.
Don't get me wrong, I think React is good at what it does, which is rendering. I just don't think the maintenance of a react app, which includes dependency management, is worth the benefits. Similarly the current model of reinventing everything in the "react way" is hardly speeding up development.
We're recently built a React Native app and I feel the benefits it brings to cross-platform development make that ramp-up worthwhile. A single iOS and Android codebase is a glorious thing, and helps avoid needing silo's of specialized developers.
I would say that the maturity (or lack thereof) is obvious when using React. The big ideas are solid, but there is a lot of thrashing - you need to watch each new version for backward-compatibility issues and carefully manage your dependencies. Coming from Ruby/Rails, I also feel like React is still at the point where you're spending a lot of time configuring things vs adopting standard conventions - it's getting there, and projects like react-navigation are helping build up that boilerplate, but certainly can be frustrating at times.
At our company, we have banned React, Angular and other "overengineered" JS frameworks. Our HTML is rendered from a standard boring Groovy server page, with some vanilla-js for DOM manipulations here and there. We have hired developers that were React fans, which quickly changed opinion that this old-school way for developing web applications is indeed better. It is faster to code, an order of magnitude easier to mai…
Recent example of it is gitly.io. It is a beatiful web service which is I believe written in go. I just looked it up and it merely uses 200 lines of vanilla js. When I'm logged in and actually browsing the file tree.
The trick is - don't try and learn all this shit at once. Make a react app without any extra state management. Just store your state at the top and pass shit down. Add more stuff until it starts to get annoying passing all the callbacks back up. Now you are ready for redux cos you understand what it is saving you from. React itself is actually really simple and a nice way to make complicated UI.
Earlier quoted context omitted.
Just curious, how do you handle the vanilla-JS stuff? 1) inline with your view files 2) write them in separate js files and include them depending on the page 3) concat them into one big js file which gets included on every page 4) something else?
Yes, we do a lot of inlining at the end of a view. In every case when the javascript is only usable for that view we find this very clean, every developer can immediately see what javascript is running on that particular view. We have our own small library for the more common operations, for small things like more effecient navigating of the DOM three or more complex "components" that for example convert a select ele…
I don't think the `className` argument sticks. `class` is reserved so you can't use it. It's annoying but not a difficult concept The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state? I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN…
I don't think the `className` argument sticks. `class` is reserved so you can't use it. It's annoying but not a difficult concept The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state? I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN…