6 ms·

every time Brad Frost writes something a bit controversial, it always feels like he can write and understand html and css, but anything else (including React) i

every time Brad Frost writes something a bit controversial, it always feels like he can write and understand html and css, but anything else (including React) is way over his head. No disrespect, it just feels like he's not spending the time necessary to understand how things work and instead of doing so, he just goes on and vents on his blog.

rhaksw 7y ago
he writes, > I also got — and continue to get — a whole lot of (often private) correspondence from a slew of people who feel equally overwhelmed. Adopting a new framework can be tricky. IMO it's okay to write about "the process of learning" to show that it isn't always a breeze. Posts like this can give perspective to both learners and experienced practitioners. Speaking for myself, I've enjoyed learning React, though looking back on my first project I can see I've made some pretty bad mistakes with my use of state. I don't know if there is a guide I could have read to avoid these mistakes, or if I just needed to struggle through it.
cljs-js-eval 7y ago
Yeah - I've seen and worked with (very talented!) people like Brad, and I feel for them. They're good at working with this presentational stuff, but it's never been necessary to learn that when they're creating an <input> they're secretly creating an HTMLInputElement. And then one day, they're expected to learn this framework that fits so nicely with the frontend because they try to emulate that hierarchy of objects on the frontend and deal with them in code. It would be weird to go from a DSL and realize that to move forward you have to get good at general programming. I'm not sure that I would handle that transition very well.
keithnz 7y ago
I've always found it odd that many React devs just keep doubling down and insisting it is much better and that it would be a disaster doing it any other way with "magic" templating systems or anything closer to html/css. Having done some significant work in vue and React and meteor, and played with a whole bunch of others, it is mostly about preference. React has a nice dev orietented mental model. As a true blooded programmer, none of them are that hard to work with once you get past their inital learning curves. I've generally swung towards to keeping things as close to HTML / CSS as much as possible to keep it realtively understandable for most any web "designer" ( so mostly I pick vue, though playing with svelte and that seems promising )
ehnto 7y ago
For me, it's not that I'm overwhelmed by the learning. I understand the "what" and "how" just fine. But React is a paradigm shift that I have yet to fully grok the "Why" for. It often feels like I'm having to re-solve problems we've had solutions to for a decade, on top of all the brand new problems React introduces. The core problem React solves, "re-usable reactive components", just doesn't come to fruition in most projects I have seen. It mostly ends up in a greenfields component stew. We can write re-usable components in pretty much any language with as bit of file organisation. So React takes a whole heap of convolution and tooling to end up in pretty much the same place as before, just written differently. Don't get me wrong though, I have enjoyed learning it and it is very cool technology, and I'm still open to having that "aha" moment when I finally get why people think it's great. It just hasn't hit me yet.
- dmix 7y ago
  What about the whole component based approached? You could certainly take a component based approach with simple code organization in HTML, CSS, and JS frontends. I've done that before, in a sort of pseduo-web components way using directories and naming schemes. React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration. Which increases reusability and helps further encapsulate the components. One of the most obvious gains to me is helping manage huge CSS files in legacy projects [1]. Components are way better than a giant BEM'd [2] CSS file, it's much nicer writing .box in a <style scoped /> in Twitter.vue instead of .twitter__layoutBox among a ton of other nested layers. All just to avoid global clashes and maintain some sanity. Or a ton of global jQuery plugins for select boxes and modals and everything else. Everything is so much more portable across projects. That's not even mentioning the whole plug-and-play reactivity that is baked in. [1] Here's a good list of the problems of CSS-in-JS helps solve: https://i.imgur.com/LbE1kqc.png https://i.imgur.com/LbE1kqc.png [2] http://getbem.com/ http://getbem.com/
  - WA 7y ago
    > React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration But is this really true? If you have simple presentational components, this is probably true. But your app is tied together by "container components". The state is unique to the app you're writing. You have to somehow map the state to the components. Maybe you use "container components". In one project, you use Redux, in another, you drill props down to all children. In the next, there's React Context or whatever the next thing is. Do components load their own data (like some widgets) or is there a root component that loads all data and handles the state for the entire app? I'd argue writing presentational components isn't that different from writing just HTML and CSS. The tough parts of React is where all the unique state logic is placed.
deleted 7y ago
[deleted]
typetrail 7y ago
Are you referring to posts like this?: http://bradfrost.com/blog/post/my-struggle-to-learn-react/ http://bradfrost.com/blog/post/my-struggle-to-learn-react/ "There’s a giant, great JavaScript community out there, but I feel like a lot of times there’s an implied (or sometimes explicit) 'OBVIOUSLY' or 'just' that comes with a lot of the territory. For instance, I was confused why there are different ways to create components in React, and several people tersely responded 'it’s common knowledge that you use functions for simple components and use classes for managing state.' I had no idea! I didn’t see an explanation of that stuff in the docs. If that’s what the convention is, that’s totally fine. Just don’t assume everyone has that info downloaded.", The assessment is pretty harsh on the guy, I think in Brad's case he's one of the more publicly documented instances of someone putting in the right kinds of effort.

