## Are web components ready for prime time?

Yes. Web components effectively turn the HTML of a site into a consistent API. HAXeditor leverages this approach and standardizes its usage in order to supply an incredible amount of functionality in the browser. We do what the vast majority of CMS provide prior to interfacing with a server. Just HTML files and a h-a-x tag to understand how to modify content.

## What's Browser support like?

- Web components can be compiled to support IE11 and work in all major browsers natively
- HAXeditor is supported by IE 11 and all major browsers, though we mostly test "evergreen" browsers.
- HAXcms support is broad but a bit fragmented to optimize the experience per each device. From lowest to highest quality (numbers based on global traffic data in aggregate , last updated Aug 2020 )

- IE (11) / Safari (9.1) / older - no JS / frame based site (~ 1.8%) ES5 / fallback text
- Edge (18 and below) - watered down UI (~ .7%) ES5

- Edge + Chromium in 2020 will move it to the bottom

- Firefox 48-67 / Safari 10.x (~1%) - ES5
- Evergreen / Modern browsers (~ 96.5%) - Native ES6!

## Do I have to use the elements HAXeditor supplies?

No. HAX is written such that the Appstore Specification is defining the elements that are available in this site and other demos. Leveraging the autoloader piece of the spec, you can tell HAX which tags to load. The web component definitions and schema can be kept separate as desired (useful in CMS with editorial workflows / permissions scenarios).

## Do these elements require HAX to operate?

No! HAX modifies HTML inside of itself and then exports back to HTML. This means that as long as the web components on your site have definitions, HAX no longer is required to render them!

HAX is effectively writing the same HTML you could have by hand. Web components help make it semantic but also ensure that functionality lives with "the platform"; in this case, the platform being the browser. So long as the definitions of the component are in scope of the page, the element will unpack correctly HAX or otherwise.

## How does this compare to the WordPress Gutenberg plugin?

In terms of mission and what they attempt to provide, a click and build website tonight, no-or-minimal-code solution for the masses... they are the same. They both seek to reduce barriers to entry in web expression. HAX takes some critical differences in philosophy of design to Gutenberg both in technical implementation and goals for the open web.

HAX seeks to improve web publishing for all systems, HAXcms or otherwise. HAXcms (which this site is constructed in) is but a tiny fraction of the web and we want to empower anyone to improve self expression. We want to improve privacy, self sovereignty, and the individuality of all peoples on the web. HAX seeks to eliminate technical barriers to production, integration and delivery of material on the internet; all of it, not just the expensive CMS part of it. We want to hax-the-web, hence this domain name.

Some larger points of different are highlighted below

- HAX is platform independent - We seek to improve the web and all that it touches, platform agnostic. Gutenberg is highly focused on the needs of WordPress and improving the content authoring experience for WordPress users.
- Gutenberg embeds its blocks layer with the authoring nuance such that all operations can be wildly different per block. For example, a tabbed list of items may have a "add another" button inline with the block. HAX believes that the editing experience across complex elements must be delivered by the HAXeditor, not the element or block level. This illustrates itself in the UX as users selecting an element to work on and then interfacing with it the same way they would any other element. We feel that this will reduce long term barriers to adoption by end-users and training through a lack of cognitive load increase per element.
- Gutenberg sees you "add" things as its primary construction method. If you need to upload media that's a separately integrated process, highly dependent on WordPress to deliver. HAX boils content creation operations down into the mental model of the author. Authors either say "I need to Add something" (Add menu), "I need to to Find something" (Find menu), "I need to Make something" (Make / create menu), "I need to Layout something" (Blox / Layout menu) or that they want to remix something from a Template (Stax / Template menu).
- The Gutenberg blocks system produces react components which are specific to the logistics of WordPress. The elements produced for HAX work in and out of HAX capable systems . We believe in extending the broader capabilities of the web first and HAX second in order to reduce duplication of efforts globally and improves resource sharing.
- Gutenberg is written in React, effectively requiring all plugins and block components be written in React. HAX is written in Web components leveraging a mix of "VanillaJS", LitElement and PolymerElement constructed elements. You can use any web component compatible library in order to produce elements for HAX. While not limited to, here are some popular examples that could natively talk to HAX:

- VanillaJS following the web component specification
- PolymerElement
- LitElement
- SkateJS
- Slim.js
- Svelte
- VueJS (web component wrapper)
- Angular Components (compiled to custom elements)
- Any library that passes testing on custom-elements-everywhere should work

## Where did this come from?

HAX is the brain child of the ELMS:LN team at Pennsylvania State University . HAX is the authoring solution originally created to power ELMS:LN and other instructional innovations and was quickly realized for its potential to transform web publishing.

The original core development / evangelist team on HAX in its infancy (an idea conceived in 2016, experimented in 2017, manifested in 2018, actualized in 2019):

- Bryan Ollendyke (@btopro ) - Project lead Developer
- Michael Potter (@hey__mp ) - Core Developer
- Nikki Massaro-Kauffman (@nikkimk ) - Core Developer
- Charles Lavera (@cgldevel ) - Core Developer
- Michael Collins (@_mike_collins ) - End user testing, needs assessment
- Katrina Wehr (@katrinamwehr ) - End user testing, needs assessment
- Melissa Hicks (@juststormy ) - Needs assessment, champion

There is nothing we can't do together. Help us build a better web together!

Ex uno Plures