But having built websites and apps since before jQuery times, I strongly disagree with manual DOM manipulation as an alternative. Declarative, component-based approach won for a reason. These frameworks allow you to tell how the UI should look based on the state and manages the transition (either via virtual DOM diffing or fine-grained reactivity) for you. DOM manipulation requires you to write some code for every single state transition (instead of every _state_). And, in practice, it becomes unmanageable very fast, and you give up, and start writing code like `element.innerHTML = ...`, causing problems with focus and event management. It's fine for small widgets, even enjoyable, but only until you need to manage a complex UI. Then, you end up with a mess of code that is hard to maintain and debug.

I know some still feel web is not the right platform for building complex UIs but that battle was lost more than two decades ago. Web is good. It comes with accessibility features (like zooming) and works everywhere. As someone with age-related farsightedness, I hate native apps that don't allow me to zoom in with a passion (which is, almost all of them). Of course I hate websites that don't allow me to zoom even more because they had to go out of their way to disable a basic browser feature. But getting decent accessibility is harder with native apps. You basically have to build everything yourself. Web gets you 90% there for free.

React might not be the best out there and might be, one day, replaced by one of the competitors or something new. But declarative, component-based UI development is not going anywhere.

Comments URL: https://news.ycombinator.com/item?id=48236239

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48221711

Points: 3

# Comments: 0

Hmm, are you sure about this? I thought chest voice and head voice were understood to be a single register called the modal register. And falsetto was fundamentally different.

[1] https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf section 6.7.3.2, paragraph 17.

Complex for humans: I can learn a new programming language in an afternoon and be reasonably productive in it within a week or two. I wish I could say the same for natural languages.

Complex for computers: We’ve had good compilers since the 50s. Satisfactory language models are less than five years old.

[1] https://sourceforge.net/projects/bin2c/

There was a time when we were hoping to “make it” and we did release an album but it wasn’t very successful, of course. That band broke up a few years later but I kept going with different bands.

I can’t do it every week anymore, let alone every night. It’s very physically demanding, so once a month is plenty in my age.

But it’s still fun. A lot of fun. I can’t imagine ever stopping it until I can’t physically do it. It’s part of who I am. Long live rock’n roll \m/

Comments URL: https://news.ycombinator.com/item?id=46172941

Points: 1

# Comments: 1

The decoder is the part of the CPU that maps instruction opcodes to a set of control signals. For example "LDA absolute" (opcode 0xA5) would activate the "put the result in A" signal on its last cycle while "LDX absolute" (opcode 0xA6) would activate the "put the result in X" signal. The undocumented "LAX absolute" (opcode 0xA7) simply activates both because of the decoder logic's internal wiring, causing the result to be put in both registers. For other undocumented opcodes, the "do both of these things" logic is less recognizable but it's always there. Specifically disallowing these illegal states (to make them NOPs or raise an exception, for instance) would require more die space and push the price up.

See here[1] for example to get a sense of how opcode bits form certain patterns when arranged in a specific way.

  [1] https://www.nesdev.org/wiki/CPU_unofficial_opcodes