hi,
i’m konrad and i just reworked a lot of haml/sass/js code from the coquelicot codebase :). we currently use coquelicot from the debian repositories on teilen.systemausfall.org and i wanted to support mobile devices for our users.
you can find the code here: https://git.hack-hro.de/kmohrf/coquelicot/tree/redesign
i would like to see these changes in the upstream repository and also have plans to work on the js codebase some more. but before i do that i would like to hear if anyone of the current maintainers and/or contributors has some comments on my progress and the changes i’ve made.
if you’re fine with what you’re seeing now i would start to implement a modern js-build-stack. this would include:
* javascript build dependencies managed by npm * a es6/es-2015 codebase based on modules * a minified javascript distribution build via webpack
what i’ve liked about the current codebase is that i could just start changing things after i installed the ruby deps. i’m not sure i can achieve the same thing with the javascript-build like you did with the sass integration (auto-rebuilds on change). but what is surely missing from the current javascript codebase are modularity and tests and this would be a start.
comments appreciated :)
bye konrad
ping?
On 18.10.2016 23:27, Konrad Mohrfeldt wrote:
hi,
i’m konrad and i just reworked a lot of haml/sass/js code from the coquelicot codebase :). we currently use coquelicot from the debian repositories on teilen.systemausfall.org and i wanted to support mobile devices for our users.
you can find the code here: https://git.hack-hro.de/kmohrf/coquelicot/tree/redesign
i would like to see these changes in the upstream repository and also have plans to work on the js codebase some more. but before i do that i would like to hear if anyone of the current maintainers and/or contributors has some comments on my progress and the changes i’ve made.
if you’re fine with what you’re seeing now i would start to implement a modern js-build-stack. this would include:
- javascript build dependencies managed by npm
- a es6/es-2015 codebase based on modules
- a minified javascript distribution build via webpack
what i’ve liked about the current codebase is that i could just start changing things after i installed the ruby deps. i’m not sure i can achieve the same thing with the javascript-build like you did with the sass integration (auto-rebuilds on change). but what is surely missing from the current javascript codebase are modularity and tests and this would be a start.
comments appreciated :)
bye konrad
Coquelicot mailing list Coquelicot@potager.org https://listes.potager.org/listinfo/coquelicot
To unsubscribe from this list, send an email to Coquelicot-unsubscribe@potager.org.
Hi Konrad,
Konrad Mohrfeldt:
ping?
Really sorry I haven't replied to you earlier. I'm glad you've pinged us again, your initial email was lost in travel and too much backlog.
On 18.10.2016 23:27, Konrad Mohrfeldt wrote:
i’m konrad and i just reworked a lot of haml/sass/js code from the coquelicot codebase :). we currently use coquelicot from the debian repositories on teilen.systemausfall.org and i wanted to support mobile devices for our users.
you can find the code here: https://git.hack-hro.de/kmohrf/coquelicot/tree/redesign
i would like to see these changes in the upstream repository and also have plans to work on the js codebase some more. but before i do that i would like to hear if anyone of the current maintainers and/or contributors has some comments on my progress and the changes i’ve made.
I've never been a good web developper, so I'm really happy to see your attempt to improve Coquelicot. Mobile support is especially welcome. :)
I'm not sure what kind of feedback you want on the current redesign. It's already quite an improvement! There's probably a few things which I would like to discuss, like loosing the byte counters that were displayed with the progress bar, but it's not clear to me how ready was the proposal.
if you’re fine with what you’re seeing now i would start to implement a modern js-build-stack. this would include:
- javascript build dependencies managed by npm
- a es6/es-2015 codebase based on modules
- a minified javascript distribution build via webpack
what i’ve liked about the current codebase is that i could just start changing things after i installed the ruby deps. i’m not sure i can achieve the same thing with the javascript-build like you did with the sass integration (auto-rebuilds on change). but what is surely missing from the current javascript codebase are modularity and tests and this would be a start.
As a Debian developper, my primary deployment target is Debian. So any external JavaScript library needs to be packaged in Debian before Coquelicot can depend on it.
With that in mind, I would not necessarily be opposed to using npm—Coquelicot is already using Bundler—but it should be as straightforward as possible to use, develop and deploy. As I don't have any real experience with it, I can't really judge how good is it.
Please tell me if you need more help from me to enable you to improve Coquelicot! :)
hi,
On 28.12.2016 12:18, Lunar wrote:
Konrad Mohrfeldt:
ping?
Really sorry I haven't replied to you earlier. I'm glad you've pinged us again, your initial email was lost in travel and too much backlog.
I’ve started to wonder if debian folks like web-developers :P. I’d understand. Packaging the JavaScript/Node ecosystem must be hell :D.
I've never been a good web developper, so I'm really happy to see your attempt to improve Coquelicot. Mobile support is especially welcome. :)
I'm not sure what kind of feedback you want on the current redesign. It's already quite an improvement! There's probably a few things which I would like to discuss, like loosing the byte counters that were displayed with the progress bar, but it's not clear to me how ready was the proposal.
The only feedback i really needed was if there’s a chance that these changes would be merged :). I’m happy about suggestions though and the byte counter probably just slipped through when i made my changes.
As a Debian developper, my primary deployment target is Debian. So any external JavaScript library needs to be packaged in Debian before Coquelicot can depend on it.
I’ll try to keep dependencies to a minimum and stick with vanilla JavaScript whenever I can, but in order to do so we have to make a decision regarding browser support. I guess we could support all browser with EcmaScript 5 Support [1], which would include IE9 with only a single dependency to node-es6-promise (available since stretch). That would be everything we need to reimplement the current JavaScript code production-dependency-wise. Are build-dependencies required to be packaged in Debian as well?
With that in mind, I would not necessarily be opposed to using npm—Coquelicot is already using Bundler—but it should be as straightforward as possible to use, develop and deploy. As I don't have any real experience with it, I can't really judge how good is it.
Well… it’s everything we have right now :). As I stated before I liked that the project just worked™ when I cloned the repository. The js build system would introduce webpack as a build tool. Webpack receives an entry file, recursively resolves dependencies (import/require statements) and outputs a single js file that would be added as the only script tag in the rendered HTML page. It also supports a watch mode, so we could keep the original "just works™" behaviour if we spin up webpack when starting the development server.
Please tell me if you need more help from me to enable you to improve Coquelicot! :)
I’d like to keep my hands from the ruby codebase in order to focus on the other tasks, so if anyone could take care of the webpack watchmode integration once it’s ready that’d be awesome. apart from that I only have two remarks/questions:
1. Are you fine with the separate repository where you can pull my changes? 2. If you have any comments regarding Debian compatibility just tell me. I’m not familiar with most of the packaging guidelines :).
bye
konrad
Konrad Mohrfeldt:
Lunar:
As a Debian developper, my primary deployment target is Debian. So any external JavaScript library needs to be packaged in Debian before Coquelicot can depend on it.
I’ll try to keep dependencies to a minimum and stick with vanilla JavaScript whenever I can, but in order to do so we have to make a decision regarding browser support. I guess we could support all browser with EcmaScript 5 Support [1], which would include IE9 with only a single dependency to node-es6-promise (available since stretch). That would be everything we need to reimplement the current JavaScript code production-dependency-wise. Are build-dependencies required to be packaged in Debian as well?
One thing that is unclear to me for now: do you want to implement new features that require reimplementing the current JavaScript code? Except cleaner code, what is to be gained by switching to ES5?
The js build system would introduce webpack as a build tool. Webpack receives an entry file, recursively resolves dependencies (import/require statements) and outputs a single js file that would be added as the only script tag in the rendered HTML page. It also supports a watch mode, so we could keep the original "just works™" behaviour if we spin up webpack when starting the development server.
I don't see a Debian package for Webpack. :(
Would you know of any Ruby library that would provide similar features? Packaging new gems for Debian is quite easy.
I see Debian as a ruby-uglifier package which is a wrapper for UglifyJS. I'd rather try to avoid adding a strict build dependency on Node.js. The above package requires Node.js for example.
I’d like to keep my hands from the ruby codebase in order to focus on the other tasks, so if anyone could take care of the webpack watchmode integration once it’s ready that’d be awesome.
I could have a look.
apart from that I only have two remarks/questions:
- Are you fine with the separate repository where you can pull my changes?
Sure. :)
- If you have any comments regarding Debian compatibility just tell me. I’m not familiar with most of the packaging guidelines :)
From the top of my head: watch out for the Crowford (“don't use for evil”) license. It's non-free and caused us huge pain in the past.
hi,
On 07.01.2017 21:39, Lunar wrote:
One thing that is unclear to me for now: do you want to implement new features that require reimplementing the current JavaScript code? Except cleaner code, what is to be gained by switching to ES5?
Apart from becoming cleaner it also becomes testable, because right now I don’t really see how that would work out.
The js build system would introduce webpack as a build tool. Webpack receives an entry file, recursively resolves dependencies (import/require statements) and outputs a single js file that would be added as the only script tag in the rendered HTML page. It also supports a watch mode, so we could keep the original "just works™" behaviour if we spin up webpack when starting the development server.
I don't see a Debian package for Webpack. :(
Would you know of any Ruby library that would provide similar features? Packaging new gems for Debian is quite easy.
I see Debian as a ruby-uglifier package which is a wrapper for UglifyJS. I'd rather try to avoid adding a strict build dependency on Node.js. The above package requires Node.js for example.
The thing is that webpack does more than uglification (actually it doesn’t do uglification at all; it utilizes uglify). The most important part is the ability to resolve common-js modules. Debian has a browserify-lite package. That’s still node-js, but is included since jessie. Probably works too. That would leave out Babel for transforming ES6 code to ES5 but as that is mostly syntax I don’t see a problem with it.
From the top of my head: watch out for the Crowford (“don't use for evil”) license. It's non-free and caused us huge pain in the past.
Most node modules are MIT, but I keep an eye on it. Everything in Debian should work, right?
bye
konrad
Konrad Mohrfeldt:
On 07.01.2017 21:39, Lunar wrote:
One thing that is unclear to me for now: do you want to implement new features that require reimplementing the current JavaScript code? Except cleaner code, what is to be gained by switching to ES5?
Apart from becoming cleaner it also becomes testable, because right now I don’t really see how that would work out.
Good, I love tests. :)
At some point, I was hoping I could investigate the PhantomJS driver for Selenium. This should allow to do full stack testing, including the JavaScript parts, expanding the current Ruby test suite. But I don't plan to work on this soon.
The js build system would introduce webpack as a build tool. Webpack receives an entry file, recursively resolves dependencies (import/require statements) and outputs a single js file that would be added as the only script tag in the rendered HTML page. It also supports a watch mode, so we could keep the original "just works™" behaviour if we spin up webpack when starting the development server.
I don't see a Debian package for Webpack. :(
Would you know of any Ruby library that would provide similar features? Packaging new gems for Debian is quite easy.
I see Debian as a ruby-uglifier package which is a wrapper for UglifyJS. I'd rather try to avoid adding a strict build dependency on Node.js. The above package requires Node.js for example.
The thing is that webpack does more than uglification (actually it doesn’t do uglification at all; it utilizes uglify). The most important part is the ability to resolve common-js modules. Debian has a browserify-lite package. That’s still node-js, but is included since jessie. Probably works too. That would leave out Babel for transforming ES6 code to ES5 but as that is mostly syntax I don’t see a problem with it.
Looks good! :)
From the top of my head: watch out for the Crowford (“don't use for evil”) license. It's non-free and caused us huge pain in the past.
Most node modules are MIT, but I keep an eye on it. Everything in Debian should work, right?
If it's already in Debian, it's perfect. :)
Thanks,
-
Konrad Mohrfeldt -
Lunar