OT: I noticed in the GitHub repository that there is `.jshintrc` as well as a `.jscsrc` and `.eslintrc`
Why are you using 3 different JavaScript linters, instead of just 1? Especially since one of them (JSCS) was merged with the other (ESLint). There was a blog post about this in April[0] and even the front page of JSCS says that it was merged with ESLint[1], so why use both of them, in addition to yet another linter?
In general I like Electron, it makes it easy for web developers like me to get into making desktop apps. However, if you're not building it cross-platform, what's the benefit of Electron? If you disregard easy for web-developers.
This frustrates me a lot too. Whenever I encounter non-crossplatform Electron apps, I extract the mac or windows app.asar files and so far, all of them have ran fine on Ubuntu. That means it's just a matter of not taking the effort to package the app for multiple platforms. I get that packaging is not the most exciting part of application building, but it's not rocket science either.
If anyone has an Electron app and wants/needs help with cross-platform packaging, feel free to contact me.
Why do you disregard one of it's main benefits? MacOS development is notoriously tricky, so to enable it for the largest class of developers today makes a lot of sense.
The other big advantage would be speed of iteration - particularly in a startup environment, being able to iterate on designs, layouts and functionality fast is a huge plus of working in JavaScript / HTML over native constructs.
Let's flip this around, what are the benefits of writing a native app when there is Electron? It's democratizing cross-platform Dev tools in one of the most standard rich environments, the browser.
> Speed
I'll give you that, but performance is not the most important factor for most users of most applications.
> Native UI
Coming from someone who has done web development and iOS development, who tried native development for osx then switched to electron with react and redux, I have found it faster and easier to completely recreate the look and feel of the native osx views while adding custom functionality than to add custom functionality to natively. Appkit sucks and many of the improvements they've made over the years are only available in recent osx versions.
The development experience is much better using VSCode than Xcode too. That's insane. A 2-3 year old web based text editor should not be a better, faster, and more stable development environment than the 8th version of the of the IDE from the most valuable company on the planet.
I haven't noticed it, and use Atom (Electron based) on a Laptop often. It's a MacBookPro, so already one of the better in terms of battery consumption, but I use it disconnected from Power for upwards of 5-6 hours at a time with no issues.
If NeXT was written after the browser (rather than being used to write the first browser), I believe the OS windowing toolkit would have been HTML and CSS based, rather than postscript based.
If you consider macOS' use of postscript rendering as roughly equivalent to that of what a browser does with rendering the DOM, then I think we start to see what Electron represents.
I personally haven't developed with Electron, but I'm hoping that there are ways to hook to native code where needed, just like Apple does from Postscript to Swift/ObjC/C.
Not to nitpick, but I fail to understand the problem you are trying to solve. Even if something like this would be bundled with some IDE, the reason is unclear to me.
It's nice as a side project to get used to electron though.
In their README, they have a section describing why one should use this project[0] which essentially says something like this:
Not everyone knows how to use the npm CLI, and they oftentimes cannot use it for "intern/office/job" reasons, or they are simply unwilling to use the cli at all.
However, the learning curve for the npm CLI, at least for the tasks that this project accomplishes, is not steep at all. For example, installing a dependency is as simple as `npm install dep` where `dep` is the name of the dependency you want to install. Furthermore, I have never heard someone say "I couldn't use npm because it's a CLI and my job does not allow me to use those", nor have I ever heard someone who wants to use npm say "I am not willing to use a CLI"
I'm curious, in what job setting is one not allowed to use the npm CLI? And, since this project itself uses the CLI[1], wouldn't using Ndm be just as bad as using the npm CLI?
To say nothing of the fact that a programmer can't use the CLI? What programmer is that?
I mean, I'm all in favor of tools that integrate into the IDE, that reduce the overhead of running commands, but not being able to use the CLI would be a huge red flag.
In fact, you now have me considering writing a new interview test to make sure people are literate with the CLI.
> To say nothing of the fact that a programmer can't use the CLI? What programmer is that?
I've seen this a fair bit before. The most common case (in my experience) is "enterprise" developers who use an IDE, only develop in a single language, and use a GUI Git tool for version control.
I would say that, in most cases, the assumption that they don't have a strong understanding of the concepts abstracted away from them (compilers/git/etc) tend to be more correct than not.
> To say nothing of the fact that a programmer can't use the CLI? What programmer is that?
People who use Excel, maybe. There are a lot of people who do "programming" in their job without their job title containing "programmer". I can absolutely believe that these days there are people out there brewing up little JS scripts to help them with their day-to-day tasks.
I personally got my start in programming through Access -> VBA -> VB.NET -> C# -> JS/Ruby/Python/whatever. The first four involved little to no CLI work.
This is seriously the only use case for this app? This is one of the least compelling reasons I've heard for using a project. If I'm using an alternative to npm on the command line, it's yarn. It adds way more value and saves way more time than a tool like this ever could.
If I had a job where I couldn't use the command line, I would quit or not take the job to begin with.
Using command line tools is one thing while managing and keeping them up to date is another and extracting the latter into a GUI is pretty convenient. I think when people see this, they immediately think of using it to help create node applications -- likely a ridiculous scenario -- but when using it to manage command like tools available through npm, it makes sense. Brew has a similar app, CakeBrew (https://www.cakebrew.com/).
Hi, you can use it when you are tired and your eyes can't concentrate ;P (joking)
One cool thing about GUIs is that (usually) you can run multiple processes and commands while other processes are running without having to open multiple tabs or shells or to go through the shell outputs to see errors and/or warnings.
But this is not to say "a GUI is better", they are just complementary in my vision.
Personally i use and abuse the CLI for most of the time, because i love to feel the machine is in my hands, then sometimes i feel more comfortable on a GUI or a Wizard process, it' human i guess.
Totally agree, in fact this would be exactly the kind of thing I'd implement only to learn the GUI framework, but I would have chosen to use Qt or similar instead.
Why have page that tells almost absolutely nothing about your project? I could understand if it was aimed at non-tech people but I have serious doubts that anyone that isn't developer will be interested in your project. If I read title on hacker news that says 'Npm Desktop Manager' I would like to be able to read a little more about it before I decide to use it without having to go to github. Like, the information that there is no stable release is only in FAQ section of github project.
It is but additional info like release version or minimum required npm version would be nice. Or have any info from 'Recommendation' and 'FAQ' section from github displayed.
Offtopic: There are merely 40-50 words on that page, but 3 different font families and several sizes and weights. Almost every line is styled differently.
This looks nice. I'm really tied to using creationix nvm at the moment and it seems like these two libraries would be competing for control over how to manage node/npm. There's no GUI on nvm though, so if this tool can handle installing multiple different versions of node/npm then maybe it is a better alternative.
Good job. I think it's useful purely for the fact that it can tell you the latest available version for each of the packages in your project. It's handy to have that at a glance
This is a beta release, due the fact we need to spot out many other possible and common bugs/problems before to make it really stable, that's the only reason why ;)
Ofc, just you know ... too much meat on bbq it will be quite degenerative :)
Actually, the API used is require('npm') that mean if it gets stable on OSX there will be quite 99% possibilities it will be stable the same on Linux and Win.
Then templating and releasing will be quicker ;)
What's the point of this? By that I mean what would you actually use it for?
Is this a GUI version of nvm and if so, seriously who would use it? The whole point of nvm is to be able to pop in/out of node versions as you're working on a project. That doesn't make any sense for a global GUI.
It's for npm, not nvm. It shows the installed packages in a project, the version that is installed and the latest available version which is handy. You can install/update packages too but don't see much use for that since the CLI is there but the displaying of info is decent.
Yeah sort of. I wouldn't use it to replace npm CLI or anything (even though you can), but like I said being able to glance at installed modules and see the different versions (installed vs latest) is a nice thing to have.
Why are you using 3 different JavaScript linters, instead of just 1? Especially since one of them (JSCS) was merged with the other (ESLint). There was a blog post about this in April[0] and even the front page of JSCS says that it was merged with ESLint[1], so why use both of them, in addition to yet another linter?
[0] http://eslint.org/blog/2016/04/welcoming-jscs-to-eslint
[1] http://jscs.info/