Show HN: Ndm – Npm Desktop Manager
720kb.github.io
720kb.github.io
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?
if you can please contribute, just PR PR PR PR :)
If anyone has an Electron app and wants/needs help with cross-platform packaging, feel free to contact me.
"As soon as we are sure that the project is stable, it will be delivered to the other OSs." :)
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.
IMO, the question should always be, why native?
- Speed
- Native UI
- Native OS hooks
> 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.
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.
Also sometimes laggy, when you operate with huge volume of data.
Take as an example editors. You can't compare the speed / size of Sublime vs Atom. Both are cross-platform. First is written with C++ ( AFAIK ).
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?
[0] https://github.com/720kb/ndm#i-love-the-shell-why-use-an-app
[1] https://github.com/720kb/ndm/blob/master/lib/js/npm/npm-api....
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.
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 can't. At least if we're talking about people who can't use a CLI or read JSON.
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.
If I had a job where I couldn't use the command line, I would quit or not take the job to begin with.
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.
387M of extracted/mounted data;
314M in the Contents/Frameworks directory (which is where Electron is);
73M in the Contents/Resources directory (which is where the application is);
73M is actually the size of the "Contents/Resources/app/node_modules" directory :D
Glad that you find it useful, many thanks!
I like this solution better because it manages all projects compared to opening each project separate in an IDE.
A few commands in my terminal can be equal in functionality to what this app does but I can see myself using this app regardless.
Isn't Electron meant to be cross platform? Shouldn't this also work on Windows and Linux?
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 ;)
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 ;)
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.
I guess the git analogy would be something like gitk?