6 ms·
Oh, come on... Is React really that hard to understand? It's one of the simplest libraries I know. I was a self-taught web dev with only about a year (though, q
by iliaznk 8y ago
Oh, come on... Is React really that hard to understand? It's one of the simplest libraries I know. I was a self-taught web dev with only about a year (though, quite an extensive year) of JS/jQuery experience when I switched to React. I had never worked with a JS framework before and I knew I was going to need one for my next project, and for some reason I chose the new (at that time - early 2014) React, rather than the established Angular. And after going through the official tutorial everything went so smooth I was amazed by the power of React.
- commandlinefan 8y ago> Is React really that hard to understand? Beats me, I've never tried to learn it - it was the author's example of a framework that's harder (or appears to be harder) to learn than to just reimplement from first principles. Replace "React" with something that does fit that description if you like. Unless you think there is no such thing?
- iliaznk 8y agoWell, I guess there sure must be something hard to learn, but is rolling your own easier? I really doubt that. Or why then we don't see a thousand of frameworks in other languages? Are there no hard to learn frameworks written in them? I believe people set out to write a new framework because those that exist do not meet some certain criteria of theirs. And just to imagine somebody lacking ability to comprehend something while having an ability to implement their own... Sounds weird.
- imnotlost 8y agoI've rewritten fairly large systems and re-integrated them faster than I could ever have understood the original code. I don't think React is in that category though, I think the concepts are understandable, the documentation is good, and StackOverflow is helpful. I implemented a small React app while learning it which is in production and running just fine.
- commandlinefan 8y agoYeah, that’s definitely true of established, in-house, undocumented, partly-working code bases.
- muxator 8y agohttps://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- commandlinefan 8y agoWell, that's what I (and the author, I believe) are getting at. In the long term, it's almost definitely better to reuse what's already there and is tried, true and tested. But that's in the long term. When you're giving daily (!) status reports and trying to justify your existence, you're better off pointing to something that you programmed than at time you spent learning something. Organizations are shooting themselves in the foot by holding learning in such low regard.
- iliaznk 8y agoOh, I see, but I haven't seen that in my experience. At our company it's fairly normal to have a task that sounds like "Investigate..." or "Research..." especially at the beginning of a project, with an expected result being zero lines of code, understanding of some important concept and a decision made that will govern which way the project will move from that point on. I personally had to explain to our PM that we can't just take whatever tools we used in a project that has been just completed and lasted over a year, because lots of things could have changed during that period, and taking time to research for better alternatives is always worth it. He agreed.