rhaksw 7y ago

he writes, > I also got — and continue to get — a whole lot of (often private) correspondence from a slew of people who feel equally overwhelmed. Adopting a new framework can be tricky. IMO it's okay to write about "the process of learning" to show that it isn't always a breeze. Posts like this can give perspective to both learners and experienced practitioners. Speaking for myself, I've enjoyed learning React, though looking back on my first project I can see I've made some pretty bad mistakes with my use of state. I don't know if there is a guide I could have read to avoid these mistakes, or if I just needed to struggle through it.

cljs-js-eval 7y ago

Yeah - I've seen and worked with (very talented!) people like Brad, and I feel for them. They're good at working with this presentational stuff, but it's never been necessary to learn that when they're creating an <input> they're secretly creating an HTMLInputElement. And then one day, they're expected to learn this framework that fits so nicely with the frontend because they try to emulate that hierarchy of objects on the frontend and deal with them in code. It would be weird to go from a DSL and realize that to move forward you have to get good at general programming. I'm not sure that I would handle that transition very well.

keithnz 7y ago

I've always found it odd that many React devs just keep doubling down and insisting it is much better and that it would be a disaster doing it any other way with "magic" templating systems or anything closer to html/css. Having done some significant work in vue and React and meteor, and played with a whole bunch of others, it is mostly about preference. React has a nice dev orietented mental model. As a true blooded programmer, none of them are that hard to work with once you get past their inital learning curves. I've generally swung towards to keeping things as close to HTML / CSS as much as possible to keep it realtively understandable for most any web "designer" ( so mostly I pick vue, though playing with svelte and that seems promising )

ehnto 7y ago

For me, it's not that I'm overwhelmed by the learning. I understand the "what" and "how" just fine. But React is a paradigm shift that I have yet to fully grok the "Why" for. It often feels like I'm having to re-solve problems we've had solutions to for a decade, on top of all the brand new problems React introduces. The core problem React solves, "re-usable reactive components", just doesn't come to fruition in most projects I have seen. It mostly ends up in a greenfields component stew. We can write re-usable components in pretty much any language with as bit of file organisation. So React takes a whole heap of convolution and tooling to end up in pretty much the same place as before, just written differently. Don't get me wrong though, I have enjoyed learning it and it is very cool technology, and I'm still open to having that "aha" moment when I finally get why people think it's great. It just hasn't hit me yet.

dmix 7y ago
What about the whole component based approached? You could certainly take a component based approach with simple code organization in HTML, CSS, and JS frontends. I've done that before, in a sort of pseduo-web components way using directories and naming schemes. React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration. Which increases reusability and helps further encapsulate the components. One of the most obvious gains to me is helping manage huge CSS files in legacy projects [1]. Components are way better than a giant BEM'd [2] CSS file, it's much nicer writing .box in a <style scoped /> in Twitter.vue instead of .twitter__layoutBox among a ton of other nested layers. All just to avoid global clashes and maintain some sanity. Or a ton of global jQuery plugins for select boxes and modals and everything else. Everything is so much more portable across projects. That's not even mentioning the whole plug-and-play reactivity that is baked in. [1] Here's a good list of the problems of CSS-in-JS helps solve: https://i.imgur.com/LbE1kqc.png https://i.imgur.com/LbE1kqc.png [2] http://getbem.com/ http://getbem.com/
- WA 7y ago
  > React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration But is this really true? If you have simple presentational components, this is probably true. But your app is tied together by "container components". The state is unique to the app you're writing. You have to somehow map the state to the components. Maybe you use "container components". In one project, you use Redux, in another, you drill props down to all children. In the next, there's React Context or whatever the next thing is. Do components load their own data (like some widgets) or is there a root component that loads all data and handles the state for the entire app? I'd argue writing presentational components isn't that different from writing just HTML and CSS. The tough parts of React is where all the unique state logic is placed.

deleted 7y ago

[deleted]

typetrail 7y ago

Are you referring to posts like this?: http://bradfrost.com/blog/post/my-struggle-to-learn-react/ http://bradfrost.com/blog/post/my-struggle-to-learn-react/ "There’s a giant, great JavaScript community out there, but I feel like a lot of times there’s an implied (or sometimes explicit) 'OBVIOUSLY' or 'just' that comes with a lot of the territory. For instance, I was confused why there are different ways to create components in React, and several people tersely responded 'it’s common knowledge that you use functions for simple components and use classes for managing state.' I had no idea! I didn’t see an explanation of that stuff in the docs. If that’s what the convention is, that’s totally fine. Just don’t assume everyone has that info downloaded.", The assessment is pretty harsh on the guy, I think in Brad's case he's one of the more publicly documented instances of someone putting in the right kinds of effort.