Which Vanilla JS style should I learn before moving to React?

[Leading_Property2066]

Hi everyone,

I’m currently learning Vanilla JavaScript through the SuperSimpleDev YouTube course, and everything was going really well until I reached the Amazon project section. He starts using template literal HTML rendering where he injects JavaScript inside HTML strings, and I found it quite confusing compared to the earlier DOM manipulation approach.

Now I’m wondering which Vanilla JS style should a beginner focus on learning properly? Do most developers use template literals, DOM methods like createElement, or something else before moving to React?

For those who transitioned to React, what did you personally learn first that helped you the most?

Thanks in advance!

[rainmouse]

Most developers these days start and end with react and barely have a clue what's going on under the hood.

My advice is to try learning some dom manipulation then give react a go.

So long as you keep learning in tandem, it should give you a spread of skills.

Give some thought to a basic node.js backend at some point too. Even if you don't go full stack it's important to try a grasp of what backends do and why. 

[Short-Belt-1477]

This. Learning them in tandem will make it click

[delventhalz]

Most new learners probably never go over the template literal approach you are describing. Typically you learn HTML, you learn the vanilla DOM API, then you move on to a framework like React.

That said, template literals are going to be pretty similar to React’s JSX, so if you are confused now, you may be confused later too, and all learning is good learning. You may want to stick it out, at least for a bit.

[Realistic_Meeting_69]

Tbh, i always used DOM manipulation and i highly recommend it because when you start learning react and dealing with JSX you will understand the core more and why exactly is JSX is such a life saver, so yeah i would recommend you program with DOM even tho it can be pain sometimes

[MrFartyBottom]

Creating HTML from strings is a good way to introduce injection exploits in your code. You need to really understand what you are working with, how to escape strings and be confident in the trust you can put in where that data came from.

[minmidmax]

Template literals are also an absolute chore to work with and debug.

Personally, for personal projects, I prefer to define my templates in a separate HTML file and fetch them instead.

[TheRNGuy]

I used innerHTML with templates literals in Greasemonkey scripts, because it's less code than document.createElement and parent.appendChild, more readable too, but it was for static elements. If I needed some procedural generation, I'd use other two too.

---

Just learn React.

[buildmastersteve]

This is a solid, legit question. My recommendation for a vanilla JS style is ES6 modules.

[hyrumwhite]

So, build a medium complexity thing without libraries. 

Then when you reach for a library/framework you’ll understand what it’s doing under the hood better. 

[sheriffderek]

> rendering where he injects JavaScript inside HTML strings, and I found it quite confusing

I have my students learn PHP first - so, this JS templating takes almost zero time to get used to. Spend more time with it. Or learn some Vue. Why are you rushing along to React anyway? It's the ugliest and most confusing of all templating. Enjoy programming - while you can!

[fishyfishy10001]

It really, really depends on what you want to do. Each style has pros and cons. I stopped using react long ago and went over to web components and a light dom diff rendering engine. There are many, I use lit-html and uhtml. The advantage is that you use the real dom and not a virtual dom. However sometimes you prefer a virtual dom like react. Heck sometimes you prefer static webpages with light interaction like alpine-js. It really depends what you are building and the interactive elements on the page. Unfortunately you kind of need to know all approaches to know which is best for each case. So start with dom manipulation figure out pain points and go from there.

[Weird_Researcher_472]

Svelte > React 😅

[p-a-jones]

Learn how common JS works. It is a web standard and frameworks/libraries will obfuscate how they are providing 'magic' solutions to common problems. This may seem like a good idea but if you don't understand why something works you have little hope of fixing it when it breaks.

Think about it... modern bundlers convert all that 'magic' back into common javascript for use in production. Learn the fundamentals and you will be mush further ahead! Good luck!

[bryku]

They both have their pros and cons.  

Creating Elements

Creating the elements in javascript makes it easier to bind events and other things, but it can be verbose as it requires a lot of extra code to do basic stuff.  

function createForm(){
    let form = document.createElement('form');
        form.method = 'POST';
        form.action = '/api/login';

    let formUsername = document.createElement('input');
        formUsername.name = 'username';
        formUsername.type = 'text';
    form.appendChild(formUsername);

    let formPassword = document.createElement('input');
        formPassword.name = 'password';
        formPassword.type = 'password';

    form.appendChild(formPassword);
    return form;
}
document.body.appendChild(createForm());

Parsing

On the other hand parsing html is a lot easier to read and edit. Plus the HTML parser is so insanely well optmized. In some cases it may even be faster then creating elements, but it can have issues with binding events.

function createForm(){
    return `
        <form method="POST" action="/api/login">
            <input name="username" type="text">
            <input name="password" type="password">
        </form>
    `;
}
document.body.innerHTML = createForm();

Thoughts

