I'd be able to get something conceivably working sooner than later. Creating an essential structure for a plugin like this could be nice. It could be conceivably be used for instance in adding flow typing as a prototype until being added to the core ESDoc functionality.
Roy Sutton
@webOS101
Hmm.
Michael Leahy
@typhonrt
Basically it's a neat problem, but I do use vanilla ES6 semantics for all of TyphonJS, so not one I immediately have a scratch to solve.
Yeah.. I'd have to see a larger snippet. BTW ignore esdoc-es7-plugin.
Roy Sutton
@webOS101
Yeah, it's clearly deprecated.
Michael Leahy
@typhonrt
The typhonjs-escomplex codebase does well I guess "complex" AST processing. I'm actually going to be making esdoc-plugin-escomplex which will use typhonjs-escomplex and generate a whole new section for ESDoc output similar to plato, but with updated D3 graphs with full ES6 semantic support for source code complexity.
Michael Leahy
@typhonrt
Are you sure you are using the fork just to be sure? This doesn't cause an AST parsing failure. https://astexplorer.net/#/CAStNWRKu9 Do you have a larger stack trace?
Roy Sutton
@webOS101
I was wondering the same thing. I was pretty sure I had unlinked the master branch of esdoc that I had tested. But perhaps I had installed the npm version.
Michael Leahy
@typhonrt
Easy way to be sure is to nuke node_modules check the package.json and just do npm install again.
Roy Sutton
@webOS101
That's better. I must have had a lingering version of the original project.
Roy Sutton
@webOS101
Oh, btw, if you know some folks in the bay area looking for a framework engineer position we're trying to fill a spot. I can provide a link.
Michael Leahy
@typhonrt
Not offhand as things go.
Roy Sutton
@webOS101
Yep, hard find people with framework experience.
Michael Leahy
@typhonrt
Good to know.. I do contracting from time to time, but will be plugging along with my current efforts soon again. IE I could be convinced to do a short contract to create that plugin for stateless function component creation especially if part or all of it was open sourced.. :shipit:
Roy Sutton
@webOS101
I shall keep that mind. We will be open sourcing all this soon.
How close is your app?
Michael Leahy
@typhonrt
Very cool. Looking forward to seeing what you guys get out there. I'm doing a bunch of other ESDoc related projects too soon for automatic documentation generation and publication on commits to repos via CI, so some interesting tooling.
re: how close is the app.. Well. I've got plenty of work to do on TyphonJS then launching the actual apps themselves and then maintenance, so hands full there for a while.
I'd think that particular ESDoc plugin though I could knock out in 2 weeks or less. I'm just curious, but what open source license are you guys going to use?
Roy Sutton
@webOS101
Apache 2.0 is our preferred license.
Michael Leahy
@typhonrt
That's cool. I put out all TyphonJS modules MPLv2, but Apache is great too.
Roy Sutton
@webOS101
yep, yep. I saw that your stuff was MPL.
Michael Leahy
@typhonrt
So is this Enyo related on your side?
Roy Sutton
@webOS101
This is the successor to Enyo.
Michael Leahy
@typhonrt
I took a brief look and the site describes using CJS.
Yeah.. I figured it would be a rewrite.
or successor..
Roy Sutton
@webOS101
Enyo was great but thing have changed a lot since it was first invented.
Still is great, I guess. :)
But some architectural decisions limit performance, particularly on low-end hardware.
Michael Leahy
@typhonrt
Definitely; it is a pretty great time to do a greenfield effort right now. I assume low-end hardware certain mobile devices?
Roy Sutton
@webOS101
I couldn't speculate on any devices.
Michael Leahy
@typhonrt
I've got a whole unreleased app framework based on my backbone-es6 fork that uses material design lite v1.0. Waiting on soon / forthcoming v2 of MDL to refactor and release.
Roy Sutton
@webOS101
Nice.
Michael Leahy
@typhonrt
Works great on phones, but I guess Enyo was also targeted at set top boxes / TVs and such as well..
Roy Sutton
@webOS101
Yep, first version was on the HP TouchPad and was destined for the phones... Alas.
Michael Leahy
@typhonrt
I'm not completely sold on the JS for phone apps; ReactNative what have you.. But then again that's because I do in depth OpenGL support on the phone. ;P
Roy Sutton
@webOS101
Understand. It has been disappointing to see the progress of Chrome on Android.
Michael Leahy
@typhonrt
Yeah.. I'm definitely a bit wary / bearish on that front. Also after 8 years of Android and, erm, seeing some engineering faltering there I'm definitely not jumping into the Angular or for that matter React camp. Just viewing from a distance for the time being.
Roy Sutton
@webOS101
Had some high hopes for web components, but it doesn't seem to be bearing any fruit.
Michael Leahy
@typhonrt
Google is a strange beast, but it's nice things are being tried out by someone. I'm going for a much more minimal framework on the web app side of things; works great with Electron too.. I haven't tried PhoneGap or the like yet. Are you guys then going to be targeting React Native for this successor effort?
Roy Sutton
@webOS101
We're keeping tabs on React Native but we're targeting the web engine right now.
Michael Leahy
@typhonrt
Are you guys using Webpack or another package manager?
Roy Sutton
@webOS101
yep, webpack.
Michael Leahy
@typhonrt
It seems like a lot of the React world leans that way. I'm working w/ JSPM / SystemJS, which I find to be rather handy / less opinionated (per se) / responsive maintainer. So part of TyphonJS is adding tooling to JSPM / SystemJS for bundling and soon containerizing the result and ultimately CI / CD tooling.
Roy Sutton
@webOS101
Yep, we looked at jspm and there were a lot of things to like.
Webpack is certainly a pain-point and a part of the ecosystem that we're trying to address at the framework level.
Michael Leahy
@typhonrt
I think for certain use cases Webpack has differentiated built-in features like hot code loading compared to JSPM. I like that JSPM is more of a tool than framework. It's also why I'll be angling in using rkt instead of docker w/ Kubernetes for orchestration and whatever other existing open source tooling as possible built around this direction.
Josh Wedekind
@halfnibble
Hello Michael, should we create a separate room for Backbone.js conversations?
Michael Leahy
@typhonrt
Hi Josh. I think it's fine to discuss things here as this channel is not high traffic by any means and backbone-esnext is falling under the larger TyphonJS umbrella for the time being. For the next several months I'm finishing up TJSDoc which is close to final mile before release. I'm kind of on vacation this week and first half of next as well, so might not be around a bunch. What do you think is a good topic to discuss. My general plan which I think I outlined on the BB issues forum is to upgrade backbone-es6 to 1.4 when released. Before things progress to backbone-esnext and fully modularizing all of the individual components of BB with separate repos / NPM modules I'd like to get a solid testing framework up for backbone-es6 which will help in maintaining compatibility for removing Underscore where possible w/ backbone-esnext.