4 ms·

Requirements: Node and npm - http://nodejs.org/ Node package manager for the Cordova CLI and Grunt Cordova CLI - https://github.com/

Requirements: Node and npm - http://nodejs.org/ Node package manager for the Cordova CLI and Grunt Cordova CLI - https://github.com/apache/cordova-cli/ Cordova / PhoneGap command line interface npm install -g cordova Grunt - http://gruntjs.com/ Build tool for minimising, running and tests npm install -g grunt-cli PhantomJS - http://phantomjs.org/ Headless webkit for running tests Cordova-icon and Cordova-splash - https://github.com/AlexDisler/cordova-icon/ and https://github.com/AlexDisler/cordova-splash/ npm install -g cordova-icon and npm install cordova-splash Nope. Nope nope nope.

Karunamon 10y ago
I'm not clear on what exactly your problem is here.
- dsp1234 10y ago
  I'm also curious about what the problem is. If the goal is a simple API client that has iOS/Android/Desktop compatibility, then Cordova seems a reasonable choice. Would the above commenter have preferred 4+ separate projects instead?
  - jernfrost 10y ago
    You seem to imply 4 projects is 4x the time. In my experience I spent more than 2x the time just getting a Cordova project up an running compared to just building the whole dam thing from scratch on iOS. Why? Cordova kept changing all the time. Documentation sucked. It was buggy. The tools were substandard and it had inconsistent behavior across platforms. Terrible experience. I have colleagues who had the same terrible experience but they still cling to the idea that it will somehow work out in the end. The idea of one code to rule all the platforms is just too enticing. I don't doubt that some people will be more effective at using Cordova. The problem is people treat this decision as if it is independent of the people who will build the solution. Somebody with years of training doing JavaScript and practically no experience with writing native code will likely be much faster with Cordova. That is why these projects exist in the first place. There are so many JavaScript developers out there. For them even a crappy setup like Cordova will still be faster than native development. But in reverse if you actually got good experience with native platforms and know the tools, Cordova is not going to deliver. You wont have access to the kind of debugging tools, editors, type checking, GUI builders, documentation etc you get on a native platform, which makes a native developer work efficiently.
- frabbit 10y ago
  I assume it's against a bunch of dodgy software from a source which is perceived as being less eyeballed than a distribution's repository.
- wyager 10y ago
  Not that guy, but that's a ridiculously bloated set of requirements.
  - Karunamon 10y ago
    The language it's written in, the testing framework, and the support library that lets it target more platforms? That doesn't seem too bloated to me.
    - pritambaral 10y ago
      > That doesn't seem too bloated to me. For a security software? It may not be too bloated for a web app, but for a piece of security software it is absolutely bloated. Note: I'm not talking from a utility point-of-view, that "C'mon, writing a security-related app doesn't have to use so much stuff". I'm talking from a safety point-of-view, that "Security stuff should absolutely not have such a large code footprint".
  - BinaryIdiot 10y ago
    Almost all of those requirements are only for developing / testing the repository. That's not uncommon for most languages / projects.
  - mmanfrin 10y ago
    But... it really isn't. This is kind of the norm for node projects + cordova stuff.
- d_theorist 10y ago
  This is a piece of software that we are supposed to trust with our passwords. It depends on a long list of crappy bloated software, including something from an apparently-non-standard source, and including a package manager that is probably going to pull in yet more untold reams of crappy, unaudited, JavaScript code from the four corners of the internet at build time. It would not surprise me if this ended up clocking in at millions of lines of code by the time it built. Just say no.
  - dsp1234 10y ago
    It depends on a long list of crappy bloated software If you don't actually want to test the software, and just want to create a production mobile/desktop application, then it depends on codova, cordova-icon, cordova-splash, semver and it's own source code. That's not a long list. If you want to test it, then it's probably not a shock that it pulls in testing frameworks for testing javascript UIs. including something from an apparently-non-standard source Here are the listed requirements from above: http://nodejs.org/ http://nodejs.org/ npm install -g cordova npm install -g grunt-cli http://phantomjs.org/ http://phantomjs.org/ npm install -g cordova-icon and npm install cordova-splash Can you point out which of these is 'apparently-non-standard'?
    - pritambaral 10y ago
      > That's not a long list It's not the list of top-level pieces of software, it's the amount of code that could have contact with the plaintext or the encryption keys. > If you don't actually want to test And build! Don't forget the building itself. It's not so much harder to exploit an app even if all you have access to is its build stage. ---- This is security software we are talking about. The more lines of code that touch it, the more risky it is of being vulnerable. Not to mention the sheer astronomical difficulty of auditing it. From what I know of the industry, I wouldn't be surprised if a security auditor plain refused to touch this because of the sheer magnitude. And that's without even mentioning it uses npm.
      - Freak_NL 10y ago
