-
Notifications
You must be signed in to change notification settings - Fork 126
Conversation
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? |
|
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. |
@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. |
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. |
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 |
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 I see two main issues blocking/limiting Ease of Setup: Workflows should work with vanilla MacOS, unless the Workflows is specific to developers in which case installing Maybe something as simple as displaying Size: When I saw |
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. |
@willfarrell I love the idea of alfy being able to install node or at least guide how to. Maybe if/when it can generate |
Unzipped and installed. |
TL;DR: Node workflows suck for users. Developers are far too quick to dismiss this.
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:
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 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. |
@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. |
I've created a proof-of-concept standalone version that doesn't require a user to install node. @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. |
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 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.)
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.
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.
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. |
@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... |
@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. |
/sigh @deanishe it wasn't @rmm5t that wrote 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 No, Alfred would not have to, and should not, install modules via |
That sounds like a hard no on bundling mode with Alfred: https://twitter.com/alfredapp/status/974248640448548865?s=21 |
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).
@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.
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
The same resources are easily used with Ruby, Python etc. The workflow 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. |
I made an alternative caniuse workflow with more and different features. This okay or are duplicates not allowed?