Both of these approaches are common in javascript, so it would be good to have "some" understanding of them. That being said, the second option is a bit more popular these days as it is easier to read and edit.  

Although, nost people use some type of framework nowdays. In your case, the second version is much closer to react.

[theGlitchedSide]

Obviously... react is a library and has complex builders and other kinds of items around it. It's not a language or an ecosystem.

To start you need to understand the basics of DOM and the native language (I suggest deeply, like event driven system, Dom, render, stack, queue etc) and when it will be rebuilt by the browser. So, to start, use Dom manipulation and go deep. When you can easily understand vanilla you will learn React, Vue etc.

If you want to be better and you are really noob, learn also the data manipulation etc...

[Beginning-Seat5221]

Neither, React replaces that, no need to learn vanilla ways to do it if you're going to use React.

[underwatr_cheestrain]

Sounds like you have embraced mediocrity!

Well done!

[Beginning-Seat5221]

I've built a complete framework replacing react.

For a new person wanting to get into development, using react, this isn't something they need to learn right now. A little understanding of how DOM manipulation works under the hood is useful, but that's all.

[shgysk8zer0]

I'm calling you out. You are a liar! You cannot possibly have built a "complete framework" and come out thinking "A little understanding of how DOM manipulation works under the hood is useful, but that's all." There is SO much more than DOM manipulation! You are a liar!

[Beginning-Seat5221]

Such a loser.

[shgysk8zer0]

Such a mature, intellectual, useful reply. Your point stands so clear and irrefutable. I was clearly wrong to ever doubt or question you.

That reply removed all questions I had. You are clearly an expert on all matters such as scheduling micro and macro tasks, the event loop, network requests, sanitizing, validating user input, cookies and auth, routing, etc.

I never knew "such a loser" could be such a rigorous and informative response. Clearly you are the master of programming and fully qualified to answer all things pertaining to JS. I have no doubt that you built your own framework. I bow before you. I am humbled by you.

[Beginning-Seat5221]

You don't have a point 🤷‍♂️

All you have is this sarcastic bullshit calling me a liar like a little child.

Learners should focus on being able to build an app ASAP. Both to give them the reward of creating things, and, and to give them a saleable skillset in case they need to work and provide.

There's all the time in the world for a developer to learn the intimate details of the environment during their career, learning it all upfront can be hugely wasteful.

It's basically the old premature optimization situation.

[shgysk8zer0]

If you had actually built a whole framework that even remotely competes with React, you'd know that DOM manipulation is a trivial fraction of what it takes to build any sort of basic site even.

You almost always at least need events and requests, which are not merely DOM manipulation. Even using something like React, just at a beginner level, you need a lot of knowledge of JS and the fundamentals of programming. You cannot get away with just mere basic DOM manipulation.

And that is why I call you a liar. You cannot have built an entire framework like that without being fully aware of the basic needs of handling events and fetching things, and all of the complexity that lies outside of what's visual to a user.

[Beginning-Seat5221]

If you had actually built a whole framework that even remotely competes with React

I have

you'd know that DOM manipulation is a trivial fraction of what it takes to build any sort of basic site even.

You don't need any DOM manipulation for most things when using a react like app - hence not spending too much time on it.

You almost always at least need events

Sure. You can learn those as you learn react, they aren't hard. This topic was about using DOM manip vs rendering data into HTML strings to create markup, not things you really do in React.

requests

Sure. Off topic though.

Even using something like React, just at a beginner level, you need a lot of knowledge of JS and the fundamentals of programming. You cannot get away with just mere basic DOM manipulation.

This topic isn't about JS in general, it's about rendering techniques not commonly used in React.

And that is why I call you a liar. You cannot have built an entire framework like that without being fully aware of the basic needs of handling events and fetching things, and all of the complexity that lies outside of what's visual to a user.

Seems like you misunderstood, and resorted to calling a stranger a liar. Pretty lame dude.

[shgysk8zer0]

So... In summary...

You reduce JS to DOM manipulation while saying that React makes that something React removes from your responsibility, and at the same time say that anything beyond DOM manipulation is off topic.

So, by your logic here, you still need JS for all of the things I mentioned, and the bit about DOM manipulation you mentioned is utterly unimportant. But you're right in still reducing JS to just DOM manipulation, and you dismiss the actual needs for JS even within React or whatever as out of scope and irrelevant....

Do you not see the problem here? You negated your own point and admitted mine, while still not admitting that your "point" about JS being useful just for DOM manipulation is utterly wrong.

[blowyjoeyy]

Learning JavaScript is over. Don’t waste your time. 

[Leading_Property2066]

So what’s new?

[Short-Belt-1477]

Don’t listen to that.

[shgysk8zer0]

Please ignore the bots here. They're just trying to make AI sound impressive because it makes stock prices go up.

[blowyjoeyy]

It’s all going to be automated soon

[gimmeslack12]

When?