31–40 of 55 posts
Back in the jQuery days, a lot of my hatred towards "JavaScript" was actually imperative UI code in hindsight. In the years since, I now enjoy declarative UI more but see some developers bang their head against declarative UI frameworks. It's an interesting contrast.
Earlier quoted context omitted.
I have to strongly agree with this. The entire point of react was to avoid all the challenges of old imperative coding of syncing up state with render state. The Dom digging was an absolutely genius idea to stop that nonsense and just render the correct state and let the framework handle the rest. I wrote a ton of backbone code, and was a major fan of jquery before Dom querying was even a feature of browsers. And onc…
Same, used jQuery for years and had a love/hate relationship with it. You're correct that React solved the imperative problems from before, but that's not the only factor to consider. You have to weigh the problems it solves against the problems that it causes.
> The structure of your application state ends up being shaped by the UI, when it should be the other way around I don’t understand this premise at all. Are you saying your UI should be shaped by your application state? That doesn’t make any sense to me, surely the application state exists to implement a desired UI?
To respond to your last statement though, I feel the opposite is true. UI's don't exist for their own sake, they only exist to support the application and its behavior.
That's one of the main points of templating in the first place: to write the code for a piece of output once, with all of the bindings that can affect it.
What happens here if you update the JSX for an element in one place and forget to do so in the others?
Thanks for sharing, neat. This makes me curious about the psychology of declarative vs imperative, and why some people gravitate towards one or the other (at least with UI code). Back in the jQuery days, a lot of my hatred towards "JavaScript" was actually imperative UI code in hindsight. In the years since, I now enjoy declarative UI more but see some developers bang their head against declarative UI frameworks. It'…
Like I love being able to just write
hello world
in my javascript, it feels very nice. At the same time, with React I absolutely hate it when I do things that are inherently imperative.A prime example is the following: I have a list of items that can be named by the user, so each item's display name will be a text input. When the user clicks the "create new item" button, a new item is added to the list, and the text input of the new item is immediately focused as soon as it's added to the DOM.
^ doing this in React sucks.
Mithril seems like it can do something pretty similar: https://mithril.js.org/jsx.html (Not trying to discourage you, just linking it)
JSX without React is also kind of fun: https://medium.com/@victor.dramba/can-you-do-jsx-without-rea... and it's working example at: https://github.com/dvictor/jsx-no-react/blob/master/index.ts...
Agreed! About 5 or 6 years ago I wrote a library to demonstrate to my teams that JSX a) was not magic b) not limited to React. After that was done I became a little obsessed with making the library the fastest JSX renderer - which I think is still true: https://github.com/i-like-robots/hyperons
I used this approach to make a syntax highlighted text editor in https://crwi.uk/experiments/text-editor/
Earlier quoted context omitted.
This is IMO a great example for React and declarative programming. > There's no special concept to understand By not understanding that you need to cleanup timers when your view unmounts, you've introduced a subtle bug that your coworker will discover in 6 months when users report that the counter sometimes increases twice as fast. I've worked on Angular-like apps before, and storing and cleaning up timers was always…
> By not understanding that you need to cleanup timers when your view unmounts I think this library eschews the entire concept of mounting so that point is kind of moot. Will you likely re-invent it again in any non-trivial app, sure, but when you're writing imperative JS it's probably a MPA where code runs top to bottom. Clean up will happen when everything gets thrown away on navigation.
Earlier quoted context omitted.
Agreed! About 5 or 6 years ago I wrote a library to demonstrate to my teams that JSX a) was not magic b) not limited to React. After that was done I became a little obsessed with making the library the fastest JSX renderer - which I think is still true: https://github.com/i-like-robots/hyperons
Add me to this club of JSX hackers: https://crwi.uk/posts/hiccup/ I used this approach to make a syntax highlighted text editor in https://crwi.uk/experiments/text-editor/
If you want to use JSX without React see this 500-line lib: https://github.com/wisercoder/uibuilder And here's an app built using this lib: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...