Show HN: My own tiny React-like rendering engine
github.com
github.com
I think as a portfolio piece there's something to be said about the value of showing that you can write your own rendering engine. But at the same time, if I was looking at this I'd just ask, "why is he building this when React exists?" If the only purpose is to mimic React's behaviour then I think this is not a great use of time.
This isn't to say what you've made here isn't very cool, and I think personally you should be proud of your work on this. But with that said, if you love React, why not help work on the core? I'm sure there are issues with React that need solving and if you've got the time your effort may be better spent on there.
Aside from that, when people keep seeing rewrites like this I think it instows a feeling of ambiguity around the capability of React "is everyone rewriting React because it can't get the job done well enough on its down?" the casual observe might think to themselves.
I think the same thing when I see new languages pop up. Why? These new languages look cool and people start using them. 5 years down the line they discover it has its own set of core problems like every other language, rinse and repeat.
I think as a community we need to work harder on being less distracted by the enjoyment of building something and try to focus more on improving and understanding existing technology. We can continue to push the envelope in the name of technological advancement but often times it's difficult to discern advancement from replacement.
Again, I think it's really cool that you've built this and I don't want to dissuade you from building cool things. I'm just a little tired of seeing React reimplemented over and over again with no real net gain that couldn't be implemented in React itself.
It's not that simple. One of the biggest critic towards the official React implementation is its big size, which is a direct consequence of the decision by the core team to include many "enterprise" features (IE support, safety checks, etc) to suit their needs. Some people like to make different compromise, e.g. more minimal one. You cannot easily change "political" decisions by contributing, also not all features are easy to modularize (esp. for outsiders).
Sometimes it's easier to implement similar API from scratch to test your own ideas than forking an existing (mammoth) project.
Btw, another "tiny react" implementation: https://github.com/developit/preact
this tiny react is pretty cool =D tks for sharing .
There's a massive difference between that and tackling some long-tail issue on a massive, mature project that apparently wasn't trivial enough or fun enough for anybody else to tackle. i.e. work.
Asserting they could've spent that time contributing to React is like suggesting they could've used that time volunteering at the homeless shelter peeling potatoes and doing jumping jacks. Energy and interest just don't work like that.
When I am doing these clones I aways remember these TJ words : https://youtu.be/wxDBF3OOaRA?t=2m58s
So even if I was planning to start contributing with reactJS core, my first lesson would be to rewrite something based on it.
tEmbO has just 300 SLOCs codebase, and its quite easy to understand what is going on with its tiny code, so I hope it could help someone that wants do learn how react works from the inside.
and last but not least, I love to CODE, I really really LOVE to code, and there are moments when I just want to write something without commitment, think of it like a football player, that after a match comes home and wants to play a little with his son.
thats why tembo is anarchist, he is just having fun, he doesn't care about testability, or his poor virtual-dom implementations, because it is just having fun .
- usage of global instead of commonjs or es6 modues - using an uncommon build system makes me uncomfortable
- _.can instead of prototype or just object creation - I cant say I understand why.
What I want to do
- allow it to use multiple renderers - toString, DOM, blessed with the goal of image output and webworker proof of concept
- give promise support to get Initial State - when attempting isomorphism in react, creating components based off a database is a pain unless retreived before hand and passed from parent to child in often disgustingly deep manners. Simply allowing the return of a promise fixes this in many ways