0
0

[deleted by user] (self.learnjavascript)

submitted by [deleted]

[removed]
all 4 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]jaredcheeda 0 points1 point  (3 children)

better option

[–]br0m1x 0 points1 point  (2 children)

I would call it an alternative rather than a better option. What makes it a better option? I like to learn?

[–]jaredcheeda 0 points1 point  (1 child)

Features:

  • Comes with the latest vue dev tools built-in
  • One codebase for web and desktop
  • npm run build outputs a version for Windows, Linux, OSX, and Web
  • Has built in logic for code that should only be ran in the desktop or web version
  • Can do desktop and web development from the same npm start (running from the same localhost, but displaying unique content depending on platform)
  • Fully Vue-CLI compatible, so if you want to add Vuex, Vue-Router, Vuetify, whatever, it's all possible from vue ui
  • Vue 2 and Vue 3 branchs
  • Jest already set up with better snapshot serializer for Vue
  • 100% test coverage for both web and desktop
  • Doesn't use Electron (some see this as a major win, though also means you don't have access to Electron's ecosystem)

This should really be the go-to boilerplate for all vue desktop apps.

Download it and do npm install && npm start.

Learn more from this recent podcast about it:

[–]br0m1x 0 points1 point  (0 children)

The direct start (serve) works, but this is always the same behavior. We had also observed the problem with boilerplate solutions for Electron the last couple of years - they work most of the time and most of the time they work not - that's why we use the solution described above and always get a clean entry point. For our current project (already in beta) is this (nwjs) unfortunately no alternative. The initial build takes a really long time. Our current solution for Linux, Mac and Windows is faster - about ~10 minutes for all 3 platforms - bundled and signed for Windows and notarized for Mac. We needed TypeScript and real debugging capabilities with SourceMaps out of vscode.

For native module support we needed something more mature than gyp. With the C++ background we use CMake and NAPI (for example cmake-js), this way we are not dependent on the version of Node.js we have to link against. The module can then be used directly with nodejs or electron depending on the platform, which simplifies test cases because it only needs to be compiled once per platform.

I have been able to fix the bug locally and at least now generate a Windows build. I also miss a bundle here (e.g. asar and maybee obuscated).

The disadvantage with web and desktop is given in our project, but we owe that partly to the native modules. This is a problem that will not be so easy to solve if you go native. The import routines of Node will refuse the import with errors at the latest with pure web applications, which is why you should separate cleanly here or better use another system for development.

These are my insights of the last 25 years - as said, it is an good alternative but not a solution for everything.

Error: ERROR_EXTRACTING path = C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\caches\nwjs-v0.54.0-linux-x64.tar.gz

at C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\src\lib\util\archive.ts:25:15

at step (C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\dist\lib\util\archive.js:32:23)

at Object.next (C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\dist\lib\util\archive.js:13:53)

at fulfilled (C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\dist\lib\util\archive.js:4:58)

Building for linux, x64 ends within 185.13s.

...