11–20 of 218 posts
The thing about ES6, braces, promises, and anything else in programming is that you need a few core examples to wrap your head around and everything else is an application of that.
Beautiful website btw.
But I just want to say, as an alternate data point, my experience has been exactly the opposite. I love React. React is the first front-end technology I have ever managed to get to stick.
* ES6 is just a detail, I know. But for me, ES6 transforms Javascript from an idiosyncratic scripting language where I constantly have to look up the ordinary way to handle basic programming tasks into something resembling a modern high-level language. To me, ES6 turns Javascript into Ruby. I don't love programming in Ruby, but I can do it quickly and without the language getting in my way.
* The basic idea behind React, that your UI rendering code is always working with a snapshot of the current state, and 95% of your job is just to take that state and re-render it wholesale, eliminates a huge amount of the cognitive load I experience trying to do front-end stuff. I allows me to stop thinking in state machines, and just write straight-line code. If you've been primarily a backend person and have always sort of hated doing front-end stuff, check out React and see whether it's just the programming model that's been bugging you.
* Unlike the author, I've always been more of a programming person than an HTML/CSS person; I would kind of rather eat a bug than fiddle with CSS. One thing that makes React so nice for me is that you can just buy an HTML template and gradually turn it into JSX to "animate" it into a UI. Another thing is that it so nicely decomposes into components that there are a bunch of high-quality UI component libraries to draw from.
I have a lot of the same problems with React that everyone else does:
* "This" and the JS class model still feel like own-goals and I'm regularly tripping over them. But I'm never stumped by them; the bugs are always pretty obvious and easily fixed.
* Perf has been an issue, particularly memory consumption. But to me, this just suggests that I'm actually productive in React, that I'm getting to the point where I'm comfortable enough belting out code that I'm generating perf problems to go fix. (This has come up on relatively complicated UI projects, like the debugger interface we did at Starfighter, which was a monstrosity).
* The tooling was a disaster before create-react-app. But now there's create-react-app, so the tooling isn't a problem.
* I still have no idea what the right way to test things is.
I'm not rebutting the article at all! Different people, different issues. I just thought, if that perspective was valuable, mine might be too.
If the author sat down for an afternoon he could fix most of these struggles, in probably less time than was invested writing about them. The thing about ES6, braces, promises, and anything else in programming is that you need a few core examples to wrap your head around and everything else is an application of that. Beautiful website btw.
I'm surprised the tooling isn't mentioned more... create-react-app is awesome and huge time saver but as soon as you have to step outside of that realm there are so many dependencies and other tools to get the sausage made that it's daunting for new-comers. It's not at all fair to compare JS and Go BUT that is the one part of Go I really, really love- `go fmt` is built in and most of the tooling Just Works™ with mini…
If the author sat down for an afternoon he could fix most of these struggles, in probably less time than was invested writing about them. The thing about ES6, braces, promises, and anything else in programming is that you need a few core examples to wrap your head around and everything else is an application of that. Beautiful website btw.
I don't get what the benefit of using React is, aside from having it on my resume. A virtual DOM? What does that get me? It renders faster? Rendering speed is not a problem my CRUD screens have. Etc., etc. Perhaps some UIs are so complex and dynamic that they're easier to build and maintain using React. I'm not saying other people shouldn't use React, but I'm fairly certain it wouldn't give me enough payback to justi…
Aside from that, it and a handful of other technologies (webpack, maybe redux) seem to be coming out ahead as industry standard for SPAs. So yes, learn it “for your resume”, or as I like to put it, “staying employable”.
Edit: this is assuming you already have a SPA based CRUD app. If you are rendering server side then by all means keep doing that.
Honestly I don't know how I learned React. It's not fun at all. Oh sure, the basics of React is not too hard. If you ignore all the outdated examples and code (using var, no JSX, overusing component lifecycle, not using functional components). But then learning Redux, React Router, React JSS, Reselect, Redux Thunk, Webpack, etc., is just terrible. Sure, there are tutorials for each individual library, or maybe even t…
Even Redux's author tells people Redux is overused. A pretty big percentage of the value of the flux pattern is just in having an event pubsub system, so if your application is so complicated that you really feel like you need to structure it, you can just use EventEmitter.
I frankly don't understand the popularity of React Router. The core thing React Router accomplishes can be done in ~50 lines of code including the switch statement for "routes". If you like and grok React Router, use it. But I don't think it's a good idea to push through your resistance to it.
Honestly I don't know how I learned React. It's not fun at all. Oh sure, the basics of React is not too hard. If you ignore all the outdated examples and code (using var, no JSX, overusing component lifecycle, not using functional components). But then learning Redux, React Router, React JSS, Reselect, Redux Thunk, Webpack, etc., is just terrible. Sure, there are tutorials for each individual library, or maybe even t…