Few minutes ago I was checking the tag section of react on dev.to/t/react , and I notice that React is just like simple JavaScript with whole bunch...
For further actions, you may consider blocking this person and/or reporting abuse
I don't think many of you kids have been around for the REAL vanilla JS. JQuery file debugging type madness. That said, these frameworks do a very good job abstracting the work from the end user. People normally use it for time/convenience/opensource community support and because it makes things look pretty.
I should add though that with all this prettiness comes some prices, JS, if anything, is a stochastic templater at heart. Uglified files, Minified files, single letter naming conventions and an overwhelming amount of scaffolding often obfuscate some real technological concerns. Just go look at some of those spaghetti JS files around, there is no one alive who can sit there and tell me they know whats happening in that code and JS writes directly to data registers.
Thats just something to keep in mind, I think these frameworks have a time and a place, but so does having a fundamental understanding of the concepts that led to this point.
Considering your first and last sentences, what are the kinds of fundamentals you're saying are important? Do you simply mean JS without any frameworks/libraries? Or do you mean some kind of old version of JS that made far fewer abstractions? Or do you mean it is important to learn to understand that spaghetti JS you referred to?
I think JS has come a far ways from where it was. When I talk about fundamentals, I'm talking about understanding the concepts behind asynchronous and singlethreaded communication. Understand the differences between parallelism and concurrency. And at a very basic level, understand how paths work and how buffers work.
I don't think people need to use JS just to use it, its fun, I'll admit. As for the spaghetti, I think its important for people to understand whats happening especially with the DataBuffer and SerialPort capabilities of JS. When I talk about spaghetti, I more so am trying to convey that if know one knows what a script does, how can we know its not doing anything nefarious? I've gotten pwned big time before and the people who did it injected Root CA's through my GPIO Serial Ports, I got live breached through DCOM ports with SID's I've never ever seen before. My head was spinning. I don't want people to go through that so understanding how something works conceptually at a fundamental level is being present and cognizant of your environment. Because, I feel like a lot of people just are like "oh computers! I pay someone to handle that!" when we are quite literally compelled to use various government systems built by people who didn't really know what they were doing (and at no fault of their own). Lastly, I think if people generally were more prudent and aware about the tech aspect of our lives, we would be in a better spot with stopping a of malware targeting vulnerable individuals, like grandparents. Probably a lot deeper than you wanted, but thats my honest take.
Not at all! I'll take all the info I can get, particularly as a rookie. This is all interesting at least and important for me to know at most, and even if it is just the former then I now have things to learn more about.
lol, we're all rookies, kid. If you're the smartest man in the room, its time to find a new one. I'll be on here, feel free reach out if you got something you help with. I'd be more than happy to talk to impart what I know. Building cool stuff with people who also wanted to build cool stuff is why I got into this field. It's why I like it, its how I hope to contribute to it.
You mean react make the code more readable but basic fundamental of JavaScript should be cleared first.
I want to know what you prefer Vanilla JS or React JS, what you feel easier to work with regardless to make it readable for others.
Vanilla js. I use a lot of recursion and functional programming and if I need to get something down on paper I like JS as a "sketch pad" as I don't have to recompile after every tiny change. As for readability, to the framework its readable. But outside that, no. Its still on large generated spaghetti. Not ragging on it for that fact, it just is. As for React, I personally wouldn't use due to the URI security concerns I have with it. I developed medical applications using nodejs for embedded systems and as much as I liked the project, JS has no place around the embedded world. It just doesn't, there are too many error for a lot of mission critical applications. Thats why the Military on large still uses a x86 everywhere critical. Northrup Gruman and Lockhead Martin get chubs if you know the instruction sets well.
It sounds like you have a whole Dev article you could write about this and issues you highlighted before. I would be interested to read about your experiences
I did a couple write ups today, one on regex and the other on a recursive and dynamic, async matrix builder you an analytical pen testing client I scrapped recently. I'm still trying to get the writing part down. These were the first tech tutorials/article I wrote ever. I'm planning on starting a small multi-part series on Kotlin. My story is honestly so absurdly outlandish that I don't know how it would be received.
I literally had a $50bil company try to sue me over tweets and get spooked when I accepted and initiated pro-se proceedings. I also uncovered a massive illegal surveillance campaign being carried out by the NSA and Verizon wireless where I have an open com channel to how they scrap their customers phones. But I've had a lot of extremely strange and unfortunate circumstance opportunely come up when attempting to launch internal federal investigations into regulatory agency malfeasance. So man, if I had the right opportunity to tell it to the right people I totally would.
I wish you very best of luck my friend and hope one day you get a chance to tell it, all the very best, Stephen.
I think it’s a better story to continue building cool stuff and talking to cool people in a dev community like i’m doing now. Take it easy, Stephen. It was a pleasure talking to you
As someone who learned web dev right before the frameworks took over, I got to say that I have never felt the need to use react.
Here is my thought process when it comes to choosing a tool.
Is this project literally a single
index.html
page? Okay, maybe I could do this without any tools.So this project needs two or more pages. Can a tool like eleventy be enough?
Is this a data driven project with lots pages? fine, could I do this with laravel?
So this site will have highly interactive parts. Client side javascript can't be avoided. But before going full "React app", could I grab preact to make just the components I need?
I need a full on "web app" with lots of interactivity. Okay React, you and I are going to build some stuff.
Progressive enhancement is the key thing for me. I don't like adding tools if I don't need them. I still think "do I even need javascript for this? And if so how much?"
The thing is that the javascript community (or at least a very vocal part) has shifted the focus from websites to "apps". They are so comfortable with the tooling they use to build apps that they use for websites too. It isn't always bad, there are some good tools. But I bet someone out there is downloading 500mb worth of js to build a landing page, and that is where I think we have gone too far.
For static websites where there is not much of interaction or very less, Vanilla JS is totally fine and should be used instead of a framework! As for a user a framework mean more load time (downloading + parsing). But for a complicated app for e.g. Dev.to itself creating it with only JS will be a headache and a lot more work, you might end up creating mini-React! to ease your work. Even with JQuery it's totally possible but it will be harder. Easier than Vanilla but harder than React. You can think of React as a lot of helper functions making the development easy!
I have only to choice: Vanilla JS + CSS - that for really size dependent small app for example : banner where you can optimize much as possible. jQuery total forget - really don't used long time ago. Every other case - the React is really small and fine choice: that means a single JSX file plus standard index.html like:
plus complicated jsx
May you found really slim react base working setup
With nice parcel boundler setup which is also good for Vannilla JS if remove react and react-doom from packagejson
No matter how small React is, it will still bring something do the table and it's about 41kb gzipped (react + react-dom) thats a lot, so a plain JS is better for small work like you mentioned btw also checkout preact (never personally used) it's way smaller with and sufficient for a lot of use cases.
Yes preact is smaller react, and I work with them around 3 years, and its fine! But in my use case : complex scientic desktop application that few kb. isn't count, however larger React compatibile libraries still important.
POV: someone who has only been studying web development for a year, not professionally (yet).
To speak to each of your points in order...
1/2. A to-do list could theoretically be pretty simple. Using vanilla JS + HTML/CSS might be do-able. But making user interfaces is what React excels at. You could probably make the same app with fewer lines of code and have the code be far more human-readable and easier to work with if you use React. And if the project is huge, like, idk a massively popular social media site, then managing it all with vanilla JS would be a nightmare.
No matter one's feelings about Facebook as a company, it is hard to deny that there are some great developers there working on making React the best it can be. So are people HYPED about React BECAUSE of Facebook? I don't know, but since Facebook made React, it is hard to separate the two regardless.
Like I said, I am fairly new developer who is currently just a hobbyist, but my thought is that if you want to make an intuitive user interface with code that is easy to read and work with, then React is your friend. If you want to make a video game or something else? Idk, it seems like there are probably better avenues to go down.
One thing that we can be sure of is that: its not about the user (or user experience)
To the user all matters is that, things should look familiar and do familiar things on interaction.
So its all about the dev's convenience. Why spend time doing things that have been done before? Why take time to build abstractions ourselves?
And its not necessarily a bad thing. By not wasting time doing stuff thats been done, they can spend more time doing what really matters; that is, appease the user. (In theory, at least)
As for the benefits that frameworks give over vanilla webdev... its easier to just head over to their website.
At least, when it comes to coding practices and code maintainence and readability, the tool itself isnt much a problem (unless the tool is named PHP, then it can suck my a$$). ahem Every language and tool has a set of idioms and best practices defined for it. So, if readability and practices is a concern, its mostly a matter of preference.
Disclaimer: i have never used a framework myself, i have only ever used vanillaJS
Aside: i have a simple shooter game in JS that uses vanillaJS only (duh). No framework or external library.
Link: keogami.github.io/shooter/
I belive if you want to learn fundamental concepts you should start with vanilla JS but as your projects get larger and larger, you'll definitely need a framework to structure your code in an organized way.
React helps with structuring your code in components and is useful when you're building complex UI elements.
Righto let's firstly say, html CSS and JavaScript are not being replaced. You gain standardisation which is the true price you pay for vanilla homebrew work. The appeal of creating a standard is so alluring! I learned many years ago to rise above that feeling that I could write a standard, join the community, hire from the community that know this standard. It's often easy to draw conclusions like the masses are attracted to a particular product, so the smaller Indies must be he mark of quality, it's like boutique and the billionaire, you might assume that the little guy cares and the billionaire doesn't... Sometimes yes, but I would wager that engineering at Facebook is full of lots of little guys who don't represent the org as a whole, they have backing which means what was developed must have been impressive?
Yeah, means people who are Hyped for React are mostly beginners and Facebook may be a reason for that but mainly the reason is the hype because most of the beginners want to say that 'yeah I know React' or Vue.js or any .
It is being used not because it should be used but to show 'Yeah! I know it`.
is a tool in my tool box. Choosing which hammer to use on a nail is up to you some times you need a big hammer sometimes you don't. I still have a few project running jquery and there doing just fine. So up to you what you want to use. You want a challenge use flutter, no html, css, or javascript is used. Go explore there's more to life than just react.
Hmm, yeah I got it and sure I will try flutter web currently I am in the learning Flutter.
I made an account just to chip in on this subject. As a freelancer that works on many teams I've encounter the wrong answer to OP's main question many times, and the right answer a few time. If you take replace the word "React" with any other more advanced technology It's a question that goes back decades. The answers sometimes will tell you something huge about the company that created the team: Do you want to serve the client or your company?
Project: A small network of marketing website and a main website to increase the amount of inbound calls and increase visibility in specific local markets. Client does not wish to update the content themselves in the future.
If you serve the client, you should start with the lowest form of technology that meets their current immediate future needs. In this case, HTML CSS and images or video. There is no need to get Developers involved at all. Talk about easy and cheap updates to the website in the future! Any Jr level web Designer or even an intern can do them. Even the SEO guy assigned to promoting these websites can do the updates. And talk about the trust you've built with them. When they expand or land a big deal with a corporation and/or gov agency and need Development services, you think they'll NOT look at you first?
If you serve the company, you should start with as complicated a framework as your staff and the clients budget will allow. Not only will the initial cost and profits of the project be much higher but all the updates will take a Developer as well. Higher revenue . . . The risk is that the client learns that none of that was needed and they are paying you way more than what it would cost to hire an in-house Web Designer or an independent freelancer to rip the whole thing down and start anew. Do you think they'll ever work with you again?
And yes, of course if the project has higher lever specification the you have to up the tech. for instance if they want their non web design SEO guy to update the websites, then perhaps WordPress is the way to go to best serve the client. But if you're looking to serve the company, you'll probably want to build a whole new framework in React or C or something (or even customize use a proprietary one you've already built).
So that's some input from someone who'd been doing this since the 90's and have worked with some of the biggest names, the biggest companies and the smallest companies and complete unknowns. And seriously no judgments from me about who you serve.
If you just need a make a small button or make a small change using JS, then just use JS. But when you start making more complex apps, you'll see that your code will get very messy very quickly.
Before learning a new technology, I advise to "to do it the hard way" first.
Go make a todo list app with JS, html, and css. See how quickly it can become a headache.
Then, build the same thing with a framework. You'll quickly realize why people use them when you see how much more efficient they are.
You're making a great point! There are many situations in which React is not necessary and using just HTML/CSS/Vanilla JS is perfectly fine. It's important to choose the right tools for the job.
However, I think the code samples on dev.to/t/react are just fine. The purpose of those samples is to explain a specific library, concept, or feature. They have to use simple snippets so that readers can easily understand what they're trying to teach.
I think React (or Vue.js, or Svelte, etc) is a good choice for web apps that do a lot of DOM modification (i.e. dynamically changing the HTML elements of the page) that depends on the application state.
on 2: The biggest advantage is, that you can benefit from common knowledge when setting up a team of devs. Frameworks/Libs like React/Ng/Vue/etc. do bundle a set of patterns, best practises and popular libraries, and those are usually known with developers. And if not, there is already a big body of learning-material available. So getting up-to-speed is much more convenient for popular frameworks than for custom-build tools.
There are advantages and disadvantages to either side, it really just depends on the full requirements of the project that you're working on. Using the Todo app has the example: what if you wanted to add in user authentication, integrate with your calendar API, and make it an SPA?
React is just a tool, just like angular and svelte are. I can give you an easy answer for when to use a framework... When you want to build a single page application. It is simply not worth the fuss to do it by hand in vanilla. Everything else after that is subjective, and frankly more up to personal preference than most would like to admit.
You can achieve the exact same results in vanilla that you can building an app an angular svelte, Vue, or react... And they will all have their individual hassles and problems, it just depends on which ones you want to deal with.
Now before I start getting bitched at, there are tasks that are immensely easier to do and react or a state-based framework then it is to do by hand... But it is a trade, don't fool yourself and thinking that you are coming out ahead.
Okay, so you say React is a tool which make things easier and it's totally depends on me what I want to use.
When we get into the complexity of application building and get most performance boost over the vanilla JS or other scripts available in the market, React is much much better approach over the Vanilla JS that's why it was created to serve the purpose, but sometime an easy click or style changes with new frameworks or library is the hardest things to do, then we think why not simple HTML CSS JS is better! :) Its simple and same time very complex. but future thing is and should be to make things easy of easy, choice is ours :)
Sometimes it feels like event-driven changes get messy very fast and become hard to manage.
For example lets say you do a simple to do list app.
In JS it goes like this
User clicks form -> event listener is fired -> finds a dom element on the page -> adds the todo
Then if you want to maybe filter todos
User clicks add button -> event fired -> finds all the todos inside a dom element -> filters those elements down -> replaces all todos inside a dom element
In react its more like this
you have a state of todos that is an array of objects . For example one todo might look like { task: "go to the store" }. When that array changes the children component change too, or react to the change in state (hence the name).
User clicks add button -> event fired -> set the state of todos
User clicks filter button -> event fired -> set the state of todos
That's all the logic you need. In this small example its not a big time saver, but in other circumstances it can save a lot of effort once you get good at it.
ALSO you can basically incorporate HTML and Javascript seamlessly using React's Templating language(JSX is what it's called).
You can still make just as good of projects in either way though, it just might be easier in react, especially if there is a lot going on. There is also plenty of alternatives to React. The smart people I know love a library called Ember, but I've never used it and apparently it's kind of hard to learn. Also there's Vue and Angular
I don't think it matters that much what library or framework you use as long as you understand the core technology html/css/js. Most of the times the project stack is already decided by the client or the company you work for.
Besides learning the core stack really well, it's also great to use tools that speed up your development process. For example with Desech Studio you can just import your figma, sketch, adobexd design file, and then you integrate with react, angular, vue and even design systems like material design and you're set.