t0f3rchr15

I absolutely agree. This is what makes technologies like graphql so compelling to me. Your data layer shouldn’t mimic the structure the presentation layer, and the presentation layer shouldn’t be tightly coupled to the data layer. And more importantly, data will typically be used by a multitude of apps, all with different purposes. There’s nothing worse than starting a new project that relies on data that was structured to facilitate an old obsolete interface.

I absolutely agree. Not only can Web Components simplify web development and lower the barrier to entry, they can also bridge the gap between frameworks and the modern modular web.

As a developer who works in an enterprise environment, frameworks like React and Angular are our boon and bane. Beyond the advertised features, they are amazing at providing repeatable patterns for developers and offer structure to large and small projects alike. And in my experience, they have proven to be significantly smaller, more performant, and more maintainable than the vanilla JS apps that were being delivered to clients previously. Also, it is because of legacy browsers that we still need all the features these libraries and frameworks provide. Many of our clients are just now moving away from IE 10 and 11, and tools like these have kept us all sane.

So we take the cost of learning frameworks, bundling through webpack, and being tied into proprietary ecosystems, because the trade off is worth it to us when our focus is delivering value to the business and functionality to our customers.

Enter Web Components. Trying to maintain branding, coherent styles, accessibility, and a cohesive user experience across an entire enterprise can be a huge undertaking. Common component libraries help, but the multiple frameworks used throughout a company can result in duplicated and triplicated work. Web Components offer us the promise of creating these assets once and including them in any application we build, regardless of framework. And since they are spec compliant and framework agnostic, changing to a new framework--or no framework--in the future doesn't have the added cost of rewriting every component to match the new lib/framework API.

To address some other comments here, it's worth discussing who controls the specs, and what's the right path for the future of the web, but we still have to develop for the world we live in today.

Another way to cut down on overhead is in the php for loops. If the page has many images to load, the size of the array will be large and sizeof() will be called every iteration of the loop. Instead, use for($m = 0, $mm = sizeof(array); $m < $mm; $m++), or set a variable to the size of the array before the loop. This way, the sizeof() method is only called once. http://php.net/manual/en/function.sizeof.php