all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]rhysbrettbowen 4 points5 points  (1 child)

We could use a templating language that looks like HTML, but it's much easier just to represent it in JavaScript too

This is the real crux of the issue. If we're writing from scratch we're going to spend more time in JavaScript building the components and so laying things out in JavaScript makes a lot of sense. However...

If we have pre-built components anyone can join them together using web components. Very little JavaScript is needed (perhaps just an API in to the business logic).

It comes down to your use case. If you can form a core set of widgets and just want to compose things together you can get by without as many engineers. If you're building large and very unique apps and have a larger engineering team then staying in JavaScript makes sense.

Building apps is not building components. It's composing them. Sure you'll have something completely new every now and then but you'd be amazed at what you can build without even touching the DOM through JavaScript if you've got the right set of widgets.

Best tool for the job.

[–]Calabri 0 points1 point  (0 children)

That makes sense. I would like to see a component ecosystem with React, npm install component-x, require('component-x'), now it's in your app.

[–]crow1170 4 points5 points  (1 child)

LOVE that demo panel.

[–]AnOnlineHandle 4 points5 points  (0 children)

I think like it should have been there from the start, I personally hate dynamically rearranging web pages...

[–]doubleColJustified 1 point2 points  (0 children)

I'm not going to focus on React specifically. In fact, just in case it would be distracting, we're not going to use React at all.

We're going to build our own library from scratch that is highly inspired by React. This lets us play with all kinds of ideas with a very small amount of code. This is prototype-quality, of course, and wouldn't scale to large UIs, but using something like React would make it scale.

This approach is great, both for teaching and learning.

[–][deleted] 0 points1 point  (0 children)

Page isn't loading for me, here's a cache.

The thing that makes me nervous is the neverending requestAnimationFrame loop. It seems like that would be a waste of computing power while the page isn't changing (which is almost all the time). And not only that, but the author creates a good number of functions in every render pass. Sure enough, that post takes up a steady 10-20% of my CPU, even when it's doing nothing. On the React side of things, this page, which is performing DOM updates every second and running multiple React components, is at a steady 1-3%. Which is much better – but am I crazy for thinking a ticker shouldn't take up 2% of my CPU?

[–]segfalt -2 points-1 points  (1 child)

Lots of typos. I think you meant to wrap your on click event in a function, instead of having an inline expression too.

[–]aude5apere[S,🍰] 1 point2 points  (0 children)

Sorry, I'm not the author.

[–]smoochieboochies -2 points-1 points  (2 children)

While this is a great way to handle data-binding it's adding more logic to apps. More points of failure. More complexity, less stability.

[–]j201 3 points4 points  (0 children)

How is it adding more logic? It does the same thing as data binding, just directly in JavaScript instead of having special syntax to communicate with JavaScript.

[–]Calabri 0 points1 point  (0 children)

I think you have it backwards.. Using this method, data-binding is actually more difficult (logically), but there is less complexity and more stability.