{"action":"created","issue":{"url":"https://api.github.com/repos/felixhageloh/uebersicht/issues/123","repository_url":"https://api.github.com/repos/felixhageloh/uebersicht","labels_url":"https://api.github.com/repos/felixhageloh/uebersicht/issues/123/labels{/name}","comments_url":"https://api.github.com/repos/felixhageloh/uebersicht/issues/123/comments","events_url":"https://api.github.com/repos/felixhageloh/uebersicht/issues/123/events","html_url":"https://github.com/felixhageloh/uebersicht/issues/123","id":100381111,"number":123,"title":"Übersicht Wishes","user":{"login":"hawkrives","id":464441,"avatar_url":"https://avatars.githubusercontent.com/u/464441?v=3","gravatar_id":"","url":"https://api.github.com/users/hawkrives","html_url":"https://github.com/hawkrives","followers_url":"https://api.github.com/users/hawkrives/followers","following_url":"https://api.github.com/users/hawkrives/following{/other_user}","gists_url":"https://api.github.com/users/hawkrives/gists{/gist_id}","starred_url":"https://api.github.com/users/hawkrives/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hawkrives/subscriptions","organizations_url":"https://api.github.com/users/hawkrives/orgs","repos_url":"https://api.github.com/users/hawkrives/repos","events_url":"https://api.github.com/users/hawkrives/events{/privacy}","received_events_url":"https://api.github.com/users/hawkrives/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":30,"created_at":"2015-08-11T18:52:30Z","updated_at":"2016-05-18T15:47:35Z","closed_at":null,"body":"*Note: Please feel free to close this issue. It's a bunch of stuff I'd like to work on for Übersicht, but haven't ever gotten around to. I'm just putting them out here to get some, er, initial feedback on their viability.*\r\n\r\nI have several things that I would like to do with Übersicht, in increasing levels of viability/intrusiveness. However, I believe that all of these changes could be made in a completely backwards-compatible fashion, so that *all* existing widgets would continue to work. \r\n\r\nI've had this document floating around since about October 2014.\r\n\r\n\r\n## Simplify the build system\r\nGrunt is overkill for what Übersicht does with it. I would like to remove grunt entirely, and replace it with npm scripts. \r\n\r\n`package.json`\r\n```json\r\n\"config\": {\r\n  \"browserify\": \"-t coffeeify --no-detect-globals\"\r\n}\r\n\"scripts\": {\r\n  \"jasmine:fs\": \"npm test\",\r\n  \"spec\": \"npm run jasmine:fs && npm run browserify:specs && npm run jasmine\",\r\n  \"spec:frontend\": \"npm run browserify:specs && npm run jasmine:src\",\r\n  \"browserify:server\": \"browserify -e server.coffee -o release/server.js $npm_package_config_browserify {-i\\  {fs,path,child_process,connect,coffee-script,stylus,nib,fsevents}}\",\r\n  \"browserify:client\": \"browserify -e client.coffee -o release/public/main.js $npm_package_config_browserify {-i\\  {connect,fs,path,child_process,fsevents,coffee-script,stylus,nib,minimist}}\",\r\n  \"browserify:specs\": \"browserify -e specs/frontend/**/*_spec.coffee -o release/public/main.js $npm_package_config_browserify {-i\\  {stylus,nib}}\",\r\n  \"jasmine:src\": \"jasmine JASMINE_CONFIG_PATH=./specs/jasmine.json\",\r\n  \"release\": \"npm run browserify:server & npm run browserify:client & wait\",\r\n  \"default\": \"npm run spec && npm run release && npm run watch\",\r\n  \"start\": \"coffee server.coffee\",\r\n  \"test\": \"jasmine-node --coffee --captureExceptions --forceexit spec/backend\",\r\n  \"watch\": \"nodemon --ext=styl,coffee -w src/css/**/*.styl -w src/**/*.coffee -w client.coffee -w server.coffee -w spec/**/*_spec.coffee --exec 'npm run spec && npm run release'\"\r\n},\r\n\"devDependencies\": {\r\n\t\"jasmine\": \"\",\r\n\t\"nodemon\": \"\",\r\n}\r\n```\r\n\r\n`specs/jasmine.json` (for [`jasmine`](https://www.npmjs.com/package/jasmine))\r\n```json\r\n{\r\n  \"spec_dir\": \"specs\",\r\n  \"spec_files\": [\r\n    \"frontend_specs.js\"\r\n  ],\r\n  \"helpers\": [\r\n    \"vendor/*.js\"\r\n  ]\r\n}\r\n```\r\n\r\nThey can be run by `npm run <name>`, or, in the case of `test`, `serve`, and any others that shadow the name of an `npm` command, by `npm <command>`.\r\n\r\nInstead of `grunt release`, you'd run `npm run release`.\r\n\r\n\r\n## Update dependencies\r\n- Sparkle has gotten some new releases recently – it's aliiive! (https://github.com/sparkle-project/Sparkle/releases).\r\n- Coffeescript has had *two* point releases since the version in `package.json`\r\n\r\n## Pin dependencies\r\nSpeaking of the `package.json`.\r\n\r\nI've run into several points of trouble while trying to hack on Übersicht, usually relating to semver ranges. In my opinion, they're great for libraries, but not so great for applications—it's too hard to ensure that everyone has the same version of things, which is a real problem when debugging.\r\n\r\nI'd like to specify absolute versions of dependencies / devDependencies in `package.json`, and use `npm shrinkwrap` to pin everything down. That way, when I change something, I won't be running into spurious compiler output changes ([`<cough>`pull 122`</cough>`](https://github.com/felixhageloh/uebersicht/pull/122#issuecomment-129936238)).\r\n\r\n\r\n## ES2015 (neè ES6)\r\nI really (really) like writing things in ES6. Of course, Safari doesn't support es6, but if you look at [kangax's tables][es6-compat], there's a column labeled \"Babel\". Babel can be run as part of a node server, and would allow Übersicht to run widgets written in ES6 as easily as it can run coffeescript widgets today. \r\n\r\nSee [pull #122](https://github.com/felixhageloh/uebersicht/pull/122#issuecomment-129936238).\r\n\r\n\r\n## Modules\r\nThe current widget system of being a JS object-minus-braces is nice, but I'd prefer to just be able to `export` the things that Übersicht requires and let the rest live in a file somewhere. Maybe run the files through browserify as part of the server process?\r\n\r\nI've been frustrated several times at not being able to declare variables at the top level of my JS widgets; bundling (and named exports) should solve that.\r\n\r\nES6 specifies the `export` keyword, to explicitly name exports, so all we'd need to do is change the bundling process—the \"grab attributes from an object\" code would continue to work exactly like it does now. \r\n\r\nBefore: (should continue to work!)\r\n\r\n```coffee\r\nrefreshFrequency: '1s'\r\nrender: () -> \"<p>Hi there</p>\"\r\n```\r\n\r\nAfter: (coffeescript)\r\n\r\n```coffee\r\nmodule.exports.refreshFrequency: '1s'\r\nmodule.exports.render: () -> \"<p>Hi there</p>\"\r\n```\r\n\r\nAfter: (es2015)\r\n\r\n```coffee\r\nexport let refreshFrequency = '1s'\r\nexport let render = () => \"<p>Hi there</p>\"\r\n```\r\n\r\n\r\n## React\r\nAs you mentioned in [issue #114](https://github.com/felixhageloh/uebersicht/issues/114#issuecomment-118026742), React is nice. \r\n\r\nI'd like to rebuild the widget system on top of react and webpack.\r\n\r\nWe could either let widgets opt-in to react support, via a file extension or something (`.react.js`?), or, with Babel support, just check what `render` returns.\r\n\r\nWe could probably use React's `dangerouslySetInnerHTML` to continue running existing widgets within React components.\r\n\r\nI read an interesting article recently about how to prevent a runtime error in user-supplied components from breaking the entire page; it seems like a [nice enough solution](https://nylas.com/blog/react-plugins)\r\n\r\n\r\n## Conclusion\r\n\r\nSo. That's what I've got.\r\nIf I were to work on any of these topics, would you perchance accept a pull request?\r\nIf you had your druthers, which (if any) would you prefer me to work on?"},"comment":{"url":"https://api.github.com/repos/felixhageloh/uebersicht/issues/comments/220069827","html_url":"https://github.com/felixhageloh/uebersicht/issues/123#issuecomment-220069827","issue_url":"https://api.github.com/repos/felixhageloh/uebersicht/issues/123","id":220069827,"user":{"login":"felixhageloh","id":367503,"avatar_url":"https://avatars.githubusercontent.com/u/367503?v=3","gravatar_id":"","url":"https://api.github.com/users/felixhageloh","html_url":"https://github.com/felixhageloh","followers_url":"https://api.github.com/users/felixhageloh/followers","following_url":"https://api.github.com/users/felixhageloh/following{/other_user}","gists_url":"https://api.github.com/users/felixhageloh/gists{/gist_id}","starred_url":"https://api.github.com/users/felixhageloh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/felixhageloh/subscriptions","organizations_url":"https://api.github.com/users/felixhageloh/orgs","repos_url":"https://api.github.com/users/felixhageloh/repos","events_url":"https://api.github.com/users/felixhageloh/events{/privacy}","received_events_url":"https://api.github.com/users/felixhageloh/received_events","type":"User","site_admin":false},"created_at":"2016-05-18T15:47:35Z","updated_at":"2016-05-18T15:47:35Z","body":"I'm not adding any restrictions to the web view, but it is known to be slower than Safari. I'm also still on an older version and apparently the latest one (WKWebView) is closer to Safari in performance. \r\n\r\nI'm hoping to upgrade to WKWebView but I haven't figured out how to show the debug console programmatically (any pointers welcome btw!)"}}