2022 - developing web (with components) should look like in 5 years

[sashafirsov]

In response to WCCG request.

The Web Components would adopt the best DX patterns which is current web application development base.

Declarative web app UI, data and behavior finally would became a sufficient tool set to make functional web 3.0 application.

DX

Starts with Web Application Descriptor which would define the dependencies hierarchy relying on trusted source repos and target CDN registry. The build would deploy the compiled sources and dependencies into CDN. Of course if the semver built package exist on CD, no compilation needed. The recurring built time and app update for user would limit the load for only new/updated packages. Win-win for consumer, support, and developers.

Web Application descriptor

is a starting point. It would define the all kind of modules resolution. From HTML to CSS and fonts, in similar to importmaps fashion. Of course, along with Custom Elements libraries. Each module has own context, be part of parent descriptor, or have a descriptor of its own.

Descriptor in Sources would point to source level modules, release build would generate web app descriptor with maps to semver CDN binaries. Source level project and release could be run in browser. It is assumed that old-fashioned module managers like NPM would work along online CDN registries.

Application structure

To support the SDLC it is assumed that along with target apps would include the

• sources of app and its modules
• Demo for its modules/components( use cases, variations, theme variations). aka StoryBook app target
• unit tests which would reuse Demo cases, just verifying the proper UX/behavior. Test runner target.
• Coverage, security report, vulnerability report targets. During release would be deployed along the binaries creating trust verification chain which starts from source web app descriptor of app and each module.

module

present the HTML with single or several Declarative Custom Element definitions and/or templates.

The module content itself could be combined in same file or split into

• element/component/template definition
• demo with use cases
• unit tests based on the demo use cases

When component needs to override some of dependency style or behavior, it would be supported by defining dependency scope ( similar to shadowroot=open but permitting to override everything inside )

Of course old-fashioned JS module with Web Component code and manifest would co-exist. But due to security and performance optimization implications would be discouraged.

defining dependency

<define-element tag="my-component" src="@web-components-magic-lib/clap-n-smile#small" />

src would load the component definition either from local (via # url) or external resource.

While the actual lib implementation would use own wcm-clap-smile tag inside, its component registry should not interfere with my app. So instead of fancy wcm-clap-small I would use my-component locally.

The more complex case of overriding lib registry only for particular instance or scope also should be covered. For example, to enable the custom dropdown in calendar component from lib. I.e the registry in lib/component would be overridable, but not leaked back to container. Container could have own names for lib components. Whether developer needs to list all used from lib tags TBD, semantically I see it similar to ES import with name redefinition.

libraries

external lib components would be run in own namespace - a common scope for CSS, scoped components registry, importmaps. It would allow to use different libs, brand-customize them on same page.

Libs would utilize relative path and own module resolution. So when code "fall into" namespace, it would think it is in own environment. The path for IMG src, CSS font, another HTML module always would be treated as usual module: relative or importmaps directed. That would allow as to embed them into bundles or reuse from CDN.

Most of libs meant to be reused from corporate semver CDN as deployment media. Due to semver and public descriptor of build builds from different apps could reuse same module in CDN with ability to validate the identity and correct binaries transformation. The build for particular module could be delegated to compute CDN which coupled with static content CDN.

Cross-domain safety.

is addressed by no-JS declarative app behavior scoped definition. Once insulated, 3rd party web app would not be able to penetrate the owner layer.

Scope

Container/component in own scope would be available to control internal content and cross-operate with other components in same scope.

The named scope would help with a shared definitions and data. Libraries of components, theme are good sample for sharing same scope.

Encapsulation - based scope would help to insulate different actors "automatically" since there is no need for

CSS. The scope would define the availability of UI components for overriding.
As in CSS, other component modules, as in data/event bindings.

Ideal native performance

been enabled by declarative web app stack: all dependencies are known to browser and it would be able to

• compile the code into native platform binary for UI which is aware of data schema.
• data processing via streaming, passing only actually used object parts, disposing data immediately upon render.
• parallel processing as data dependencies are known ahead of run time

Mobile web apps with low CPU consumption would gain a ton from this approach.

side effects of Declarative Custom Elements

page vs routing

is not relevant anymore. Performance-wise the shared modules would be pre-cached and loaded. Page layout template is #1 candidate for caching and would not take a roundtrip to server and parsing. In this context the template is same as page layout component. The UX readiness time during route switch in "SPA" and page-based meant to be identical.

SSR

would fell out of developers scope. For app rendering speed it would become a legacy as external components based UI would be rendered FASTER. Just due to ability to load/parse/render parts via HTTP 2 in parallel.

The declarative custom components and data would be rendered faster due to templates reuse and multithreaded render.

SEO would be solved by search engines 👅