benforreal

I think Lit is still recommending using web dev server (https://modern-web.dev/docs/dev-server/overview/), which no, its not a build system, but still a bit of a departure from a simple web server. And that's only needed to resolve imports that aren't a full relative path (like if I want to import Lit, I don't have to do import node_modules/lit/whatever). Someone else mentioned import maps here, and it's now supported in all browsers if you include the Safari preview release. I haven't tried it yet because I've been hung up on it being Chrome only until now, but it should complete the no-build experience. Except yeah, Typescript, but if you use it, you can just leave it watching in the background without much intervention.

But a build process ensures you can use imported dependencies internally AND use them with zero dependencies on your page (other than the JS component definition itself). Even if you don't have a build process and just use ES6 modules, the Web Component manages its own dependencies such that you don't have to worry about it (the only friction there being if folks use bare import modules). Whereas with React components, you'll always be dependent on a React runtime.

Sure thing! Those things are def up and coming, and I'll admit I haven't looked into them so much yet, but they are being designed to solve this very problem. I don't think that Web Components are the tool to solve every problem, but I've been a fan for a while (so much so that I'm writing a book)

"Stick to patterns, not libraries" - Such a simple statement, but concise as hell. It's whats been my mindset, but I haven't put it to words. Like normal DOM event bubbling is going to cover lots of use cases. When it doesn't, an event bus is crazy simple to write. A centralized data model can just be a static module. Need observables? Easy to write a simple one - otherwise there's likely a bazillion of them on npm. Not that I've used it, but it's not like Redux or MobX are restricted to React either

In the instance of Predix (I peripherally worked on that during my time at GE) and likely EA and every other large Web Component ecosystem you're thinking of, that's desired behavior. The real want is a design system such that things look consistent, but as design systems are CSS only, they aren't smart enough for interactions that require JS. So then the need for a design system becomes a need for components of some kind that include the design. You're looking for components with more adaptable design, but that's just not the intention of these ecosystems. If done with that goal, yes CSS vars take you a little bit of the way, but I think we'll see more power coming to help out soon with Shadow Parts/Theme, CSS Modules, and Scoped Stylesheets. But really, just styling a background? If the component author just left the background: none, you could do whatever you wanted from the outside. It just takes planning - even without the Shadow DOM you still need to plan for proper themeing.

I'm glad to hear this take. I came from Angular v1 and got sick of the framework churn, so jumped over to Web Components around 2015/2016 instead of going React. I abandoned Polymer pretty quickly around v0.6 because things were changing too much and just went plain vanilla JS + Web Components. I've been building applications since then with just Web Components and couldn't be happier. Unfortunately I just don't have enough experience with React to debate any of these points - I guess I just have to leave it that React is a need I don't have.

I was at the Chrome Dev Summit - we got 75% off coupons at registration, so it was advertised as for attendees only. Even so, it wasn't a real coupon code - you go to a site, enter the code, and tell them what app you're working and they get back to you. Not quite sure how "required" that is, but they were required form fields

I don't think managing your manager is a healthy way to think of things. You are there to support your company and team, and your manager enables this larger picture and should return support to every employee, including you. I think, as in most things, you need some empathy for his/her position and try to come to a common understanding. Talks are a fantastic way to boost your resume and soft skills, and they help you as an employee better practice talking to your team and enable you to better represent your team's ideas in big meetings with a crowd of stakeholders. Your manager should be sympathetic to this and be happy that you're passionate. On the other hand, when you speak at a conference, you are representing your company. If you say stupid things in your talk, you not only hurt yourself, but your company's reputation. I think the default policy at many big companies is to get explicit permission for each and every public thing you do like this, but usually managers just look the other way because its easier. Its possible your manager just wants to go by the book and not deal with the overhead of company policy, so the answer is no. You may want to discuss specifically why your manager isn't allowing you to present, and politely explain that you think it will level you up as an employee to be an even greater asset. Maybe suggest that you run the talk by them to make them feel better about what your are presenting, and even ask if its OK that you speak to HR or corporate to get the company's ground rules and make the extra time and effort in this regard so your manager doesn't have to.