This is what Angular does, where an Angular component is typically rendered as a custom tag. I find it to be one of the (very) few nice things about Angular, as it can be helpful to track down components in a large codebase. I haven’t used React for many years, but makes me wonder if custom tags as a convention would be similarly useful.
Great nostalgia! I fondly remember QuickBasic, and how excited I was to compile my BASIC code. And the rarely mentioned gem I thought was amazing at the time: Visual Basic for DOS!
All true, but glosses over a lot of nuance and wide variety of contexts, particularly B2B.
We’re likely going to switch to Cognito because maintaining OIDC auth has been a pretty big cost for a small company. IdP configurability in particular is painful both technically and in customer support.
One downside to Cognito/etc though is while they’ll handle the tech side (Okta notwithstanding), it’s still up to you to troubleshoot and configure and integrate correctly. Lots of opportunities to “solve” the security risks, but hurt customer and user experience in the process.
PDF processing seems like a security minefield. What are folks doing to mitigate that problem prior to (or as part of) processing? Or as part of any system that accepts PDFs with the intent that they’re shared with other systems and users.
Nice overview, especially for those of us working long term projects and locked into whatever framework the originals devs chose. I wish I had time to try all these things out, but it’s tough to keep up.
Interesting that angular, and especially angular 2, only gets a passing mention.
This seemed like a really great explanation. But I have no idea if it actually is, or it if it just feels that way because I finally have some Haskell coding time under my belt.
Regardless I enjoyed the read and found it a useful way to think about monads
This has absolutely been my experience as well. The one thing to be careful about is losing sight of the content while making it entertaining. I've swung a little too far a few times, and risked my tech talk looking more like a standup routine.
I’m all for culture of writing, but that feels too easy.
Like another pointed out, what about a culture of reading? And further, what are these cultures of writing doing to help individuals improve their writing? Understanding audience, valuing brevity, tone, structure, knowing when not to write, etc are all important skills that the vast majority of people in business (probably including me) lack.
Further, writing takes time. How do you evaluate what writing is worth it, that the time you take away from e.g. coding still adds business value? It certainly may, but that feels very hard to quantify.
I’ve always felt that quality of writing is one of the best signs of a good candidate for hire, well before tech skills, and is something I factor heavily while hiring. But now that you mention it, our candidate projects generally are just code focused plus discussion, which is unfortunate, and probably worth revisiting.
I could rant for a while, but a few things off the top of my head: over-architected, overly complex, sometimes bad tooling (karma, protractor), tons of old issues (though they’ve been working to clean this up lately), big time inner platform effect (the templating feels like a language to itself), slow compilation, RxJS is generally overkill, Reactive forms is untyped(!) and clunky, and the “included batteries” are sometimes later removed leaving you to figure it out yourself, such as with protractor and eslint. If I’m just gonna figure it out, why not use React anyway and get a much simpler framework?
That said, for a team or teams with lots of apps where a consistent structure provides real benefits in getting up to speed, I can appreciate that some of angular’s enforced structure could be helpful.
I think I’ve reached the point where I simply don’t mention most nits. I’m most business software it just doesn’t seem worth it. If the code works, isn’t utterly obtuse, and abides by automated formatting etc, then is the nit really worth it?
Granted I’m probably biased towards high churn SaaS apps, which is what I work on.
Funny to see these new incarnations of the old ASP.NET UpdatePanel. I despised WebForms back in the day, but always had a soft spot for the UpdatePanel, seemed like a great idea. Especially when the alternative was manually building and managing UI on the client using ASP.NET AJAX.
I’ve noticed that often this is an area where WIP is not limited, and the efforts are least likely to be well managed and documented (unsurprisingly, it can take a lot of work to keep up).
I’ve also noticed numerous long term migrations that don’t tie back to a strong long term value proposition. And when the claim is that it does, it’s often just overly optimistic gazing into the crystal ball. Just as dubious as multi-year product roadmaps, for most businesses a ton of unpredictable things will occur.
IndexedDB on Safari has had issues it feels like since day one. IIRC there was a full rewrite somewhere along the way too, and still problems seemingly every Safari release. My favorites were the iOS upgrades that simply deleted all IDB data.
Super frustrating, makes me glad I’m not currently building anything that relies on significant local storage.
The web could fill so many needs instead of using apps, but with crap like this it’s no surprise that it still doesn’t.