It's interesting that you're advocating against DSLs yet suggesting Lit, which has a plenty of equivalent DSL in it.
Portability from one framework to another is not improved, e.g. by using Lit, since moving away from Lit would be as difficult as, say, moving away from React or Svelte.
Portability, in my view, is not an actual realistic problem, since there is generally no great reasons to move from one framework to another.
Web Components do not solve a problem of letting you port your code from one UI system to another without a major rewrite. Think of how you would port your web components app to be a CLI app? You need to think about separation of concerns and still moving most of the logic out of your web components, making them only responsible for bare data display and minimal interaction logic, while making your business logic independent. There is no difference for this when it comes to using web components VS a framework.
From point 4, it follows that either framework or web apis want you to couple your code to it, which is the root of the problem. The more important thing is code architecture and how you structure your code and manage your dependencies rather than which tool you use.
Software Engineer and UX Architect. I design and build user centric enterprise class applications that reduce human error, flatten learning curves and improve user productivity.
Location
Brentwood, TN
Education
B.E. Computer Engineering, University of Pune 2006
I don't know that I am arguing against DSLs per se, only that learning a new DSL for little gain in engineering capability resulted in framework fatigue for me.
There are cases where learning a new DSL grants you a superpower. I experienced this when learning RxJS, for example. But learning Angular wasn't a significant step forward for me after having used ExtJS. Svelte, on the other hand, was enough of an improvement that I'd never consider working with ExtJS again.
Re. #2 and #3:
I'd argue that portability here isn't about converting components from Lit to, say, Stencil, but rather about using Lit and Stencil components within the same application. When you decide you don't want to use a web component library anymore, it does not engender a rewrite of those components you already built.
Also, portability is very much a developer experience problem from my point of view. I would never voluntarily undertake to work with ExtJS again, unless I was getting paid 10x of what I'd charge for working with a more modern framework.
Re. #4:
That's true, but I was speaking strictly in the context of web applications. My argument dos not take cross platform portability into account.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A few points:
Re. #1:
I don't know that I am arguing against DSLs per se, only that learning a new DSL for little gain in engineering capability resulted in framework fatigue for me.
There are cases where learning a new DSL grants you a superpower. I experienced this when learning RxJS, for example. But learning Angular wasn't a significant step forward for me after having used ExtJS. Svelte, on the other hand, was enough of an improvement that I'd never consider working with ExtJS again.
Re. #2 and #3:
I'd argue that portability here isn't about converting components from Lit to, say, Stencil, but rather about using Lit and Stencil components within the same application. When you decide you don't want to use a web component library anymore, it does not engender a rewrite of those components you already built.
Also, portability is very much a developer experience problem from my point of view. I would never voluntarily undertake to work with ExtJS again, unless I was getting paid 10x of what I'd charge for working with a more modern framework.
Re. #4:
That's true, but I was speaking strictly in the context of web applications. My argument dos not take cross platform portability into account.