An Open Letter to Web Developers

栏目: IT技术 · 发布时间: 4年前

Dear Web Developer(s),

While, as a software developer ourselves, we understand very well that new features are exciting to use and integrate into your work, we ask that you please consider not adopting Google WebComponents in your designs . This is especially important if you are a web developer creating frameworks for websites to use.

With Google WebComponents here we mean the use of CustomElements and Shadow DOM, especially when used in combination, and in dynamically created document structures (e.g. using module loading/unloading and/or slotted elements).

Why is this important?

For several reasons, but primarily because it completely goes against the traditional structure of the web being an open and accessible place that isn't inherently locked down to opaque structures or a single client. WebComponents used "in full" (i.e. dynamically) inherently creates complex web page structures that cannot be saved, archived or even displayed outside of the designated targeted browsers (primarily Google Chrome).

One could even say that this is setting the web up for becoming fully content-controlled.

The more additional "features" are tacked on to these components, the less likely it is for non-Google clients to be able to display sites in full or properly. It creates problems for people who are in limited environments, need special web clients for e.g. limited physical accessibility, or need to strictly protect their privacy. What of people on older hardware who don't have the computing power to basically run all these JavaScript applications fully off-loaded in their browser just to be able to render a page? Not to mention other software that needs to be able to parse web pages as a whole like alternative search engines (another thing one could consider unfair competition from Google).

It also creates problems for any browser that is not Google Chrome or a direct descendant of it (and that includes Mozilla's Firefox, despite being developed by a well-funded corporation), which is basically enforcing a full browser monoculture in the near future if web developers continue to adopt every latest new thing that comes out of the Google web labs in an "implementation-first" fashion, and continue to implement change for the sake of change. Once more, this is doubly-important for frameworks in use by thousands of websites that are at the heart of the Internet economy like on-line stores, bank sites, media sites, etc.

Full disclosure: While it is absolutely true that it is in our direct interest that web developers don't use something we are still working on implementing ourselves (considering our limited capacity as a smaller non-profit community, which is likely the same for any other true Open Source/Libre projects out there), the impact of what is outlined above is much more far-reaching than just our own projects; not only is it pushing for a proprietary web that is vendor-locked, it also, as stated, becomes something that will be impossible to archive, save or process.

"But I like the scoped styling I can do"

One of the main reasons people want to use shadow DOM these days is because it allows them to designate CSS styling that only applies to their little corner of the web page it is in (e.g. a widget). The thing is, we already had scoped styling in a much simpler (not script or DOM dependent) way that was actually asked for by web developers like yourself, that was actually standardized, and that got implemented by browsers, but then removed... basically because Chrome didn't implement it (despite resistance from designers[1]) to be replaced with the much more complex Shadow DOM alternative; it would be much more useful to ask for that to be returned to the spec. You can help by getting involved with the requested spec change on WhatWG issue 4508 [2] and/or Mozilla's implementation bug 1542645 [3].

The big question to framework and web developers

The biggest question you should all ask yourself when you are currently considering (or already using) Google WebComponents is: Do you really need it? Do you need the complexity, inherent slowness of megabytes of client-side scripting, or the specific features of Google WebComponents? What was wrong with your previous implementation that "couldn't be solved any other way"? In my opinion, the last actual scripting standards (ES6 and extensions) already allow anything that would be needed without completely re-architecturing what the web has been building on for decades. The few missing "tricks" that these components offer are not new, after all: (X)HTML has been fully extensible by design. Things like XBL have also existed for a long time doing the exact same things now touted as "new". You also shouldn't need JavaScript and DOM to style your pages, especially with the latest additions to CSS like flexible layouts.

We know that some developers will obviously not be amenable to this request to avoid WebComponents (e.g. I don't expect Angular, developed by Google, or YouTube, owned by Google, to do anything but push these things) but we ask that you please consider this request if you don't have a direct need to actually use them.

To conclude, I'm hoping that you, our web creators, will continue to keep the big picture in mind when it comes to the internet being primarily a public exchange of information, keeping it open and accessible to all with the software your users choose or need to use.

Thanks for listening,

Moonchild.

[1] https://github.com/whatwg/html/issues/552#issuecomment-178107702 and onwards

[2] https://github.com/whatwg/html/issues/4508

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1542645


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

TCP/IP网络编程

TCP/IP网络编程

[韩] 尹圣雨 / 金国哲 / 人民邮电出版社 / 2014-7 / 79.00元

第一部分主要介绍网络编程基础知识。此部分主要论述Windows和Linux平台网络编程必备基础知识,未过多涉及不同操作系统特性。 第二部分和第三部分与操作系统有关。第二部分主要是Linux相关内容,而第三部分主要是Windows相关内容。从事Windows编程的朋友浏览第二部分内容后,同样可以提高技艺。 第四部分对全书内容进行总结,包含了作者在自身经验基础上总结的学习建议,还介绍了网络......一起来看看 《TCP/IP网络编程》 这本书的介绍吧!

URL 编码/解码
URL 编码/解码

URL 编码/解码

html转js在线工具
html转js在线工具

html转js在线工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具