How I converted my React app to VanillaJS | Hacker News Reader

How I converted my React app to VanillaJS

hackernoon.com

116 pointsbubble_boi29 comments

This is a very sane exercice to do, while obviously not something to recommend for production code - but I guess it's not the point.

We often take our tools for granted, without thinking about how they were designed. Doing such exercice allows both to get insights into the possible solutions for a problem one of our tools solves (allowing us to understand our tools better), and also is proper training for architecturing our own tools.

Thanks for sharing your discoveries.

And thanks for presenting it as an exploration and not the, "I am a real carpenter, so I don't use a hammer, I just pound in nails with my dick!" inanity a lot of these articles are.

Interesting read, although the shtick got a bit old near the end. I really wonder how this compares to inferno.js as that has some real optimisation magic to make it super small and super fast while also being, close to, compatible with React.

Nice work. Enjoyed the step by step process. Want to do something similar, but in an Elm style.

A fun read as well.

Can someone explain this interesting snippet?

  const h1 = () => makeElement(`h1`);

before you have to write

    makeElement(`h1`)

everywhere

after this declaration you can write

    h1()

instead

just a shortcut function

Sorry, it was the syntax up to the makeElement(`h1`); that I didn't understand:

  const h1 = () =>

Is this new syntax declaring a function named h1 that returns a function or what? I don't understand what the empty pair of parentheses means.

Yes, it's ES6/ES2015. It's a lambda function ("fat arrow notation"). In the parentheses you would specify the arguments. An empty pair of parentheses means that the function does not expect any parameters.

OK, thanks. So it is the parameter list, not the return value

Yes, this is a shortcut for:

    const h1 = function() {
      return makeElement('h1');
    }

Arrow functions without arguments need empty paranthesis.

They also have an implicit return if you don't use {}

To add to the other explanations: it's also important to point out that arrow functions are slightly different from regular functions in that they don't redefine `arguments` and `this` so these keywords behave like any other variable would in a closure.

So it's not just a syntactic shorthand but there's also a semantic difference.

This is declaring a constant and assigning a function that takes no arguments to that constant.

It Uses "fat arrow" functions (lambdas) to define function. It is "equivalent" (there are several differences here, like "const" and the context of the function) to:

   var h1 = function() {
     return makeElement(`h1`);
   }

Edited to reflect the valid point brought up in the comments

Ah, thanks a ton. Everything I looked up was too general to help!

Techinically you're missing a return.

Not really an equivalent, because "this" would be different - unlike with function(){}, there is no automatic this-context binding with arrows, so just switching to a fancier syntax in existing code may break things.

Also, no "arguments" (there are ...rest parameters that allow for variadic functions).

> no automatic this-context binding with arrows,

I thought the arrows were now binding to surrounding context? (e.g. https://babeljs.io/blog/2015/06/07/react-on-es6-plus)

It is equivalent in this case though, as the function body doesn't use any of those features...

This post reminds me of the book, Build your own AngularJS

It's a little old now, but still worth a read.

https://teropa.info/build-your-own-angular/

Creating frameworks by reversing the works of others is something I'd call art. I really enjoyed your article, and I'll surely use some of it for a personal framework that I'm currently writing.

Great work.

TL;DR : Even though ReactJS (or any other JS framework) is 'heavy', Web Devs still need them to be able to code in a sane way for real world products.

Correct. Self made framework is a good thing for pet projects and in terms of education. But if you work in a team on the long-term project it's better to use standard tools since there will be a need to expand the team and it's better new members are already aware of the used tools/frameworks.

More like, "How I wrote my own framework in VanillaJS"

Doesn't code automatically look like a framework when you structure it?

You can e.g. hide that fact within a DSL!

Thats just called software engineering.

Its not a bad thing when 95% of the code in your project is borrowed (i.e. when you use a framework), but ducktaping stuff together will only get you so far.

For the size of the example project (single dev, one day, single page) and the requirements (load as fast as possible) this would be the superior approach. React would indeed be overkill. And below 200ms load times has proven impact on conversions. That is: the requirement is realistic and commercially, if at all possible, not at all negotiable.

I guess I'm NOT the only person not sold on React/Angular. Unfortunately, all the companies hiring in my area are. :(

At the end of the article the author admits that while this is a worthy exercise and might sometimes be useful, using a framework such as react does have a lot of benefits.

"replacement" - not even close.

Reply on news.ycombinator.com