alternative caniuse workflow

[robjtede]

I made an alternative caniuse workflow with more and different features. This okay or are duplicates not allowed?

[derimagia]

I don't want duplicates but if it has better features I"m okay with switching = can you tell me a few things this does better that made you write it?

[robjtede]

• I wrote it first and foremost because the other one stopped working for a while.
• It's got a nicer interface since the browser support tables are shown with a separate query which also lets it show wayyyy more browsers in the list. (Anything other than the big 4 though I'm pretty sure the existing one even doesn't show Edge support.)
• The info it presents is far more detailed.
• Has a link to the source website if more detail is required.
• Auto-updatable with alfred-updater.

[deanishe]

Personally, I wouldn't replace the existing workflow. It may not have as many features as this one, but it runs out-of-the-box, as it's written in PHP.

This one doesn't because it's written in Node. As a consequence, it's also massive. 60MB vs 200KB for @willfarrell's workflow.

It's just my opinion, but I count excessive size and needless external dependencies as less than awesome.

[robjtede]

@deanishe makes a fair point. I was offering as an addition but if this list prioritises size (I can look into that) and the need to run out of the box then I understand why you wouldn’t want to replace it.

[deanishe]

It's not my place to lay out priorities/criteria for inclusion in the list, nor would I describe small size and works-on-vanilla-macOS as anything close to requirements.

I would just be hesitant to replace the existing workflow with one that, imo, has a couple of asterisks next to it.

OTOH, the workflow is aimed at web developers, who very likely have Node installed and more space in Dropbox than the default 2GB, so being big and needing Node probably don't bother the target audience. I imagine many will see the latter as an advantage.

[derimagia]

I agree with @deanishe about preferring workflows which are easy to setup for all. I want to add warnings (w/ an icon or something) for the existing ones for requiring node or other runtimes as well.

If this was a unique one that we didn't have an alternative it would be another thing.

Btw to reduce size you can run it through something like webpack.

Nice work though otherwise. I'm not against other workflows which don't replace existing ones that use node - Preferably if they are "compiled" down and have warnings about requiring node

[willfarrell]

I feel like I should comment on this. Since I wrote my workflow, over 5 years ago now, a lot has changed. Most notably Alfred Workflows can have more capabilities and alfy & alfred-updater now exist. Updating my workflows to node has been on my backlog for quite some time.

I see two main issues blocking/limiting node workflows adoption. Maybe this can be a starting point to addressing them.

Ease of Setup: Workflows should work with vanilla MacOS, unless the Workflows is specific to developers in which case installing node should not be a expected barrier for them. However, I feel this rule can be disregarded if the UX from Alfred is clear enough for a non-developer to take the steps to install node. This is solvable, might be a useful feature for projects like alfy to include.

Maybe something as simple as displaying This package required NodeJS to be installed. Click to download.. Would be nice if Alfred knew the dependencies a workflow had via the config and had this built in (If someone knows someone over there, please tag.)

Size: When I saw 60MB vs 200KB I was blown away. 60MB is way too big. I feel 1MB is a fair threshold most people can easily reach if provided with pre-made build process that everyone accepts. @derimagia is right, webpack is the way to go. Not sure if a project exists already that can take care of this, yet, maybe something like alfy-cli w/ init / build / publish. I have some cycles next month if someone would like to collaborate on it.

cc @sindresorhus

[robjtede]

I've no idea where 60MB came from. Max I ever saw was 12MB.

Anyway, I played some golf and got it down to <1MB for the .afredworkflow bundle. Not bad considering it contains a bunch of icons, too.

[robjtede]

@willfarrell I love the idea of alfy being able to install node or at least guide how to. Maybe if/when it can generate .alfredworkflow bundles then a proxy bash script could be included that does so.

[deanishe]

I've no idea where 60MB came from. Max I ever saw was 12MB

Unzipped and installed.

[deanishe]

TL;DR: Node workflows suck for users. Developers are far too quick to dismiss this.

I see two main issues blocking/limiting node workflows adoption. Maybe this can be a starting point to addressing them

To my mind, that skips past the more important question of "why use Node in the first place?"

Node's strengths as a platform aren't really relevant to workflows, and Node's downsides compared to built-in runtimes all accrue to the workflow user, not the developer.

A lot of users struggle to find and alter a workflow's configuration in Alfred Preferences. Installing an SDK via Terminal is a very, very big ask.

Sync doesn't Just Work, either, as a result of the external dependency.

