Conferences, Clarity, and Smokescreens
22 points by siddhartha_golu
22 points by siddhartha_golu
Whether or not you’re interested in frontends, I like the author’s approach to conferences:
…conferences succeed by foregrounding the hot topics within a community. Agendas are curated to reflect the tides of debate in the zeitgeist, and can be read as a map of the narratives a community’s leaders wish to see debated.
I mean, it’s kinda obvious?
Maybe? Is it? Nobody ever told me why conferences exist in such concrete terms, just “it’s where you go to talk about and listen to new research”, for scientific conferences. Certainly nobody’s ever explained to me how you make a good conference agenda. I’ve never asked either, so this is new to think about.
I was like ‘this feels like an Alex Russel rant’ and then I checked and it was!
I had to create a web component recently and that was truly awful (something called lit). So if that’s what’s being sold here, then I’ll give it a pass.
Maybe you would like to say what was so awful about and how the non-standard solutions are better for your use case
I really dislike the framing of “standard” vs “non-standard” when talking about web components, because it doesn’t make any sense. Frameworks are a standard solution: they output DOM nodes and Javascript, which are the standard building blocks of the browser, and because frameworks work with encapsulated components they can interop with each other just fine.
What typically isn’t standard is state management, and each framework has its own mechanism for handling state updates, deciding when to rerender, etc. It could be useful to standardise things here, but right now it’s not necessarily clear what the standard ought to be — each framework makes different assumptions, and therefore has different needs for state management.
But that’s also precisely the thing that web components doesn’t standardise. Web components have a very rudimentary event-based mechanism for detecting changes to inputs, but other than that, the expectation largely seems to be that you’ll bring in an additional framework (e.g. Lit) to handle state management for you. Which it does (albeit, again, very rudimentarily), but if even your standard system requires non-standard additional frameworks to run, what’s the benefit of standardisation there?
You’re entitled to dislike the framing. I do, however, use the term standard as what the browser accept as-is without the need for a compiler/transpiler in between and non-standard for the rest. I am not saying one is better than the other, I still prefer to write TypeScript over vanilla JS.
You bring a valid point regarding state management which is already orders of magnitude better than calling something “truly awful” without giving any argument.
If “standard” is just shorthand for “needs a compiler”, would you consider a framework like Mithril or an application written in React without JSX as standard? Or equally, would you consider an application written using web components and a bundler like Vite to be non-standard?
If that’s the case, then I’m not sure what your use of “standard” and “non-standard” really has to do with web components, as whether or not there’s a compile step is largely orthogonal to whether or not you use web components. Indeed, I suspect most people using web components in production are bundling their code and introducing a compile step there.
If “standard” is just shorthand for “needs a compiler”
At least for me, it is pretty clear that ~jrgtt means standard as in standardized APIs. Web components are built on top of web standards.
Web components are built on top of web standards.
My interaction with them did not feel at all as if they were built on web standards. It felt like web standards and react had a weird ass baby.
Web standards for me is: I can write some random markup and it’ll work without having to delve into terrible JS tooling.
That’s what I assumed as well, which is why I commented to point out that all frameworks are built on top of web standards, so singling one set of standards out to call them the real standard doesn’t make much sense. But then their reply suggested that their definition was more about compilation, hence my second comment.
all frameworks are built on top of web standards
Doesn’t React use virtual events, that are incompatible with DOM events, from an internal event pool so you have to grab whatever data you need out of the event before it gets recycled back into the pool?
That’s fair - all frameworks are built on web standards, but some frameworks wrap around those standards more than others. React is not the only framework to exist, though, and I believe it’s the only one that uses synthetic events like that.
I mean:
It’s a bit fuzzy since it’s probably 6 months since I last touched this bit, but I’ll take any solution over this.