4 ms·
Great work guys, but correct me if I am wrong but it seems the reasons you decided to build Deku (if I am understanding what you have written) did not seem to b
by DigitalSea 11y ago
Great work guys, but correct me if I am wrong but it seems the reasons you decided to build Deku (if I am understanding what you have written) did not seem to be anything other than you were not a fan of how React doesn't take a completely functional approach to building components. Is that an appropriate assumption to make based on what you have written in your article?
I feel a little disappointed to be honest. Because as I was reading, I was expecting to read that you somehow had created a dom-diffing algorithm and matching library that was more performant than React.js, but really it just came down to the fact you didn't like how React.js looks. I was rooting for you from the beginning, expecting to see someone had created something superior to the much hyped React, but it didn't happen.
I don't want to hate on what you've done, looking through the code reveals that you put some considerable effort into Deku, but it makes me wonder if that effort could have been spent on perhaps learning the inner-workings of React.js and adapting it to your needs in its own fork. But having said that, Deku to me only has a few slight differences to React.js, the way components are built in Deku in comparison to React.js doesn't appear to be that dramatically different.
I don't want this comment to come across as yet another cynical HN commenter, but I just cannot see anything comprehensively different to existing solutions. I hate seeing talented development hours going to waste that could have been used to make an already existing project better.
- jsprogrammer 11y agoSorry, but did you read the article? They claim a 38% performance advantage over "other frameworks", which I assume includes React. Even if the performance was at React's level, a first pass at Deku shows it as much preferable to React in terms of coder experience.
- jeswin 11y ago> Deku to me only has a few slight differences to React.js This framework is genuinely different from React in how you use it. I know several JS programmers who prefer functional style, yet choose to incorporate React-style classes because React is really good at what it does. This gives them an alternative. The components built with Deku will be different in programming style. And that's really, really significant.
- fiatjaf 11y agohttps://github.com/Matt-Esch/virtual-dom/ https://github.com/Matt-Esch/virtual-dom/
- malandrew 11y agovirtual-dom is excellent. Also check out mercury: https://github.com/Raynos/mercury https://github.com/Raynos/mercury Or better yet, fork mercury and modify the index.js file and package.json. It's a bunch of libraries masquarading as a framework (which is awesome because it means it's modular instead of monolithic)
- fiatjaf 11y agoWhat do you say about https://news.ycombinator.com/item?id=9529457 https://news.ycombinator.com/item?id=9529457?
- Scarbutt 11y agoReact is really much more than just some virtual dom implementation.
- meric 11y agoHave you heard of omniscientjs: http://omniscientjs.github.io http://omniscientjs.github.io? It allows you to use react in a functional style.
- chime 11y ago> I hate seeing talented development hours going to waste that could have been used to make an already existing project better. They didn't go to waste. They made Deku and learned a lot along the way. Just because something exists, doesn't mean you can't build your own. And not everything has an immediate, positive outcome. I wrote my own MP3 Player back when Winamp really whipped the llama's ass. That got my name in a local newspaper in India, which ended up being the small boost I needed for the Consul General to grant me a Student Visa to come to the US. A few years later, a fan of my MP3 Player messaged me and we became good friends. I interviewed for a job in Florida and ended up staying at his place for the weekend. A few years later, while I continued to work at the job in Florida, my friend and I built a scheduling webapp that made it to the front page of Wired during SXSW. An incredibly long list of positive things that happened in my life, I can track back to spending a week or two writing that MP3 player in my youth. If you ask me, I'd do it all over again. So I'm glad they build Deku, regardless of how it compares to React.
- filearts 11y agoReally awesome story. I agree with you wholeheartedly that there is always value in building things! There may or may not be value to other potential users or even to the employer though and these seem to be the only perspectives addressed by commenters. If the company's resources could have been better spent elsewhere than that is the company's (and its stakeholders') problem. Please stop discouraging others from creating and sharing because you don't find the creation better or worthwhile right this instant.
- burntcaramel 11y agoI think also the fact that Deku has a smaller file size than React.js is significant (10KB vs 118KB). That would have been more difficult with a fork. If Deku looks solid enough I might consider using it. And hopefully it can influence React too.
- mattdesl 11y agoI am not invested in either framework but there are some very clear differences: - size/complexity: React is a monolith that can't be digested by just skimming a couple small files - API surface area: less room for major semver bumps - modularity: React devs seem to fear dependencies - versioning: React encourages the use of peer dependencies which is truly going to be a nightmare in 2 years with hundreds of UI modules across different conflicting React versions - no singletons: React can only be required once, otherwise bats will fly out of your computer. This is compounded by the versioning issue. - style: React uses and encourages a different programming paradigm
- throwaway1979 11y agoI'm disappointed for a different reason. I'm just sick and tired of the delta new thing. Frontend dev as it is practiced today is horrible ... libraries and frameworks seem to have shelf lives measured in months! I was watching a video posted this morning (how NYT uses Go) and the dev was mentioning how challenging their system used to be with different languages - Python, PHP, Java and Groovy ... so they decided to redo major chunks in Go. Seriously? I don't pretend to have the answer ... stopping to innovate isn't going to cut it. But I increasingly feel that as a tech worker, I'm on a train careening towards a ravine without a bridge. But hey ... lets go faster and it'll be a fun ride!
- geon 11y ago> libraries and frameworks seem to have shelf lives measured in months! What "shelf life"? If the library works for what you app needs it to do, there is no use by date.
- vorg 11y ago> their system used to be with different languages - Python, PHP, Java and Groovy ... so they decided to redo major chunks in Go. Seriously? Valid reason for a rewrite, especially considering the quality of one or two of those languages. A language can look and run OK when used for a script calling system code, but when those scripts are glued together and become the system, all sorts of problems can manifest. It's only sensible someone there looked at the sit and planned out a replacement.
- kuschku 11y agoBut Deku gives them the advantage of not being bound to possibly devastating patent licenses.