React vs Vanilla JS

Hello Campers,

One quick question regarding React vs Plain ol’ Vanilla JS. Currently continuing to learn JS in general, when I came across vanilla js, Developers often added injected styles and JS to the HTML markup mixing code like a spaghetti. As things move faster organization was a key ingredient for well usable code. so developers came to a solution of doing separations of code/files, meaning you have your HTML file, your Styles file, and finally your well-organized js file a more clean way. So this will make sense for a good workflow. But then not a few years ago a new kid on the block came to play (REACT JS). A faster render approach. Just started to see just the insides but not diving too much into the lectures, just by seeing the pick of the iceberg I notice React started to mix code as well… what? meaning HTML/CSS/React JS all in one file. I started to see why are we looking back again in time. when you can work will full separate files as we used to?

Do I get the picture or any of you have the same thought or questions regarding this? Can someone explain if is worth trying or just keep learning the good old way?

Thank you so much. Looking forward to any opinions/suggestions.

It’s not faster per se, that’s not really the point. It can be more efficient, and the underlying general model means it is generally much easier to deal with complexity, and a declarative approach means it can be much easier to build and test applications. But it makes no guarantee of being faster.

Yes, that separates code/files, but it does not really seperate concerns, or functionality. HTML/CSS/JS that relates to the same piece of UI functionality can’t, in reality, practically be seperated. So all you’re doing is putting it in separate files. That can be helpful, but it doesn’t by itself make anything more organized or cleaner. Organisation by concern is equally valid.

Also React doesn’t mix HTML in: JSX is syntactic sugar for JS function calls, it isn’t HTML or an HTML templating language. It doesn’t mix CSS in unless you use a CSS-in-JS library (ie a way of dynamically generating CSS). Those are not a thing that is specific to React, or frontend frameworks. Also, nothing stops you just using a separate CSS files.

React is a UI library for JS: it’s just JS. It has a small API, and for SPAs it (or a similar library) means that you don’t need to write the boilerplate code you would need to if you just wrote it yourself using plain JS with no library. It does allow use of JSX, which is where you’re getting HTML being in the same file. Except (aside from it not being HTML) an SPA just written using browser APIs would be often be doing the same thing, but injecting HTML via strings in the JS files using browser methods like innerHTML, or using HTML templates, or using web components, or some combination thereof.

2 Likes

That’s a good point.

I see not that many goods pros for separating based on file format (html, css, js), because you can create your DOM objects both in HTML and JS.

Thinking in components makes a lot more sense to me how we code for the web nowadays. A component has content, styling and maybe some interactivity.

How we deal with this per component depends on the library and personal preferences:

  • 1 file (Vue)
  • 2 files (React with CSS/SASS)
  • 1 file (React with CSS-in-JS)
  • 3 files (HTML, CSS, JS)

Structure is just a tool to handle complexity. E.g. if you add testing, you can put the test to the component or have a __test__ folder.

I like the idea of “just abstract (= separate into new component) if you can’t handle the current complexity anymore.”.

This means I start with app.js and build everything there. If it feels to clunky, I separate out the stuff. Because too many tiny components can also increase complexity (“Where does this thing live?” + need for good naming).

3 Likes

Your correct in being suprised in React’s approach to web development looking very different than traditional web development, that traditionally had clear separations of concerns. Instead React’s approach focuses primarily on the idea of a component, which can be seen as a block of the application’s functionality. (including HTML/CSS/JS) This component idea contained all the previous concerns, except on a smaller scale.

Mind you, this “component concept” isn’t unique to React, it actually exists and is fundamental to almost all of the modern web development frameworks.

With this approach its usually easier to isolate and focus on these individual components, rather than needing to understand the entire application as a whole. This is very important if your application gets very large and complex. Where understanding the entire application is essentially impossible.

Classically the idea of having a web app that is to large for a single person to understand didn’t seem that reasonable. Except now, with so much being moved to the web, its more reasonable to assume you don’t actually understand every single tiny detail. This is especially true if you start leveraging frameworks and libraries, and start building large and complex applications using the web.

I consider it important to understand what the “good old way” is, and how it works, its advantages, and disadvantages. This way later you can understand what your giving up if you take a different approach.

Modern web development is rather “far removed” from the raw underlying features of the web. Generally the code you write Isn’t the code rendered to the end user. Odds are you write some code that gets transpiled/bundled/minified in some way or form before it gets to the end user. As such, “the good old way” **still exists, your just not dealing with it directly.

The end goal here is to give as much power to the developer, while making the end user experience the best. Almost every design decision with these frameworks goes with this thinking.

2 Likes

Thank you so much for your explanation, and now I understand a bit more, maybe I need to do more research in React JS in a more deep scope. What i mean by mixing is by looking at this small code of a todo list.

