Use a different architecture

[ribose-jeffreylau]

It may be a good idea to take advantage of the modern niceties that React and its ecosystem bring to the table.

Links of possible interest:

• https://reactjs.org/
• https://medium.com/@allizadrozny/using-webpack-and-react-with-jekyll-cfe137f8a2cc
• https://github.com/avin/react-asciidoc
• https://github.com/insipx/Jekyll-React
• https://allizad.com/2016/05/02/using-webpack-with-jekyll/
• https://github.com/gatsbyjs/gatsby
• https://github.com/gatsbyjs/gatsby/tree/master/examples/using-asciidoc/src/pages

[ronaldtse]

@strogonoff perhaps the Open Site framework can utilize React? Thoughts?

[strogonoff]

@ronaldtse has the ban on Node stack been lifted? Gatsby may be almost there in terms of maturity, if we contribute theme support (it was nonexistent last time I checked) I’m open to playing with it for sure. I don’t know of any worthy alternatives to Gatsby.

[ronaldtse]

There's also Hugo in Go. I don't mind Gatsby but last time we checked it wasn't mature enough. I'm just afraid there is a large contribution effort needed from us to get what we need.

[strogonoff]

Then we’re mostly on the same page. I’m keeping an eye on Gatsby. I will play with Hugo in free time, Go could be more pleasant to work with and build faster

[strogonoff]

The problem that triggered this issue can’t be phrased as “we’re not using React”, can it?

Let’s start with the problem to make the discussion more on point.

To provide an example, here’s a problem I see with the front-end right now.

Currently JavaScript (in assets/opf.js), while achieving desired functionality, is not well-structured and is not using some quite useful features provided in latest ES standards.

(I don’t find it acceptable and I’ve been looking into attacking this on multiple levels: (A) to implement UI behaviors, use native web components, which are gaining support across browsers (a polyfill may be enough at this point); (B) minify and combine JS, transpiling from TypeScript, with Jekyll at site build stage or with Lambda at S3 → CF fetching stage.)

What would be some problems that you see? Let me know in a comment below!

[ribose-jeffreylau]

@strogonoff Thanks for the input!

The issue is indeed not so much about React as it is about moving to a more modern stack that would help solve some of the problems you just outlined :) In particular, I can see web components as a major factor in enabling cleaner template encapsulation.

[ronaldtse]

Again, the major issue we have right now is arrangement and amount of content, vs the “stack”.

It’s something we should look out for but it’s not a priority.

[strogonoff]

I only meant to provide the problem as an example but apparently that is the problem you meant? I was hoping for more discussion but OK I guess I hit the nail on the head then ;)

[ribose-jeffreylau]

@strogonoff Yes, pretty much. There are other things as well but I think they're just nice-to-haves, and/or are not specific to React. Things like quick build time (which does matter a lot actually), seamless page-loading (that Gatsby gives you out of the box), other things that promote encapsulation like CSS modules, and the whole JS transpiling ecosystem that we can leverage (think JS vs Typescript/Purescript/etc. Tools that make JS work for us.)

I think what this issue is trying to convey, is that what would be the upgrade path to take to make both the development and user experience more pleasant?

[strogonoff]

@ribose-jeffreylau I have considered this and seamless page loading actually doesn’t work smooth enough in my experience :( CSS modules and encapsulation is good (hence web components or such), TypeScript is sorta independent from React to be honest :)

I think user experience would improve a bit but not a lot since page loads quickly thanks to gzipping by CF, but TS will definitely help reduce the amount of bugs and smoothen development experience (at least for me)

[strogonoff]

Here’s a

Rundown of static site generators

• Jekyll (which we’re using)
• Hugo (which we’re considering)
• Gatsby (which we’re considering)
• Eleventy (https://www.11ty.io/) — saw many recommendations
• Bedrock (http://bedrockapp.org/)
• Middleman (https://middlemanapp.com/)
• SSG (http://romanzolotarev.com/ssg.html)

Not quite generators but on topic:

• Forestry (https://forestry.io/): Git-based CMS for static Jekyll or Hugo sites
• Hops (https://github.com/xing/hops): React development suite which includes a static file generator

[strogonoff]

For the record, I’m much looking forward to rewriting Open Project framework (as well as ISO TC Jekyll theme) with native custom HTML elements in mind. It’s great to encapsulate specific functionality in widgets, and build UI based on those widgets, each styling itself and communicating with each other through APIs.

The biggest hurdle to using them right now is uncertainty in writing self-contained elements, easy to build and import into the browser.

We want it so that given element’s markup, styling and scripted behavior are authored and imported together, encapsulated and not affecting the main document’s styling and behavior except for exposed HTML element markup tags and associated JS APIs.

There are two competing ways of doing it. Sadly, the documentation online tends to focus on one way and ignore the other (until they switch their preference and start recommending the other way).

First way is HTML Imports, or HTML Modules (<link rel="import" href="my-component.html">). Imported HTML file may contain its own markup, scripts & CSS (with <script> and <link> elements, just like a normal HTML document) and may define custom elements (e.g., <dropdown-menu>) that the parent HTML document can then use. HTML within the imported file gets parsed by the browser natively. This was planned for implementation by browser vendors. It seems to be the most logical and natural way of encapsulating Web components, but browser vendors seem to be moving away from it (some announce intents to implement again, some suggest polyfills).

The other way is JS Modules, or ES6 Modules (<script type="module" src="my-component.js">). Imported files are scripts, which can define styling and markup in JS (as strings or using some other way) alongside element behavior. Supporting code (likely, some JS library) would take all that and provide, again, a custom element that main HTML markup can use. This appears to be a less native and more library-dependent way, and it appears to require more of a build process. Lately vendors seem to be favoring it for some reason, though it’s not clear if this will become the standard way.

As of now, either way can be used via polyfills. However, I don’t want to end up sitting on a ticking bomb by choosing the “wrong” way that later ends up getting deprecated and its polyfills unsupported, at which point UI widgets will have to be rewritten.

I do prefer HTML imports, and I want to see whether vendors commit to HTML imports or abandon them for sure. Or maybe using HTML imports non-natively with polyfills does become a reliable and widely accepted way of bundling web components. In any case, we seem to be at crossroads here—I’d like to get a better feel as to where the consensus is going, and start using the most promising way then.

• Polymer library migrates from HTML imports to ES6 modules (Polymer is by Google, probably the most convenient way to start using custom components)
• Webcomponents.org docs on using components through ES6 modules
• Chromium/Blink announcing intent to implement HTML modules after all
• “HTML imports are the best Web component” (real-life case study of web components & HTML imports)
• “Mozilla will not ship HTML Imports”
• “The downfall of HTML imports”
• W3C revisiting HTML imports — HTML Modules WICG/webcomponents#645

[strogonoff]

IMO using a native way is preferable to React and similar libraries, in medium/long term.