For programming veterans who have at least some frontend experience and just want to pick up React (i.e. me) the React docs and scattered tutorials/stack overflow sites was sufficient. But I wouldn't remotely recommend this path for someone relatively new to programming.
React itself is simple enough. To build a proper, functioning app, React is not enough. You need a dozen other packages to build even the most basic of data driven sites.
I'm an experienced developer and I could not wrap my head around React with free tutorials. This tutorial uses React, Flux, blah blah blah. This other tutorial uses a whole different set of packages.
It's not transferable. I need to build X. Show me a tutorial on how to build X.
People give Angular 2+ a lot of crap but at least every.single.tutorial I've ever read on it are discussing the same basic set of tools and system.
I pay for Pluralsight and while I've been focused on learning Angular from it, paid tutorials "generally" are much better quality then free ones IMO.
You can do the same with Ember.js also. There is a free detailed tutorial for absolute begginers. You build a full featured web app. It is so much fun: https://yoember.com
Young web developers certainly seem to love video courses for some reason. Maybe I'm just old and crotchety, (well, one of those is certainly true), but I would much rather get my fix textually and go along at my own pace. Flipping pages or scrolling is still superior to trying to scrub through a video timeline.
>Flipping pages or scrolling is still superior to trying to scrub through a video timeline.
Well, that's a different use case.
Videos are good for exact instructionals, because of this, they are quite good for getting to the bare metal quickly and getting a quick - albeit incomplete - understanding of the technology.
Following a tutorial online on a webpage is a bit different as it's not a follow along, (you don't get told exactly what to click and "see" someone doing it) so it requires a bit more parsing and effort on your part. (Which can often be better for learning, but not always).
Generally my workflow for learning a new tech is starting with a good instructional video (like udemy) for the basic grounding, then move onto the technical documentation to develop an actual well grounded understanding.
Videos have their downsides, (you can get through an entire video series and not actually know how to self-guide) but they are much better in my opinion at lowering the barrier of entry.
Text is much better for someone wanting to learn specific things, or connecting concepts together, and/or reference documentation, searching for concepts.. etc.
The other point that I'm unsure if it is just me or all people, but I've started loving udemy videos because I can follow along with it a lot easier when I have tired eyes and worn out brain after a full day of work. I often struggle to teach myself a new technology when I'm completely worn out from my job.
I agree most of the time, but sometimes watching someone actually do something lets you observe the little things that the teacher would take for granted or forget to mention in a written format.
I'm agnostic towards the medium if instruction but if I'm a little familiar with something, I would take a reputed book or official docs over video courses.
However, if I get too perplexed by something and need hand-holding to understand something, I look for videos.
Also, videos help in cases with libraries whose documentations are lacking or don't have docs regarding integration with something.
Videos are good for me to get a conceptual overview, when I actually start on a project, I’ll read docs and a getting started guide. I can watch a video while I’m working out in front of my TV. There are AppleTV apps for Udemy, Pluralsight, etc.
I'm also old and crotchety, and also prefer books to videos. I don't know why.
Give me an in-person training course, brilliant, I'll happily watch and learn from an expert. But I just don't like video courses for some reason.
I'm actively trying to rid myself of this mindset as I recognise the benefits of using such a huge range of - really very good - resources. Maybe a 2019 New Year Resolution there!
It depends... if you're new to an entire workflow, it's sometimes easier. If you're learning something specific and adjacent to something you already use, text is usually best.
Do people actually put that kind of stuff on resumes? I've done a good handful of MOOC courses (usually not all the way through to be fair), but I can't imagine actually paying for a certificate so I can put it on my resume. If I want to show that I know React I'd rather just build something with it, throw it on github, and list it as a side-project.
I learned most of it myself but bought a Udemy course for Black Friday. I find the docs to be quite confusing to be honest. I know it's not React but Redux's docs aren't great either. Concepts quite hard to understand at first.
FWIW, a lot of people tell us Redux's docs are "great", but we've also had people tell us they aren't helpful. Kinda hard to figure out how to make improvements based on that kind of conflicting feedback :)
We are actually looking at revamping the Redux docs in the near future [0]. If you've got any specific concerns or suggestions on how we can improve things, please let me know directly, or comment on that issue.
Also, besides the docs, you may be interested in my suggested resources for learning Redux [1], including my own Redux workshop slides [2].
Maybe I can help on this one. I'm midway through learning Redux - enough to have stuff working, but not enough to write complex UI code with it.
The problem for me is that Redux uses a set of higher order constructs, which requires a set of functional abstractions that are pretty unique to Redux and Redux-likes. There isn't remotely enough documentation to explain why the boilerplate is put where it is or named the way it is, so I have working code, but no real understanding of why the boilerplate is this way vs. any other way.
So what happens in the docs is that I follow the tutorial along, and it's great about setting up the problems to show why Redux is useful, but then it goes "ok so to solve the problem you use this magical incantation in Redux." Yes, I can adapt the magical incantation, but that doesn't really help me grok who owns which callback that makes which modifications or transformations to be consumed by which objects.
not saying you're taking offense to the critique, but I wouldn't. While I don't use Redux nor have experience with the docs for it, there have been some concepts that I didn't grasp from reading the docs for a topic where others had a better understanding of it coming out where after someone broke it down in a blog, it allowed me to understand it as well (at which point the docs were beneficial as a resource to come back to later). Different mediums will probably be better suited for getting more nuanced than the docs can, generally.
So I can totally see where conflicting feedback could appear and why you shouldn't take the "negative" feedback as a slight against the work on the docs (but fielding concerns/questions/suggestions as you are is completely a great thing).
From the outside looking in, if I were looking at Redux and I heard from a few "man, the docs are a bit hard to grasp" and others "I love the docs. They allowed me to get up and running" I wouldn't be scared off; it'd seem to be pretty par for the course.
Right, not taking offense - just saying that it's hard to come up with actionable ways to improve things when most people say they're good, and a few people say they're not helpful, and neither group really gives much in the way of specifics :)
The Udemy course that I saw gives an anology to how Redux is meant to work in the form of an Insurance Company and how Action Creators, Actions, Reducers, Stores etc. map to a real world scenario. That really helped my understanding of the 'Redux' model.
Redux has the problem that (a) the read-only reducer concept is totally at odds with how a bunch of JS builtins work and so conceptually hard to understand for a newbie, (b) it has just so much boilerplate for "best practices" for even the simplest use case, and (c) it's not immediately clear what the benefits of wrapping your head around all that are.
For me, it took me a while of working on a web app with derived data everywhere (~15 KB raw JSON that gets updated with diffs and recombobulated into different output formats and different intersections of data with live updates), and endless debugging of data transformations by stepping back and forth through the reducer history, before I really "got" it.
On the note of (b), I really like the redux-actions project (https://redux-actions.js.org) for the way its helpers that get rid of most of that. A simple example:
We've actually got a new `redux-starter-kit` package which includes some reducer utilities similar to `redux-actions`, but using the Immer library internally. That allows you to write simpler immutable updates that look like "mutation".
There's also some helpers for common use cases like simplifying store setup, and generating entire "slices" of state at once (including generating action creators and action types automatically).
I put together an example of using this the other day:
createSlice is an interesting approach, though it feels like it's missing the use case of being able to set multiple keys in the same reducer from one action, as with my valueAB example above. It might be worth putting some thought into how to make a variant of it that can produce multiple reducers (one per key to be affected), not just one.
I found their docs to be quite good, but I teach the topic and students vary in their responses, so I think it comes down to your approach and previous experience.
React is best to approach the same way you approach functions: You want to have small components, that do one job, that don't interact with outside state (see below for exception), and are largely ignorant of how your app works. The slight exception is container components, where interacting with outside state should be their sole job, encapsulating the application state interactions and passing the info to the contained components so that they don't have to have that knowledge.
I find a top-down approach works well: Break your page into parts (boxes of content), and then break those down, and so forth. Each box of content will be a component - most will contain others, and the smallest will just have on job.
Move all logic except for simple "show/don't show" into outside functions that you import in to your components - React is the View and you don't want it doing nearly as much as it CAN do. Keep it simple, keep it small.
Remember the key rule: You can pass values DOWN (into contained components) but not UP (into your wrapping components). So if you need to send data "up", you need to pass callbacks down and use those callbacks to pass any data "up". This can feel weird, but it helps keep those contained components ignorant of your larger application, which in turn makes them more reliable overtime, as they aren't impacted by changes outside of themselves.
If you have had limited experience with function best practices, or if you've only worked in deeply OOP systems (that have similar best practices but different concepts for passing data), this can be a bit of a struggle to adjust to, but it's actually a very common pattern, and the reason I use React to teach web dev (after teaching basic vanilla JS) - even after React is obsolete these practices will be useful to follow.
I also recommend learning React BEFORE taking on Redux (or any other application state management lib) - even a simple TODO app (don't copy what is out there, write it without hints, then compare) can help clear up the root concepts, and after that application state management is easier to keep distinct in your mind. I took it all on (React + Flux) at once when I started and it took months to grasp because I wasn't keeping them clear from one another. Redux mapXXXXToProps() functions are in fact quite hard to grasp unless you comfortable with how you use React props in practice, at which point they become straightforward.
And lastly, the switching between class-based components and function-based components can be really confusing. I personally prefer to use almost exclusively function-based components, because React is not expecting you to use an OOP approach to the components. I only use class-based components where I need component state (often only the top-level component for small apps) or if I need to use the lifecycle methods (and I rarely do - many examples use didComponentMount to fire off service calls, but I tend to put those into event handlers, though that gets a lot easier when you are using an application state management lib). but if you prefer class-based components, that's fine - just don't think React is using classes for anything more than providing inheritance of the component methods. No OOP-approach to your components.
I would say we are all human. Some are lazy, some want shortcuts, some have difficulty in reading, all sort of things, that's why there are a lot of non-free React (framework X/ Library Y...) courses
I think you learn a lot from watching people code that you don't get from their docs.
Here are some examples:
1. Which files do I spend time on and which ones can I ignore? The first time I tried npm I felt like I had to understand all those files that kept popping up.
2. What is a good workflow? None of those documents tell you to open up dev tools and constantly console.log out values, but in a video (I assume) this will come up.
These are two examples but they mostly they show you what you should focus on. There are dozens of little things that you won't pick up from text.
Imagine a brand new developer who started learning JavaScript as their first programming language one month ago. A nice hand-holds video might be perfect for them.
Also, not going to judge a super experienced developer if they just prefer videos for whatever reason.
This actually looks like a pretty good resource. The combination of a voiceover and an interactive editor looks pretty neat. Noting this for future reference.
If anyone's interested in further resources, I'd suggest checking out my suggested resources for learning React [0], my React/Redux links list [1], and the Reactiflux chat channels on Discord [2].
I use React daily so wasn't expecting to learn much, but the vids on forms were helpful! Handling form submission can actually get pretty annoying in React if you want to do anything remotely customized.
Also love the idea of including "Project Ideas for Practicing" as its own module. Two thumbs way up.
Am I the only one who thinks that courses that don't teach TDD from the start are useless? How can you write an app and not programmatically prove it is working as expected?
I imagine it would be very difficult to teach a topic no one is familiar with by teaching how to test it _first_. A TDD approach to teaching a brand new topic would be very hard to follow and require the viewer to go back to re-watch the testing portion. (Imagine teaching a total beginner how to test a function before teaching them what a function even is...)
However, I think there's a lot of validity to the idea that every tutorial should include lessons on how to test it that new topic, and even give examples of how to implement a TDD approach. But those lessons would (IMO) have to come after the initial parts of the tutorial that taught the concept first.
Are you referring to teaching TDD at the start of learning programming, or are you referring to using TDD as a vehicle for teaching every programming topic?
If its the latter, that's an approach that I've never seen before but its definitely thought provoking.
Have you listened to the "Why React" video? He says there, repeatedly, that, quote, "For now, it's enough to know that the virtual DOM helps make React work a lot faster than vanilla JavaScript". How can anyone make such a statement and expect to remain a credible source of information? I mean, even if you are targeting complete novices, how?!
Because it's kind of right, in the way that it's not technically accurate, but a bit of an approximation that's reasonable for a beginner-level introduction.
But how, how? I wouldn't be able to bring myself to say something that I knew to be strictly inaccurate. Even if you are talking to beginners, don't you owe it to them to say only things that you believe to be true? There are lots of ways to put it differently so that it wouldn't be so outrageously inaccurate and so that, if you are a beginner, more senior developers don't laugh at you if you repeat those things.
It's not that inaccurate. It's in the right ballpark, just glossing over all of the details of what that means in practice. Would you prefer "The virtual DOM helps make React work a lot faster than doing direct manipulation of the DOM using vanilla Javascript"? Doesn't really seem like it makes that much difference – and the author links to an external video that explains it all in more detail.
Anyway, any senior developer who laughs at a less experienced one for repeating that kind of thing is a bad developer. I'd like to think they'd take the time to correct the inaccuracy :)
> Would you prefer "The virtual DOM helps make React work a lot faster than doing direct manipulation of the DOM using vanilla Javascript"?
I am not sure this is even correct. Firstly, the famous js framework benchmarks (https://github.com/krausest/js-framework-benchmark) based on adding/removing list items used to have vanilla JS as an unbeatable winner, despite its direct manipulation of the DOM, and React was definitely significantly behind. Secondly, as the README for morphdom says, the real DOM is very fast (https://github.com/patrick-steele-idem/morphdom). If I remember correctly, virtual DOM was supposed to solve the particular performance problem where you would otherwise just throw huge chunks of DOM away rerendering them anew every time your app state changed. But this is a very special (although brilliant) approach to keeping your UI in sync with your app state; you wouldn't necessarily do so if you wrote your app with vanilla JS.
Oh, I am sorry, I re-read your sentence, and I think I misunderstood it. Yes, if React were using real DOM rather than virtual DOM it would have been slower, but the author was not trying to make _that_ point.
Sometimes it's easier to brush off a question, or make a statement in a learning context than get tied up in nuances. Do you really want to learn react with a 4-hour video on framework comparisons in the middle before you've learned the one you're looking at?
It's a valid point - if I were concerned that Jr. developers would parrot every line from the course to the ridicule of very particular Sr. developers I would have specified that the Virtual DOM makes React faster than if it were trying to directly use the actual DOM, all else being equal.
But since that wasn't a concern of mine when I made that video (it is far from the main takeaway of the course), I kept it as simple as it needed to be to get the point across.
But why even bring up the topic of virtual DOM in a course addressed at beginners? If you picture your target audience as so new to the field, why should they even care how React is working under the hood to change the contents of the screen?
Virtual DOM (unless I am mistaken) is a solution to the problem that React would have otherwise introduced. But surely, selling points of a framework are not how it solves its own technical problems, but rather what problems it undertakes to solve for its user.
I find this ^^ to be one of the main selling points. All online courses are in danger of falling into the "Tutorial Hell" category, where they spend all their time teaching you without the student actually being more capable afterword. The Scrimba platform significantly lowers the barrier for students to get their hands on the code and actually obtain new skills. I have yet to find another platform that lowers that barrier as efficiently/well as Scrimba.
If you actually spend some time researching, you'll find plenty of information about us and the company.
As for "collecting VC money" we've raised around $250K from angel investors and one Norwegian VC and we've also gotten a loan (which we're partly personally reliable for) from Innovation Norway.
Thank you for the information.
I am however not an investor but a developer. When 'a free tutorial' is advertised i am always afraid i'll be forced into later payments or becoming the product myself, especially when professional investors are willing to support the company financially.
Giving information on your website about the user do's and don'ts are always appreciated without having to file a request in triplet to the board of directors.
Still I highly appreciate the links to the company information.