class ShoppingList extends React.Component {
  render() {
    return (
      <div className="shopping-list">
        <h1>Shopping List for {this.props.name}</h1>
        <ul>
          <li>Instagram</li>
          <li>WhatsApp</li>
          <li>Oculus</li>
        </ul>
      </div>
    );
  }
}

By creating a class and adding a return that will return a ul list items, an html tag. At the same time, we have a div with a classname ’ shopping-list’ . So this tells me we are doing one file. Having HTML/CSS/JS.

In the old way, we clear the HTML/ CSS and js each in its corresponding class, with exception of JS, when we want to append we can do 2 things we either create elements to display in the DOM or create a template literals/Backticks or create an innerhtml or appendChild/insertAdjacentHTML.

parentDiv.innerHTML += '<div class="content">' +
    '<h1>Welcome</h1> '+
    '<p>Lorem ipsum dolor sit amet, consectetur  ' +
    '</p> ' +
  '</div>';

});

Hope I’m not confusing you on this, just that I have questions and concerns. What will you recommend best Plain Vanilla JS or React JS?

You make a good point there, 1 file with CSS in JS makes a component more ideal with more options in one file. I know this new framework will simplify things more easily for more robust applications. But in my mind i feel we are doing a bit of spaghetti when it comes to JS and HTML in the same file, maybe I need to get used to the new tools and options out there. Thanks for the reply and great study case. I leave a link for any more comparisons in react and plain vanilla.

Thank you so much for your feedback and now I understand a bit more… by doing a more easy way and for developers to understand the whole code or application will be more efficient in the end. Focusing on individual components makes more sense now. Just that the whole concept of adding in the same file HTML/CSS/JS was something I wasn’t expecting since we want the developer to know a well-orgazided code. I do think it has good advantages I do believe that, but leaving the good old way will be hard since I’m used to it and leaves in me and I want to keep working on it like many developers here in the forum. Thank you so much for your advice, and I understand at one point I will have to learn a new framework as companies will love to have new tools to develop applications. Thank you so much for the feedback helps a lot.

There isn’t a distinction. It’s not a “new way of writing JS”. It is a JS library for building Single Page Applications. You need to know JS, because it’s JS.

If you want to make something in a browser that works like a desktop application (or simply something that reacts to data coming into the app and automatically re-renders), you can’t normally just make a website, you need to use more JS. And the more apppication-ey it is, the more JS you need to use.

You could write all of that JS yourself, or you could use a library that someone has already written (eg React) and just write the JS you need instead.

And “SPA” literally means a single page, a single HTML page. You still need that with React, if it’s being used in a browser it can’t do anything without that HTML page.

How is this different? You’ve mixed “HTML” into the JS. Except it isn’t HTML, it’s a string. If I use JSX, I’m doing a similar thing (though it isn’t React using the DOM APIs). Except with JSX, I’m writing something that looks like the end product rather than a string, and it’s all just JS.

Okay so:

  • it’s not returning HTML, it’s returning this:
React.createElement("div", { className: "shopping-list" }, [
  React.createElement("h1", { name: ....
  // ....etc etc, for every element
]);

That builds/alters an object that represents a DOM structure. To render HTML, you use a different library (ReactDOM). Or to render to native use a different library (React Native). Or to render out Windows native apps use the MS library for that, and so on.

What you’ve written as JS is going to basically do the same thing:

parentDiv.innerHTML += '<div class="content">' +
    '<h1>Welcome</h1> '+
    '<p>Lorem ipsum dolor sit amet, consectetur  ' +
    '</p> ' +
  '</div>';

});

Then say you put it in a function:

function Post ({ title, bodycontent }) {
  return `
    <div class="content">
      <h1>${title}</h1>
      <p>${bodycontent}</p>
    </div>
  `;
}

parentDiv.innerHTML = Post({title: "Foo", bodycontent: "Loren ipsum foo bar baz." });

And you can keep going with the abstraction, and eventually you’ll end up with something like React.

  • className is the same as class. When HTML is eventually rendered that’s what it becomes: <div className="foo"> becomes <div class="foo">. I’m not quite sure how that translates to the CSS being in the same file, it’s literally the same as it works in HTML.

EDIT: there is a way that CSS can be imported into the React component files, but this isn’t a React thing, this is functionality inherited from the JavaScript tool used to bundle things together. This can be done with any kind of JS code that makes use of tooling that supports it. What it’s doing when the tool runs is just finding any CSS imports (which aren’t valid JS), locating the CSS file that they refer to, removing the import statement from the code so that it’s now valid JS, and joining all of the CSS files together into a single CSS file. Sometimes it does other stuff, like append stuff to the names of classes to make sure that the CSS imported in the component applies only to the elements that the component renders. Sometimes it doesn’t. But this is all a tooling concern – it doesn’t have to do with React, it’s just tools for constructing JavaScript-based applications.

3 Likes