Lot of it was bad, sure, but there was so much games and animation done by literal kids back then, because of how easy it was to create something with the tooling. Nothing even come close today, unfortunately.
Same, I'm currently working more in React project, and I miss Angular so much that I actually use it in my personal project, it can be a genuine pleasure to use if you avoid over-engineering the rest.
React shines when it comes to the composability of components, eg. for data-table with customizable rows. It's still possible in Angular, but it's heavier.
For the rest (syntax, the ecosystem, routing, data-handling, DI), Angular is so much more straightforward. Services with dependency-injection is 99% of the time way simpler to reason about than React hooks, especially when you start to need cascading changes between hooks after user interaction.
Agree. RxJS is a beast to approach at first but it's a genuinely cool library, as long as you don't spread observable around when you don't actually need them. I used the same approach for a few years (pushing my http calls behind domain-specific api services that only return promise), and it's way simpler to handle.
I still use RxJS, but mostly in the top-level component and/or service who orchestrate between data, url state and api responses. Those top-level page usually keep the default change detection instead of the 'on-push' strategy).
As someone who feels stressed about not feeling able to finish the side projects I have (that is, working on my music player, learn Arabic, and learning to draw), this is a very refreshing take. Thank you for this.
I think the implication is that even though the technological landscape is evolving, it's not as if people born in the 60's couldn't foray into computer science because they arrived too late to study the ENIAC first.
I'm not sure why you're downvoted, but this is the right take IMO. I hate cheating and lying in general, but in any job posting you have to separate what are the actual requirement in term of knowledge versus what can be realistically learned on the job / doing a prototype in a weekend.
Of course don't fraud by like pretending you're a statistician when you have absolutely no mathematical background, but also don't take at face value the "Must have {x} years of experience in {y} tech" requirement when you know you have the necessary work experience to have a good grasp on it in a few weekend prototypes, and you also know that the job doesn't actually require deep expertise of that particular tech.
I did the same for my first React.js job, and I didn't feel bad because 1) I was honest about it and did not sold myself as a React expert, and 2) I had 10 years of front-end development, and I understood web dev enough to not be baffled by hooks and the difference between shallow copy vs. deep copy of a data structure, so passing technical test was good enough for it.
A few years ago there was a thread about "How complex systems fail" here on HN[1], and one aspect of it (rule 9) is about how individuals have to balance between security and productivity, and being judged differently depending on the context (especially being judged after-the-fact for the security aspect, while being judged before the accident for the productivity aspect).
The linked page in the thread is short and quite enlightening, but here is the relevant passage:
> Rule 9: Human operators have dual roles: as producers & as defenders against failure.
> The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense against failure role is emphasized. At either time, the outsider’s view misapprehends the operator’s constant, simultaneous engagement with both roles.
reply