Hacker News Reader

Comment by kbenson | Hacker News Reader

Actually, given the subject, that's an entirely acceptable requirement.

If all the components are only meant to function inside a blink based engine, then making versions that might function without chrome specific extensions just for the demo site is silly and a waste of resources.

It's simple enough to install chrome just to view this if you didn't have it installed already, and if you are interested in deploying an electron app, you probably already do.

Requiring a chrome based browser to view is the equivalent of requiring your browser support java applets when viewing a site showing off a toolkit for java applets (assuming it's a decade in the past). The simplest way to show the actual usage it to actually use them, and the best way to make that function correctly is to deploy examples that actually use the engine.

View on HN

A simple screenshot of how this looks like would be fine.

Representing the multiple states, animations, colors, hover actions and myriad other ways things can be styles with a simple screenshot isn't necessarily simple. Not representing that info doesn't make for good examples or demos.

Animated GIFs that showcase the functionality would suffice, and are almost as simple as taking a screenshot these days. You don't need to record every nook and cranny of the toolkit; just enough to get the gist of the look and feel.

> Animated GIFs that showcase the functionality would suffice

Suffice, yes. And yet they are clearly inferior to actually using the widget as it would be used, so why sacrifice that? In the name of possible users that refuse to use Chrome?

I think the number of people that are actually interested in this that do not have a version of Chrome handy already install that they can use and are unwilling to install it to see the functionality of a tool that relies on the functionality of a core component of Chrome is very small. So small, in fact I would be interested to hear from someone that was actually put off from viewing this that was actually in the market to make an Electron app.

I guess you could say I'm in the market to make an Electron app; I currently use the Quasar framework since I already use Vue, but I was interested to see how Xel does things in comparison and if it has Vue interoperability.

If I hadn't seen this comment thread, I would've went about my business to never give Xel a shot, because I'm on a low-end machine currently that takes forever to boot up Chrome, or any modern browser for that matter.

Though, I'm also a proponent of writing accessible sites/apps that don't break when javascript's disabled, so this sort of "you need x to view y" grinds my gears.

TL;DR: I'm definitely in the minority but it'd still be nice to have screenies

Sidenote: To those who use angular/react/vue: add a prerender to your buildscript to fallback to a static site for js-disabled folk. It can even wait for database calls, so dynamic content can still be shown. I personally use this one for Vue: https://www.npmjs.com/package/prerender-spa-plugin

I asked, and you delivered. :)

> I'm definitely in the minority but it'd still be nice to have screenies

Which is fine, and I'm not arguing it's better to not have them, just that when it comes to the set of cases where it's okay to require a specific browser version, this pretty much fits the bill for me. Anything else is more work than using the actual widgets in examples, so that's what appears to have been done (and (one of?) the authors is on record here as saying they are planning to a add more later).

I just think "Well frankly F off" is a bit extreme given the actual specifics of the situation. People have a tendency to shift outrage from one item to another using false equivalencies (a website targeting general users doing this would be a different story), and I think that's worth calling out when I notice it.

I'd argue presenting the documentation for your java toolkit as a java applet would be bad form.

Not getting the full demo without a matching browser (although I'd ask the question if there isn't a polyfill for the webcomponent APIs), but there is no reason why a basic info page with at least a screenshot doesn't work everywhere, and would already be a lot friendlier. There is the "fork on github" banner, but the readme just sends you back: "Visit xel-toolkit.org for demos, documentation and code samples."

> I'd argue presenting the documentation for your java toolkit as a java applet would be bad form.

The equivalent would be if Java had a documentation viewer application which was built in Java and was the standard way to view the documentation. At that point, saying and enforcing "You need to read our documentation using the standard documentation program but utilizing this special Java version which is what you would be deploying the toolkit in, because that's the only way the examples will work right." matches the current situation.

Unfortunately it is not technically possible to polyfill all Web Components APIs. Shadow DOM is especially hard to polyfill in any sensible way (Google did try it, but failed to deliver a solution that would cover all use cases).

I'm sorry for the missing documentation on Github, I will write a proper project description with some examples later next week.

Is there something specific that's preventing Edge/ChakraCore from working with this? Just wondering.

WebComponent APIs seem to be the main thing, at least that's what the "sorry, wrong browser" page checks.

From the top of my head, Edge is missing: Shadow DOM, Custom Element, HTML Imports, Web Animations, CSS custom properties and CSS path data ("d") property .

In the longer run I'm planning to replace HTML Imports with ES.next modules, so it's temporary dependency.

Reply on news.ycombinator.com