Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For context I'm a specialized back-end (but with a lot of experience in desktop GUI/game engine stuff) dev and I also wanted to learn React recently to round off my skills and be more marketable in the job market.

Like yourself I also prefer written docs, but trying to find such structured info was an exercise in futility. At the end I used my existing Pluralsight subscription and went through the React 18 path they have which is around 18 hours or so in total. The courses covered different topics around React like components, hooks, testing etc. Good thing is the courses also have full transcripts! I followed them along and created some small apps myself in the process. Now I'm pretty much sure I can handle working with React in a normal job setting. You might want to consider that option. To be honest FE seems like programming on easy mode compared to some of the things I'm used to working on in my day to day. If you are an experienced programmer you should have no problem getting caught up to speed on that relatively quickly.



Similar experience, frontend work is more relaxed and forgiving. You can more or less trial and error until it works and looks good. It's all very visual. On the other hand, making a mistake in your backend auth, order handling/accounting or even mass email efforts can have some really nasty results.


You’ve basically said that you did a React course, built some toy apps (which almost certainly had sterile, malleable requirements) and now feel like the whole “front end” thing is easy mode.

Chances are you aren’t materially smarter than the hoards of smart people doing this day-to-day and find it ‘not-easy-mode’, and that you’re instead in deep Dunning-Kruger territory.

You watched the VHS about foundation repair but you’re yet to get thrown off-course when you find out that you don’t know what carbon-fibre stucco lath is.


A more charitable interpretation is that _hao has learned that React has simple, easy-to-remember patterns, allowing the developer to focus on domain-specific problems (which can be arbitrarily deep and complex, just like backend code.)


Not to be combative, but I didn't say anything about being smarter or master at web FE and React. My comment was supposed to be seen as more like how @hathawsh read it. It's easy to do work with React if you have a good programming background and it doesn't need that big of an investment of time to go into it.

I'm sure React has it's own intricacies just like every other tool and it takes time to appreciate those. I can see how managing your reconciliation state can become a big hurdle in larger projects for example. I've done WPF, MFC and a lot of other things on native desktop programming and the ideas in React are not that different. Those ideas in the browser context are actually easier to deal with than on a native platform hence my "easy mode" thought.


Agreed... I've done a bit of simulation work, and the unidirectional flow for react (and redux) was pretty natural to me and similar to other approaches I'd used for ui composition and state management. A few patterns that can be more difficult (slightly/arguably) to get started with, but easy to repeat.

I've been a fan for several years now, almost a decade and I adopted the hooks relatively early on as well. It feels right, even if something under the covers are complex, you don't have to think about a lot of that when you aren't looking at it.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: