For others who are probably going to skip this because it sounds like a getting started tutorial - it’s not.
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.
I started going through this but got stuck on Lesson 4. I copied this file [0] as is and tried running it locally using live-server but I get an error.
Uncaught SyntaxError: /Inline Babel script: Adjacent JSX elements must be wrapped in an enclosing tag. Did you want a JSX fragment <>...</>? (36:4)
Somebody, please, publish a tutorial something like "Create simple web applications with Vanilla JS", or "How to build frontend-only apps using only native HTML5 APIs".
I can't believe people are still interested about this horrible, overhyped framework.
AKA: how to end up with your very own framework, that’s not as good as this other “horrible, overhyped” framework and you have to do absolutely everything yourself because nothing works with it.
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 don’t know how HN readers would know that “Dan star[r]ed the repo” without spending way more time on it than any reader does.
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 :-)
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.
Honestly, there's lots of different ways you can teach and approach learning React, in the same way there's lots of ways to teach and approach programming.
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.
Appreciate the tutorials, thanks. I understand that the core concern of them is to demonstrate React, but it wouldn't hurt to use valid HTML. None of your pages have a html, head or body tag. Speaking as someone involved with accessibility I'd hate to think we were assuming that devs just know this stuff - how can we expect people to learn web accessibility guidelines or how to use ARIA when tutorials don't even come with the most basic valid HTML structures?
This is actually valid since HTML5, and doesn't have any impact on accessibility. html, head and body tags are all 'implied' by the document structure. Times have changed...
Yep, this is valid HTML according to the spec, and should have no affect on accessibility. It might not be “valid” according to the W3C validators, but neither are many perfectly normal practices like proper custom elements (hyphen in tag name) and wrapping links around container elements. The era where validators were worth following has passed — we're now in the era where you need to learn to look at the spec for the laws of the land.
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 don't know, do you expect a written summary of them?
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?
Jeez. Why does anyone do this to themselves? All the work by the javascript guy and then all the work by the server to produce simple HTML/CSS output.
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.
If one would spend all this time learning HTML/CSS/Javascript fundamentals, and how to properly use them, they would have the same questions I have after 14 years of doing this, for companies large and small, as to why anyone bothers with this, Angular, and all the others. It just makes no sense at all.
If you've been in the industry for 14 years, know JS and CSS inside out, and still don't understand why anyone wants to use React... I think you're the one missing some understanding, not the people who choose to actually learn the framework in question.
No. Remember the repeated rise and fall of NoSQL, and the repeated rise and fall of mainframes/cloud, and everything else that's happening cyclical. Style-Attributes in HTML, CSS-in-JS, etc.
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.
I disagree, everything is much simpler without React. I'm actually working on writing a tutorial for creating structured code for dynamic content with vanilla JS. With Ecmascript 6, a lot of advanced concepts has become much simpler and easier to read.
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.
Sounds like you're proposing a framework, just one that people write themselves. I'll be interested to read your piece though, I'm curious to know how ES6 makes things like state management simple.
Yeah you can totally reinvent your component system yourself, or you can just use React which is used in production on thousands of websites and big products with top-level support of hundreds of engineers.
If you'd shared that system 10 years ago maybe we'd all be using that instead of React!
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.
I am into programming, like you are. I also would rather benefit from the thousands and thousands of developer hours that have gone into the react core, and not have to train every new team member on a crufty ten year old bespoke codebase. I do try to keep my external dependencies low, but core utilities are not worth rewriting from scratch.
sadly we aren't all as smart and worthy as you are, and don't have a decade old react-like hanging around. some of us even prefer the idea of using an open source library for the various benefits of doing so.
For the life of me, I can't understand why React is as popular as it is. A web application is simply HTML, CSS and Javascript. Why do people want to make it so damn complicated?
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.
Now, I realize that browsers' capabilities have advanced enormously in the intervening years, but it's still just HTML, CSS and Javascript, once the transpilers and the zillion other build tools get done with it. And I would argue that someone who really knows HTML, CSS and Javascript at a deep level can write it directly and maintain it a lot more efficiently than with a bunch of third-party frameworks and an overly-complex build process.
When people tried to write big enough applications with JavaScript, they found out, that it was a mess. JavaScript is a terrible language, so another languages were born (including modern JavaScript which isn't that bad). DOM is a very low level and very verbose API, so various approaches were taken to simplify development, e.g. jQuery, Angular, React. Hello world apps might be easy to do without frameworks, but once you're making complex pages with dozens of inputs, asynchronous loading, etc, lack of frameworks is likely to turn your code to a mess. Or, if you're brilliant developer, you might invent your own little incomplete buggy framework.
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.
Simple JavaScript has its place, of course. If I'm making text-only website and I want to introduce just a little bit of interactivity, like image gallery, using anything but a few lines of JavaScript is overkill.
>When people tried to write big enough applications with JavaScript, they found out, that it was a mess.
I have written huge, complex, graphics-intensive applications with Javascript, and that was not my experience at all. So maybe it's not the language, but the person using it that is responsible for the mess.
> 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.
>Do you use any framework, library or specific patterns in your apps?
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.
> someone who really knows HTML, CSS and Javascript at a deep level can write it directly and maintain it a lot more efficiently
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.
Frontend frameworks solve a need for SPA (Single Page Applications). While simple HTML/CSS/JS can handle simple static sites, something that needs reactive components (e.g. interacting with something on the site, and populating change instantly) is much easier in a framework. Javascript natively is quite difficult to do this and requires a lot of code to handle simple logic. This is what libraries are good for. React and Vue are such frameworks. These frameworks also allow for iOS and android integration as well.
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.
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.