Something @rmm5t said on the Alfred forums kinda sums up the problem as I see it:

Btw, most Alfred workflows suffer from this least-common-denominator language versioning issue by not being able to specify runtime versions.

The workflow doesn't suffer, the developer does. Because they don't get to use their favourite runtime and/or have to work around a bug or two in the old runtime version included with macOS. And Ryan's solution isn't to suck it up, it's to push the cost onto users instead by bundling his preferred version of Node with the workflow. As a result, the workflow is 50MB, compared to a few hundred KB for the original Ruby workflow it copies. The only user-facing benefit is the addition of a handful of newer emoji, which could have been easily added to the existing workflow without increasing its size by two orders of magnitude.

Requiring non-standard runtimes and/or 50MB workflows are fundamentally user-unfriendly things.

And I think that's something that Node developers are far too quick to dismiss.

That a lot of Node workflows recommend installation via npm (which is fundamentally incompatible with Alfred's sync) indicates to me that many Node devs are approaching workflow development from the wrong direction. Their goal isn't to make an Alfred workflow, it's to use Alfred as a frontend for Node.

That's a fine recipe for building great Node tools, but it's a crap way to go about building a great Alfred workflow. There's no way to work around requiring a non-standard runtime that doesn't come at a cost to users.

[deanishe]

@robjtede I just installed the new version. Down to 30 files/2MB unpacked and installed from 10,000 files/60MB. That a stupendous improvement. I bet it loads a lot faster, too, now it only has to read a couple of files, not hundreds.

[robjtede]

I've created a proof-of-concept standalone version that doesn't require a user to install node.
Download size: 13MB, unzipped size: 43MB.

@deanishe I'll accept that a trade off has to be made when creating workflows (and indeed anything) with non-standard runtimes. I wrote this workflow in node because it's my prefered platform and I can make cool things with it.

Obviously, smaller file sizes yielding the same results are better but I, personally, have never hesitated to download a workflow based on it's size. What's 50MB these days? Now, of course, theres the problem of having all your workflows take up 50MB. I have 37 workflows installed which at 50MB each would be 1.6GB. That's more of a worry but it's the exact same problem that projects like Electron have and uptake of that hasn't been held back.

The npm version is incompatible with sync in that it simply symlinks itself into the Alfred workflow directory. However, both of the packaged versions are syncable. I'd say that a developer should, generally, understand the implications of each approach and even if not, a line in the README explaining so would be sufficient.

I'd love to get a wider set of opinions of whether choosing a workflow is based primarily on lower file size or greater usefulness.

[deanishe]

What's 50MB these days?

Exactly 1/40th of the standard 2GB free Dropbox account.

Were you an average user in a world of 50MB workflows, you'd be close to the point of having to delete workflows in order to install new ones.

That's more of a worry but it's the exact same problem that projects like Electron have and uptake of that hasn't been held back.

That's basically impossible to quantify. What is certain is that Electron-based apps have come in for a significant amount of criticism for their appalling performance and excessive resource requirements compared to native apps. (In fairness, the performance issues seem to be mostly down to shitty coding rather than inherent to Electron as a platform. The excessive resource requirements are inherent to the platform.)

Now, of course, theres the problem of having all your workflows take up 50MB

That's the heart of the matter, imo. Bundling Node with your workflow/writing your app with Electron is much the same as not vaccinating your kids: It's just not an issue if it's only you and a few others doing it. It becomes a serious problem when lots of people start doing it.

I'd say that a developer should, generally, understand the implications of each approach and even if not, a line in the README explaining so would be sufficient.

A developer would get it. Which is fine if developers are the target audience for your workflow. Normal users don't have a fucking clue that there even are implications, let alone what they may be. They understand installed and they understand not installed. That there's may be a grey area between the two escapes the average user entirely.

I wrote this workflow in node because it's my prefered platform and I can make cool things with it.

You wrote this workflow in Node because it's your preferred platform. You could make something every bit as cool with Ruby/Python/PHP/Swift etc. if you wanted to. You could probably also stick with JavaScript and target JXA instead of Node.

It's not my place to tell you which language/platform you should use, and I'm not trying to. It's your time and effort, and you should invest it as you see fit. But let's at least be honest about it and acknowledge that it's you that made your workflow as good as it is, not JavaScript or Node.

I don't expect I'll be able to dissuade a single Node developer from using Node for workflows. I'm just trying to ensure someone is out here advocating a user-centric approach to workflow development that doesn't impose unnecessary burdens on users, which is largely driven by a Kantian attitude of "what if everybody did it that way?" (which you also touched upon).

For exactly this reason, I never use my own preferred language—Python 3—for workflows.

Python 3 automatically solves 99% of the problems that arise with Python 2 workflows (text encoding issues), but I suck it up and deal with the Python 2 issues because it's installed with macOS by default and Py3 isn't.

[rmm5t]

You could probably also stick with JavaScript and target JXA instead of Node.

@deanishe At first, I was a little peeved for getting called out in this thread out of the blue, but this got me thinking. JXA is a great idea for alfred-emoji! It would probably also require a webpack precompile before bundling the workflow, but that's no biggie. I think I can strip out the node binary from that alfred workflow. Playing now...

[deanishe]

@rmm5t How did you package it up for JXA?

I had to do something similar (JS was the best language for the job, but I didn't want to use Node), but I don't have the first clue about JS packaging, and I've probably made a right mess of it.

Also, sorry about calling your workflow out like that. It was rude of me. I "paged" you because I thought it would be even ruder to talk behind your back.

[jsumners]

/sigh

@deanishe it wasn't @rmm5t that wrote alfred-emoji with Node. It was me. And, yes, the reason was for my benefit as the developer. I can't stand even the sight of Ruby code, much less am I able to parse that line noise enough to have forked the original project and update it as needed.

My opinion is that Alfred itself should bundle Node so that workflows can use it as a "native" runtime. Yes, a lot of things can be accomplished with JXA, but the benefit of Node is the ecosystem of libraries that can be included. In the case of alfred-emoji that ecosystem is leveraged to generate the resources the workflow needs. The actual bundled Javascript does not directly depend on any ecosystem modules. But I'm sure there plenty of workflows that could be devised that would be able to make direct use of ecosystem modules.

No, Alfred would not have to, and should not, install modules via npm. Whatever modules the workflow author deems necessary should be bundled with the workflow. The workflow may not be super tiny, but at least it wouldn't need to bundle the underlying VM.

[robjtede]

That sounds like a hard no on bundling mode with Alfred:

https://twitter.com/alfredapp/status/974248640448548865?s=21

[deanishe]

That sounds like a hard no on bundling mode with Alfred

Oh definitely. Andrew's sensibilities are not dissimilar to mine. He was very pleased to be able to remove Alfred's only 3rd-party dependency (the Growl SDK) in Alfred 3 when he dropped support for pre-Notification Center versions of macOS.

There's basically zero possibility of bundling any language with Alfred, let alone Node (which would be an objectively bad choice to anyone but a diehard Node dev).

My opinion is that Alfred itself should bundle Node so that workflows can use it as a "native" runtime.

@jsumners You mean, you wish Alfred bundled Node, right? If you have an objective argument for why Node is a better choice for bundling than other languages, I'd genuinely love to hear.

Yes, a lot of things can be accomplished with JXA, but the benefit of Node is the ecosystem of libraries that can be included

That applies to every language apart from maybe bash. You can argue that Node has far more libraries than other languages, but that's largely a result of the Node community's treating npm as a snippet manager (e.g. the patently ridiculous left-pad), in addition to a real package manager.

In the case of alfred-emoji that ecosystem is leveraged to generate the resources the workflow needs

The same resources are easily used with Ruby, Python etc. The workflow alfred-emoji improves on is written in Ruby, after all. The main thing you are leveraging the Node ecosystem for is to treat building an Alfred workflow as if you were building a JS library.

Essentially, you embody the approach I described above. You didn't set out to create an Alfred workflow; you set out to use Alfred as a Node frontend. You complain about the difficulty of generating info.plist programatically because it's undocumented, but that problem is entirely of your own making. Everyone else just uses Alfred Preferences to edit info.plist, like you're actually supposed to.

That is to say, from my point of view, as a direct result of your approach, your workflow comes with a significant drawback (or rather, it did until @rmm5t removed the unnecessary Node dependency), and you complain about issues (generating info.plist) that are entirely of your own making for behaving as if you were building a Node program, not an Alfred workflow.

As I've emphasise repeatedly, I don't presume to tell anyone how they should spend their time. I just want to express how daft your arguments appear to someone coming from a workflow-first point of view. Every issue you have with Alfred (no Node, undocumented info.plist) is only an issue because of your "Imma gonna writing a Node program" approach.