I’ve only skimmed it but it starts by building up the components React works with from scratch without any JSX / React helpers at all. Much better way to get an intuition of what’s going on under the hood.
Uncaught SyntaxError: /Inline Babel script: Adjacent JSX elements must be wrapped in an enclosing tag. Did you want a JSX fragment <>...</>? (36:4)
Guess the array needs a comma and the fragment has to be React.Fragment
I can't believe people are still interested about this horrible, overhyped framework.
React fills a need and it’s features are bourne of real world necessity. Even if you don’t care for it, it’s interesting because the lion’s share of libraries are built to work with it these days and it’s backed by a company that will keep it going. It might not be the best way to fill a specific need, but it’s a good general tool.
I started this a few years ago to show people how simple React really is and that you can use it in directly in the browser :)
Hope this helps many people.
Btw. I am a remote software consultant for hire.
and I have a Patreon.
Didn't know what goals I should put there, but maybe more tutorials in that style, for Angular, Vue etc.?
My guess is that the different results are a mix of chance and the fact that the repo, and thus the HN submission, now contains “a simple tutorial for React.” The longer title is much more informative: https://hn.algolia.com/?query=https:%2F%2Fgithub.com%2Fkay-i...
If there’s a lesson here, it’s to use informative page titles, even for repos :-)
I think dad that there's no commitment to create some beginners' guide using jQuery and only just React, as the "go-to" solution for projects.
You are partially right. I discovered the repo on 'trending on github' and that probably happened because 'Dan starred the repo'.
However, getting on HN front page is a mix of luck and opportunity. Before posting, I checked on Algolia (because most repos get trendy AFTER being on HN): few votes. Too relevant for that so I reposted it. Then got lucky.
lol, you just stole my heart
Webpack, babel and create-react-app should be demonstrated as a conclusion, not as an introduction.
Had the impression most people who didn't want to use React hated the tooling.
I was impressed that even Babel itself wouls run via script-tag :D
It's a react tutorial, not a webpack/babel tutorial.
I'd even say you should start with a toto list exercice with only react.createElement, and only move to JSX later.
Using CodePen do show you full-gear examples is dishonest IMO.
Is it better to teach with something resembling a "real app" setup, so the user can start doing something "meaningful" right away? Or is it better to strip away all abstractions and start from the bare bottom, so that the user understands exactly what's going on under the hood?
Both are valid approaches, and a lot of times it depends on both the individual's learning style and what their background is.
This a million times over. I know webpack isn’t hard but it can be daunting to a newcomer.
It feels like the community it still struggling with this framework , while it has existed for many many years... Very interesting.
I'm blogging for over a year now, and the most views get the articles about basic JS stuff.
There are simply more people starting coding world wide than senior devs.
Then we might not speak of the same React. Angular and Vue have very rich documentation which makes tutorial unnecessary.
React doesn't have that, so it's very likely "has to do" with React.
For a beginner React tutorial, I’m happy to see the React parts given emphasis, and the other parts don’t matter simplified. Omitting those tags reduces noise, and is a good subtle way for people to discover that they are in fact optional.
I thought about turning the whole thing into an ebook once. Maybe a few extra lessons with stuff like HoCs/RPs, more lifecycle methods and some principles?
I am positive someone will come here and make a claim of large, dynamic sites and reddit's favorite nonsense phrase about DRY but I am also positive more people learn React because online articles tell them to than a real need for them.
There's a coaching gap because of the high demand in dev roles. New talent freshly out of uni and coding bootcamps lacks basic concepts and has to go through all the same architectural pitfalls and relearn the same mistakes over and over again.
The longer you're in business, the more such cycles you see repeat.
What's "everything"? Writing a mostly static webpage with a few moving bits? Yeah, sure. Building and maintaining a complex SPA on a team of 4+ developers? I'll take React any day.
When you are into programming, like we are, you think of these things long before some big company tells you what to do.
Where I work, we use React because it's easier to find new hires (because they want to work with React) and quicker to get them up to speed on a project (because they already know the framework).
It's also easier to integrate and extend any 3rd party components, as we're already familiar with the boilerplate.
Yes, like with most software.
But I guess the average dev is better off with learning React/Vue/Angular than cobbling together its own thing
I was around when browser based apps started to take over the enterprise software world. One of the big selling points was its simplicity compared to native desktop development languages like (horrors!) Visual Basic. Anyone could open up Notepad and create a simple HTML page with some form elements and a submit button.
It's similar to WinAPI. Sure, you can write C with WinAPI and it's enough for simple applications. But in practice people use better languages and frameworks.
> It's similar to WinAPI. Sure, you can write C with WinAPI and it's enough for simple applications.
That is a very far-fetched comparison, in my view.
oh. it would seem this is more about you feeling impressed with yourself, rather than making substantive arguments.
That is my argument. It's simple logic. If I can get good results without React, I've proven that React is not necessary to get good results.
Yes, but my team takes the same approach that Facebook or Google takes. We don't try to shoehorn in some general framework made for some other application by someone else. We make our own, that serves our own particular needs. We are the architects and the builders of our software.
My brain cycles are limited. I would rather let my toolchain catch the trivial errors and focus on more important tasks. I love TypeScript and React/JSX for this – typechecking my code, including views with data bindings and event listeners, saves my sanity.
However, I do agree with things being overcomplicated. I keep my tool chain process as lean as possible, with as few dependecies needed. I find it baffling that people would use React for something like an ecommerce site. Its all about the right tool for the right project. Not everything benefits from React, but some things do some things do not.