Show HN: Under the hood ReactJS

Post by daliwali » Tue, Jul 04, 2017, 1:23 PM UTC

jchw wrote: post #60

daliwali wrote: post #58

Earlier quoted context omitted.

A paragraph of well thought out text will be ignored. A critical remark on the web framework du jour will be carefully deconstructed, rebutted, and shamed. Funny how that works.

Well for one thing, I really think you're taking this a bit too personally. I don't think anyone here is intending to 'shame.'

Post by Ralfp » Tue, Jul 04, 2017, 1:32 PM UTC

aaron-lebo wrote: post #61

Ralfp wrote: post #51

Earlier quoted context omitted.

I am sorry but this sounds like Dunning-Kruger effect on your part. You have created library that you think the problem, but which seems to have limited adoption in the wild. What experience in the field you have? Have you wondered how much you don't know about problems and scenarios that view layer has to handle? I've been in same situation once with my OS project. I've did something small that I've been certain doe…

But React is bloated. Check it out in comparison to something like Mithril which does everything it does and more in a much smaller and faster package.

Post by aaron-lebo » Tue, Jul 04, 2017, 1:36 PM UTC

Ralfp wrote: post #64

aaron-lebo wrote: post #61

Earlier quoted context omitted.

But React is bloated. Check it out in comparison to something like Mithril which does everything it does and more in a much smaller and faster package.

Last time I've checked Mithril it had no event normalization, JSX, scroll control and input state preservation. Does it have those now? I've did Mithril for 6 months year an half ago, before that Ember.js for two years and Angular.js for year even before that. I've eventually settled with React.js because it was just view library, with everything else up to you.

Post by daliwali » Tue, Jul 04, 2017, 2:13 PM UTC

matthewmacleod wrote: post #63

daliwali wrote: post #29

Earlier quoted context omitted.

These are marketing buzzwords that can be said about every single web framework, effectively thought-terminating cliches. Every fanboy says their preferred framework is the simplest, fastest, most scalable and most testable. In the car analogy the improved performance of modern cars have more to do with mechanical engineering than software. And the analogy falls apart when you consider that modern web frameworks are…

Every fanboy says their preferred framework is the simplest, fastest, most scalable and most testable. That's a way argument though; just because these are metrics on which frameworks are compared does not mean that there is no comparison possible. In fact, I'd say quite the opposite! And the analogy falls apart when you consider that modern web frameworks are invariably slower or roughly equal in performance to its…

Post by TekMol » Tue, Jul 04, 2017, 2:18 PM UTC

daliwali wrote: post #30

TekMol wrote: post #28

Earlier quoted context omitted.

I agree that React introduces way too much complexity. From a quick look at your approach, I have one concern: ... You seem to use classnames as variable names. What if some other template has a "name" variable too? What if a stylesheet uses it? I prefer simple placeholders. Instead of: I would use: {{NAME}}

Using class names was just an example, people may get the wrong impression that has anything to do with the variable name. It could have been made more explicit, but I wanted to be as terse as possible: It was also a design goal not to introduce a templating syntax, so `{{}}` brackets are out of the question.