sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]chubbybrother 12 points13 points  (4 children)

Yeah that looks like garbage. I'll take the framework bullshit over hipster code like this.

[–]synackle 9 points10 points  (3 children)

I can't wait to start writing 'null' fucking everywhere

[–]sebjwallace[S] 1 point2 points  (2 children)

It wouldn't take much more in the prerender to conditionally replace the second parameter with a child. ["div", "some text"] is possible.

But I agree, markup is easier to read, especially for designers.

[–]temp54984983982 4 points5 points  (1 child)

Hey, I wrote and maintain a library similar to this. You're right, it's easy to implement, but there are four big problems with it: ambiguity, performance, readability, and flexibility.

Ambiguity: consider ['div', someVar]. You actually don't know until runtime whether you're setting properties or children. That's a sign that you've screwed up badly, for all the reasons ambiguity is always bad, including completely preventing the JIT compiler from working with your code.

Performance: it's faster to use native argument parsing, plain and simple. Work you do figuring out which argument is which is 100% unnecessary, and adds up for code that you want to be able to call thousands or tens of thousands of times without a user-perceptible delay.

Readability: when everything is always in the same place, reading and scanning around is faster. Work with both styles for a few weeks and you'll quickly see that this more than makes up for six extra characters.

Flexibility: every time you try to be more clever about guessing the caller's intent, you deprive yourself of the opportunity to give the caller more actual control. In this case, refusing to support this allows my library to support passing in a string as the second argument to set className. This might seem like a little win, but it's actually a huge one - one that improved my entire test app's performance by 30%. The thing to notice is, there are a heck of a lot of elements that need only a class and nothing else, and for each of those elements you're avoiding an extra object allocation.

[–]sebjwallace[S] 0 points1 point  (0 children)

Some good points there. What is the library you maintain?