This is cool Guilherme, however my strongest reaction to these rewrites is always: why?
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.
> 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.
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.
Valid points, however I think most people would agree these things are important when you have multiple people working on a project. That's my opinion, anyway.
You learn a lot building something from scratch. And it's fun. You start with naive, clean abstractions and slowly encumber them with trade-offs as you make progress. That's a fun Saturday for a lot of us.
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.
Tks for your time and attention.
So, first of all, i think trying to rewrite something is the best way that i found to learn about it deeply, tEmbO is not my first rewrite, in the past, when I was studying angular, I wrote http://github.com/guisouza/abstractjs, and it was a very helpful in my learning process.
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 .
Thanks for the thoughtful response. I absolutely agree with the idea of rewriting to learn, so I suppose that was an oversight in my original post. Keep it up, and nice work on tEmbO.
I'm trying to understand the differences between this and React. It seems as though the emphasis is on the 4kb size, but I wonder if there are any other differentiating features?
The main difference here is that a 300 SLOCs code-base is easier for others to understand how it works, the react codebase has a lot of tricks and fallbacks and etcetera.
This project is for studying purposes.
The best way to understand something deeply is try to reproduces its behaviour.
I want to contribute to this but there are a few things holding me back.
- 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
14 comments
[ 3.1 ms ] story [ 37.9 ms ] threadI 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