BinaryIdiot 10y ago
Care for elaborate on the "nopes"? Grunt, PhantomJS and node are essentially for dev support and the rest are for running it. It's not that heavy.

Karunamon 10y ago

I'm not clear on what exactly your problem is here.

dsp1234 10y ago
I'm also curious about what the problem is. If the goal is a simple API client that has iOS/Android/Desktop compatibility, then Cordova seems a reasonable choice. Would the above commenter have preferred 4+ separate projects instead?
- jernfrost 10y ago
  You seem to imply 4 projects is 4x the time. In my experience I spent more than 2x the time just getting a Cordova project up an running compared to just building the whole dam thing from scratch on iOS. Why? Cordova kept changing all the time. Documentation sucked. It was buggy. The tools were substandard and it had inconsistent behavior across platforms. Terrible experience. I have colleagues who had the same terrible experience but they still cling to the idea that it will somehow work out in the end. The idea of one code to rule all the platforms is just too enticing. I don't doubt that some people will be more effective at using Cordova. The problem is people treat this decision as if it is independent of the people who will build the solution. Somebody with years of training doing JavaScript and practically no experience with writing native code will likely be much faster with Cordova. That is why these projects exist in the first place. There are so many JavaScript developers out there. For them even a crappy setup like Cordova will still be faster than native development. But in reverse if you actually got good experience with native platforms and know the tools, Cordova is not going to deliver. You wont have access to the kind of debugging tools, editors, type checking, GUI builders, documentation etc you get on a native platform, which makes a native developer work efficiently.
frabbit 10y ago
I assume it's against a bunch of dodgy software from a source which is perceived as being less eyeballed than a distribution's repository.
wyager 10y ago
Not that guy, but that's a ridiculously bloated set of requirements.
- Karunamon 10y ago
  The language it's written in, the testing framework, and the support library that lets it target more platforms? That doesn't seem too bloated to me.
  - pritambaral 10y ago
    > That doesn't seem too bloated to me. For a security software? It may not be too bloated for a web app, but for a piece of security software it is absolutely bloated. Note: I'm not talking from a utility point-of-view, that "C'mon, writing a security-related app doesn't have to use so much stuff". I'm talking from a safety point-of-view, that "Security stuff should absolutely not have such a large code footprint".
- BinaryIdiot 10y ago
  Almost all of those requirements are only for developing / testing the repository. That's not uncommon for most languages / projects.
- mmanfrin 10y ago
  But... it really isn't. This is kind of the norm for node projects + cordova stuff.
d_theorist 10y ago
This is a piece of software that we are supposed to trust with our passwords. It depends on a long list of crappy bloated software, including something from an apparently-non-standard source, and including a package manager that is probably going to pull in yet more untold reams of crappy, unaudited, JavaScript code from the four corners of the internet at build time. It would not surprise me if this ended up clocking in at millions of lines of code by the time it built. Just say no.
- dsp1234 10y ago
  It depends on a long list of crappy bloated software If you don't actually want to test the software, and just want to create a production mobile/desktop application, then it depends on codova, cordova-icon, cordova-splash, semver and it's own source code. That's not a long list. If you want to test it, then it's probably not a shock that it pulls in testing frameworks for testing javascript UIs. including something from an apparently-non-standard source Here are the listed requirements from above: http://nodejs.org/ http://nodejs.org/ npm install -g cordova npm install -g grunt-cli http://phantomjs.org/ http://phantomjs.org/ npm install -g cordova-icon and npm install cordova-splash Can you point out which of these is 'apparently-non-standard'?
  - pritambaral 10y ago
    > That's not a long list It's not the list of top-level pieces of software, it's the amount of code that could have contact with the plaintext or the encryption keys. > If you don't actually want to test And build! Don't forget the building itself. It's not so much harder to exploit an app even if all you have access to is its build stage. ---- This is security software we are talking about. The more lines of code that touch it, the more risky it is of being vulnerable. Not to mention the sheer astronomical difficulty of auditing it. From what I know of the industry, I wouldn't be surprised if a security auditor plain refused to touch this because of the sheer magnitude. And that's without even mentioning it uses npm.
    - Freak_NL 10y ago

BinaryIdiot 10y ago

Care for elaborate on the "nopes"? Grunt, PhantomJS and node are essentially for dev support and the rest are for running it. It's not that heavy.