Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Under the hood ReactJS

bogdan-lyashenko.github.io

Post reply on HN
Print view View original

111–120 of 124 posts

Re: Show HN: Under the hood ReactJS

#111

Post by daliwali »

always_good wrote: post #88
daliwali wrote: post #14

There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case. The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors ar…

You're being a bit dishonest in these posts. Maybe it's your marketing style and maybe it works, but it puts me off. I even see it in your landing page marketing. > MINIMAL > One function > Its entire API surface area is a single function Then I scroll down. var bindObject = require('simulacra') var bindEvents = bindObject.bindEvents var animate = bindObject.animate var retainElement = bindObject.retainElement

This has been revised. There is now a separate entry point for helpers, to make it obvious to people who don't read docs, that it is separate functionality:

    var helpers = require('simulacra/helpers')
    var bindEvents = helpers.bindEvents
    var animate = helpers.animate
There is no practical difference. It is just for those who read code but lack reading comprehension skills.

Re: Show HN: Under the hood ReactJS

#112

Post by daliwali »

TekMol wrote: post #102
daliwali wrote: post #89

Earlier quoted context omitted.

I'm not sure I understand what you mean by additional mapping. Here's all that's needed in the template: has residents And the mapping would be: [ 'city': [ '.city', { name: '.name', population: '.population' } ] ] If you don't want to manually define a mapping, you could do it automatically by assuming that some attribute like `data-bind` corresponds to a binding, but Simulacra.js doesn't make assumptions like that.

