Let’s say you already know how to write vanilla Javascript or jQuery to do some app-like things. You can fetch data, send data, and manipulate the ...
For further actions, you may consider blocking this person and/or reporting abuse
If you don't mind, I have a couple of thoughts about the article. It looks very well, but it might create some confusing impressions:
It just not true. Yes - native support, for now, is shipped in Chrome, Safari, Firefox, Opera, Internet Browser, UC Browser, and many more, but not in IE or Edge. However, with shims and polyfills provided by the community you can try to use web components today! Especially polyfill for creating custom elements covers almost 100% of the specification.
Someone who has no idea what the React is may have one thought after reading that - JSX is an integral part of the library, and it has to be used. It's not true, even though it is still recommended. It might be a good idea to point it out.
And the sentence before that code snippet... A newbie can understand, that with React is possible to just put a new fancy created element in HTML document. You don't explain, that it has to be used with the render method:
ReactDOM.render().I would also recommend simplifying your code examples by hiding not important implementation details. In the code snippet, you can import your methods, which fetches GPS data or update something, and only show the DOM part from vanilla example and React part from the latter. Your first example is cut off in the middle of the function (?). You also compare it to the react example before you show the react example. If they would be shorter you could show them one after another.
And the last thing. Your form example in React can be simpler. Lat and Long fields could use one React component, they are almost identical - the only difference is with what callback they call. You can parametrize that with name prop for example.
By the way, I hope I did not offend you. Again, it is nice to read more articles from the DEV community.
Thanks for your feedback, Dominik. I didn't realize I had not included all the code in the first example, so that was extremely helpful! Some of the other feedback will be incorporated into future posts.
I'm not offended. I appreciate your taking the time to read! 😄
Hmmm...you could replace "React" with "Angular" (or "Vue", or whatever) and say the same thing. So tell me again why should I learn React?
Hello Devon, great article! I have to say that React is also very simple to use when you are a beginner in web development, very clear to understand with a good documentation.
My advice for those who hesitate to start learning it: read this article, go on the web site of React JS and have fun! 🌟 🌟 🌟
My initial answer to the title is "because it's awesome" but seriously though doing things in React may look like a lot of extra work initially but taking that extra work makes for allowing an application to grow and scale without the additional complexity and additional mess of other approaches. Great article!
React is something I have looked at but have chosen not to pursue. React has many fine attributes especially that it offers a way to encapsulate functionality as components as you describe. However, it also comes with an unwelcome feature you mention only by allusion: the build step.
In the past I have used the Sencha framework (when it was free and called ExtJS and before it became hideously expensive) and React has many similarities. Unfortunately, one of the similarities is the need to execute a build process to transform the React source into a package of actual JavaScript.
To me, an attraction of using a scripting language is that it is possible to change code and run it. More importantly, the code seen in the development tools windows of the browser is the code that's been written. This is not the case with React. Instead, its necessary to install the React developer tools to help the developer relate the code executing in the browser to the React source.
The encapsulation offered by React is welcome but for me it does not justify the cost of retooling the development process to change the way writing code, testing, user validation and documentation is accomplished.
If we are going to retool the whole cycle and accept the need for a build process I want there to be bigger gains so I will be waiting until one or more of the existing strongly typed languages such as C++, Java or C# are able to emit reliable web assembly packages. Using a tool like Razor (based on C#) offers the prospect of being able to run code closer to the machine and so gain performance benefits while also getting access to the existing strong typing, build optimisation, profiling tools and OOP capabilities of a mature development environment.
This is not an option for a group that needs to move today or needs to be able to support IE 9 today but it may be a more cost effective option for some groups that can take a slightly longer view.
Create React App addresses some of the problems you've mentioned here. It allows me to write code, save it, and see the results almost immediately in the browser.
Source maps address being able to debug with the code I wrote rather than the built code. These come for free with an app generated with Create React App.
The build process is still there, but it has little impact on your development workflow.
Sweet! I wasn't aware dev.to used Github markdown. Got that fixed. Thanks for the tip!