As a frontend engineer who started 15 years ago, learning the box model required a lot of knowledge of the internals of the browser. The times of having to know things like quirks mode, abusing overflow hidden [1], how to break the behavior of float, etc are long gone. This is great both for us having to struggle less, and for the newer generations to be able to tackle harder problems than just layout and build cooler stuff.
> I am convinced that if react really wanted to, they could make optimizations to make it really close to svelte
Facebook has been working for a while on Ahead-Of-Time compilation for React. Interestingly, it looks like they thought the problem was too complicated and they gave up:
> To address this challenge we initially experimented with one approach to ahead-of-time (AOT) optimization — Prepack — but ultimately that direction did not pan out. Specifically, we realized that many AOT optimizations don’t work because they either don’t have enough global knowledge or they have too little. For example, a component might be static in practice because it always receive a constant string from its parent, but the compiler can’t see that far and thinks the component is dynamic. Even when we could make optimizations work, we found that they were unpredictable to the developer. Without predictability it was hard for developers to rely on them.
Browser differences are mostly disappearing, they have gained some very good APIs are CSS has gained significant layout capabilities with grids and flex. So the need for libraries like jQuery for dealing with DOM differences is disappearing. New standard libraries like Intl and now Temporal make libraries like Moment obsolete.
The web is also gaining a component model with Web Components that will help you get some level of sanity when building some mildly complex reusable stuff. This is probably very good for content heavy sites, which make the majority of the web.
The other part of the web is applications running on top of the Web platform. Those still heavily benefit from frameworks. Having some amount of sanity when managing state is very much welcome. And functional programming models have proven that a declarative way of approaching UIs is much better than dealing with browser APIs imperatively.
So for some years frameworks will still be useful for certain use cases. For the others, we should be embracing Web technologies. Maybe with some light libraries like Stencil and Catalyst.
You don't need a zoned date. You can invert the question and ask if a zoned datetime falls within a plain date.
Temporal is very well designed thanks to building on years of prior art. Give it a try and you'll realize that it leads you to ask those questions the right way.
Just like if you take some extra Zinc (30mg-50mg picolinate) for a variety of reasons - you have to take a bit of copper with it, or eventually your copper supplies will be drained and start causing issues.
I’m not 100% sure if it was zinc but I supplemented zinc for like a week then had the worst constipation of my entire life. Like, wife had to run to the pharmacy to resolve it while I cried in agony sort of bad. So yeah, be careful with how you supplement!
we use GraphQL for this purpose as well, but I'd also like to be able to validate across other boundaries.
However, as I'm saying this, I wonder if I've been looking at this problem wrong. Since we already generate types from GraphQL schemas, maybe I should figure out how to use the same client side parser that's already in my GraphQL client, define a GraphQL schema for the types I'm interested in, and then just generate and use those types.
One thing that doesn't necessarily give me is the ability to define custom parsers corresponding to custom types. At least, I think most of that sort of thing is usually done server side with GraphQL.
So, thank you for the link and also the inspiration for considering an alternative.
Highly debatable. In fact, trying to classify it as a dark pattern may derail the very valid discussion that the FTC is trying to have. There are significantly worse patterns out there. See [1].
What the push notification pattern is, is annoying. And it is specially annoying because of a prevalence of confirmation dialogs all over the Web with GDPR/CCPA, paid subscriptions, etc. But does it cause harm or monetary loss as the sneak into basket pattern? Or the opt-out unnecessary "insurance" that airlines continue to put in the checkout flow?
We do a disservice to ourselves littering the web with these constant asks. But it's not what needs regulation and enforcement.
The pattern tries to avoid an outcome desired by the user: permanently revoking consent for some permission. Only asking when you are confident the answer is Yes goes against the intent of the platform functionality, and I’d argue that’s a major dark pattern.
Similar to how apps used to ask “how do you like app?” And then only prompt to review the app if you responded favorably. Goes entirely against the app store’s intent to uniformly sample users, and I’m glad Apple at least has cracked down on this practice.
Just honestly make a product and stop trying to fool the user!
Like eBay asking over and over for me to trust the site for payment transactions. No, no. I have a separate paypal account with 2fa enabled rather than giving you my credit card for a reason. Asking 1,000 times will never change my answer, but eBay remains ever hopeful.
It’s a trick to try to take a yes / no choice and sneakily turn it into a “yes / ask me again later” choice. Silicon Valley in general seems to have a huge problem with the idea of user consent and permanently revoking consent.
It's not just about security. It's also about democracy. Who can verify that a voting system is secure? Only software engineers. And to be honest, only a small subset of them. Your own comment hints at that. Paper ballots allow anyone to verify the results of an election. It's supposed to be a universal process that everyone can be a part of.
The parent-child problem you mention can be addressed with names. Children can say "grid-name: footer". This is just a hint for the parent to decide where to place it in the grid. Then the parent can use grid-template-areas to arrange its children. You no longer need to change the children if you're adding columns to the layout.
As a frontend engineer who started 15 years ago, learning the box model required a lot of knowledge of the internals of the browser. The times of having to know things like quirks mode, abusing overflow hidden [1], how to break the behavior of float, etc are long gone. This is great both for us having to struggle less, and for the newer generations to be able to tackle harder problems than just layout and build cooler stuff.
[1]: https://css-tricks.com/clearfix-a-lesson-in-web-development-...