you could do it automatically by assuming that some attribute like `data-bind` corresponds to a binding Yes, that could be done. That would mean to extend Simulacra. Or do it outside of it. To me personally, {{NAME}} is easier to read and reason about. Also, it enables you to do stuff like {{CITY}} has {{POPULATION}} residents Which is much shorter then has residents You can also do other useful stuff. For example: {…

Sorry, but avoiding templating syntax was really a hard design goal. It may not be a tool for everyone.

The reason is that every templating language I've used either is or becomes a Turing-complete language by itself.

Re: Show HN: Under the hood ReactJS

#113

Post by daliwali »

Ralfp wrote: post #51
daliwali wrote: post #14

There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case. The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors ar…

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…

This is by the way, a thinly veiled insult. Citing Dunning-Kruger effect is just a way to call someone an idiot who thinks they are competent.

Nobody looks at objective benchmarks. My own DOM utility is faster than React.js, and in fact it is not such a difficult feat, there are a few DOM utilities which are faster, also authored by relative nobodies.

I don't worry about catering to IE8 users, neither do most websites, and that number is vanishingly small. I'm also not interested in competing on complexity, which is what happens when one preemptively builds for edge cases.

I will probably never work on a web app that has a wider reach than Facebook. Setting up arbitrary personal goals for success like working on "one of the busiest social sites in the world" and even achieving that won't make me any happier. How much is enough? I've already proven that I beat Facebook at the DOM performance game, and still I'm the Dunning-Kruger idiot.

Re: Show HN: Under the hood ReactJS

#114

Post by Vinnl »

jchw wrote: post #55
Vinnl wrote: post #50

Earlier quoted context omitted.

No, the main point was that it's > significantly nicer to code for than DOM binding There are other ways to code this nicely, but _those_ are slower than virtual DOM. Real DOM _can_ indeed easily be faster, but that's not nearly as nice to program for.

Simply saying "No" after a point and not rebutting it is not a good argument. A lot of people like to point out that the "real DOM" can be just as fast, but far fewer people have any good examples of this being done. Yeah, for making a button that signs you up to a mailing list or a simple SPA or something like that, you can just use the DOM. But if you have a complex app with a huge amount of data flow and many comp…

Yeah, we're agreeing :) "Real DOM" can be just as fast if you do all the work React does by hand, but it's bound to be a mess - resulting in the programmer making mistakes that makes it slower.

Re: Show HN: Under the hood ReactJS

#115

Post by TekMol »

daliwali wrote: post #112
TekMol wrote: post #102

Earlier quoted context omitted.

you could do it automatically by assuming that some attribute like `data-bind` corresponds to a binding Yes, that could be done. That would mean to extend Simulacra. Or do it outside of it. To me personally, {{NAME}} is easier to read and reason about. Also, it enables you to do stuff like {{CITY}} has {{POPULATION}} residents Which is much shorter then has residents You can also do other useful stuff. For example: {…

Sorry, but avoiding templating syntax was really a hard design goal. It may not be a tool for everyone. The reason is that every templating language I've used either is or becomes a Turing-complete language by itself.

What would force you to make your own templating language turing complete?

Re: Show HN: Under the hood ReactJS

#116

Post by always_good »

daliwali wrote: post #111
always_good wrote: post #88

Earlier quoted context omitted.

You're being a bit dishonest in these posts. Maybe it's your marketing style and maybe it works, but it puts me off. I even see it in your landing page marketing. > MINIMAL > One function > Its entire API surface area is a single function Then I scroll down. var bindObject = require('simulacra') var bindEvents = bindObject.bindEvents var animate = bindObject.animate var retainElement = bindObject.retainElement

This has been revised. There is now a separate entry point for helpers, to make it obvious to people who don't read docs, that it is separate functionality: var helpers = require('simulacra/helpers') var bindEvents = helpers.bindEvents var animate = helpers.animate There is no practical difference. It is just for those who read code but lack reading comprehension skills.

I'm not sure what that accomplishes.

The "entire API surface area," as you put it, surely includes more functions than the only one you need for a landing page's hello-world. I don't evaluate something like Simulacra with a hello-world in mind, else I wouldn't need Simulacra.

My advice is to just change "one function" to "tiny API". Or maybe "just three functions in the public API". That's just as respectable and spares you from needing to split your API into a pointless "helpers" namespace.

    const {bindObject, bindEvents, animate} = require('simulacra')
^ looks ideal to me.

Re: Show HN: Under the hood ReactJS

#117

Post by brlewis »

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.

JSX and input state preservation were already there a year and a half ago when you were using Mithril. It does not automatically normalize events, though I'm not sure how important that is in 2017. I don't know what you mean by scroll control.

Re: Show HN: Under the hood ReactJS

#118

Post by hardwaresofton »

rohannair wrote: post #69
hardwaresofton wrote: post #67

At this point I'm sure I and others sound like a broken record, but if you're new and just jumping into frontend component-based frameworks, please don't start with React. There are simpler ways to get reasonably fast re-usable components on your project that introduce less accidental complexity. Carefully consider which thing you actually need: - A view library that uses components as the main building block (this u…

React is a view framework, and knowing the internals of React is a completely unnecessary set of knowledge for the majority of developers using it to build products with.

As with anything, the longer you use a library, the more you must know at least some of it's internals to use it efficiently/axiomatically/well. Even something small like the class/className attribute thing is an implementation detail that leaked through, which will bite and likely confuse a beginner for 3 seconds if they didn't throughly read the docs.

Other libraries don't have that problem (because they didn't accept that trade-off in that fashion).

IMO Libraries that beginners should be shown should not be ES2015-in-every-example, and introducing transpiled DSLs for generating DOM elements.

Re: Show HN: Under the hood ReactJS

#119

Post by hardwaresofton »

simooooo wrote: post #104
hardwaresofton wrote: post #67

At this point I'm sure I and others sound like a broken record, but if you're new and just jumping into frontend component-based frameworks, please don't start with React. There are simpler ways to get reasonably fast re-usable components on your project that introduce less accidental complexity. Carefully consider which thing you actually need: - A view library that uses components as the main building block (this u…

I still love knockout. A simple view layer on top of whatever other architecture you want. Has worked really well for me for years.

Yep! One of my favorites (I didn't mention it because I didn't want to make it seem like I was just trying to push people towards another framework).

KO also has components now, and they work super great. Also, while bigger frameworks like Ember (which I love) are just starting to figure out and cement how they work with engines (dynamically loaded chunks of your ember app), KO supported async loading of components with RequireJS so long ago.

Re: Show HN: Under the hood ReactJS

#120

Post by hardwaresofton »

ivanr wrote: post #87
hardwaresofton wrote: post #67

At this point I'm sure I and others sound like a broken record, but if you're new and just jumping into frontend component-based frameworks, please don't start with React. There are simpler ways to get reasonably fast re-usable components on your project that introduce less accidental complexity. Carefully consider which thing you actually need: - A view library that uses components as the main building block (this u…

Perhaps you're right, but it would be useful if you mentioned those other choices here.

Sorry I actually purposefully didn't mention them because I didn't want it to seem like I was just trying to push my own favorite choice.

Here are some options:

Component libraries -------------------

1) KnockoutJS (just data-binding, quite possibly the simplest I've seen)

2) Vue.JS (More complex, but one of the best sets of docs I've seen, fits in with the DOM model extremely well, few hacks, though I would have loved a simpler data-binding system)

3) Mithril.JS (super small, super fast, very simple. Transpilation tradeoff, it makes you just write the DOM as a JS function with elements like `m('div',[...])`. Have yet to use this one for a large project, but will very soon. Also has a little bit more support for the other thing you might need for a Single Page App.

Full fledged frameworks -----------------------

1) Ember (has been around a super long time, changes fast which is good and bad, and is great for large projects because it has a solid set of conventions)

Post reply on HN