Comments (40)
I am interested in seeing where hoodie can go, and might be interested in helping with porting hoodie.js to JavaScript.
Have you got any thoughts on how it could be ported?
from hoodie.
once we have a few decent JS developers that would like to take over some ownership, I'd
- make a new branch and to the rewrite in it.
- I'd leave the specs intact, so we can make sure not to break anything.
- Once the rewrite is done, I'd rewrite the specs as well.
- make a pull request to master and discuss in the pull request
- Finally, merge the branch into master.
I'd also suggest to replace the Cakefile
thing with grunt
Sounds good?
from hoodie.
This looks like a very interesting project and I'm willing to contribute a few hrs/week on this if someone from the core team is willing to take real ownership.
from hoodie.
Welocme @rudasn
yes, I take real ownership, I'll make sure that things go smoothly and I'll make sure all your questions get answered, with high priority.
Would be great to have a few more developers. I'll also ask some JavaScript heros for advice on how to build & structure the core hoodie.js library
from hoodie.
I would like to contribute. This will help me to understand hoodie better.
from hoodie.
My fork does already have a basic grunt implementation. At the moment is just supports compiling and minifing but I'm working on the tests. 4ca7416
from hoodie.
I'd like to contribute to this effort too. Completely new to hoodie ATM though, so I need to get familiar with it before I dive in.
from hoodie.
Find me at IRC or ping me at Twitter for any questions, happy to help whenever I can
from hoodie.
Hey @gr2m, I'm really interested in helping with the rewrite.
from hoodie.
One problem I ran into while rewriting hoodie.js is to have .coffee and .js next to each other. Is there a good grunt build script which can handles CoffeScript and JavaScript files along each other good?
from hoodie.
putting myself down for this as well @gr2m
from hoodie.
@mroderick @rudasn @Acconut @jlank @svnlto
Thanks guys for offering support on this. I'll of course remain a core contributer myself, but besides that I'd love to invite you to become one yourself. I think the rewrite to JavaScript is a great way to get familiar with the overall product, and I'll make sure to be available enough to answer all your questions as fast as possible.
So, let's get this thing started :-)
I don't know about you, but I did not work on a modular library like Hoodie before, so I'd like to do some research on other libraries to find out how they structure the source code and how they do they build process.
So I'll start by looking into jQuery & Zepto, maybe you can suggest other libraries, or have already opinions on structure & Code?
Once we agree on the overall structure and build tools, I'll fork the project into it's own repository with own issues, so we can better collaborate on it and spilt up the work among us. I'm also a big fan of (remote) pair programming, it's a great way to get to know each other, exchange ideas and get lots of stuff done at the same time.
Looking forward to hear your thoughts on it!
from hoodie.
I think the rewrite to JavaScript is a great way to get familiar with the overall product
agreed.
I don't know about you, but I did not work on a modular library like Hoodie before, so I'd like to do some research on other libraries to find out how they structure the source code and how they do they build process.
I don't think the current approach is that far off to be honest, other libs like the one's you've mentioned above are doing the exact same thing. As long as it works I don't see anything wrong with it either.
Once we agree on the overall structure and build tools.
The current structure of the project seems fine, if we could use 'grunt' instead and reevaluated testing tools we should be good I think.
I'm also a big fan of (remote) pair programming, it's a great way to get to know each other, exchange ideas and get lots of stuff done at the same time.
This sounds great.
from hoodie.
What @svnlto said.
Just throwing an idea out there... What would be your thoughts on using an ES6 shim/compiler so that we are free to use some of the most recent features of javascript like classes and/or modules?
from hoodie.
@rudasn one of the reasons for the rewrite is to make hoodie.js more approachable for more people. One of the barriers we try to reduce is the need for a precompiler. I’m not saying this is a bad idea, but it should be weighed against the downsides :)
from hoodie.
What is the target compatibility? ES3? ES5?
+1 for pairing, I am in Berlin
from hoodie.
tl;dr: I'd go with ES5.
Regarding browser compatibility: IE 10 / latest Chrome / Firefox / Safari / mobile Safari / Android browser. So that gives us ES5 per default. To support older browsers, I'd ask them to load a separate shim.js before they load hoodie.js.
I agree that ES6 looks super exciting, but it's not even spec ready as far as I know. I'd go with ES5 for now, and maybe to another rewrite when we are fancy and browser support is wide enough. I don't think the rewrite would be much work at this point, the Hoodie Core will be quite slim. Modules like hoodie.email / hoodie.publish / hoodie.share will be in their own repos and can be handled separately.
from hoodie.
@mroderick @rudasn @Acconut @jlank
Hey guys,
@svnlto went ahead and got rid of CoffeeScript, replaced Cakefile with grunt, and introduced Test'em for cross browser testing. Thank Sven, awesome work!!
I've created a milestone to gather remaining things to do, feel free to grab one or add more:
https://github.com/hoodiehq/hoodie.js/issues?milestone=3&state=open
Also, there is still some weird JS code remaining from the CoffeeScript to JavaScript compilation, so just go ahead and tweak it in the v0.2
branch!
Let's continue farther discussion at #82
from hoodie.
@svnlto went ahead and got rid of CoffeeScript
As far as I can tell, @svnlto took the output of the CoffeeScript transpiler and is tidying that up for 0.2. Is that correct?
from hoodie.
@mroderick it's basically:
- replace Cakefile with grunt for building / testing / etc
- rewrite hoodie.js with all core modules to JavaScript, test against existing specs
- rewrite specs to JavaScript
but yes, you're correct.
Also, @gr2m I think we're good merging this.
from hoodie.
Morgan, if you'd like to dive into the code, I'm happy to pair and give you an intro on the overall structure and answer all your questions
—
Gregor Martynus
On Tue, Jun 25, 2013 at 9:36 AM, Sven Lito [email protected]
wrote:
@mroderick it's basically:
- replace Cakefile with grunt for building / testing / etc
- rewrite hoodie.js with all core modules to JavaScript, test against existing specs
[x] rewrite specs to JavaScript
Reply to this email directly or view it on GitHub:
but yes, you're correct.
#51 (comment)
from hoodie.
I was under the impression that the goal of the rewrite was to produce a more "JavaScript idiomatic" version of hoodie.js. To me, working from the build artefacts seems awkward and less likely to achieve the goal of making hoodie.js more approachable to more people (as you're practically writing coffeescript build artefacts by hand).
If we start from the build artefacts, we are going to have to live with them for a long time to come, and the intention of the programmer(s) won't be that clear.
Are you sure this is the path you want to take?
from hoodie.
take one of the files, rewrite it the way you'd love it to work, an explain how it's better than the current approach. Would love to see and understand your preference
—
Gregor Martynus
On Tue, Jun 25, 2013 at 10:31 AM, Morgan Roderick
[email protected] wrote:
I was under the impression that the goal of the rewrite was to produce a more "JavaScript idiomatic" version of hoodie.js. To me, working from the build artefacts seems awkward and less likely to achieve the goal of making hoodie.js more approachable to more people (as you're practically writing coffeescript build artefacts by hand).
If we start from the build artefacts, we are going to have to live with them for a long time to come, and the intention of the programmer(s) won't be that clear.Are you sure this is the path you want to take?
Reply to this email directly or view it on GitHub:
#51 (comment)
from hoodie.
Would love to see and understand your preference
+1
from hoodie.
OK, I'll take a stab at it :-)
from hoodie.
@mroderick why do you think you'd like to look into it? I wouldn't like to delay the CoffeeScript → JavaScript rewrite for too long
from hoodie.
Do you mean 'when'?
I've been working on it today.
On 29/06/2013, at 19.32, Gregor Martynus [email protected] wrote:
@mroderick why do you think you'd like to look into it? I wouldn't like to delay the CoffeeScript → JavaScript rewrite for too long
—
Reply to this email directly or view it on GitHub.
from hoodie.
oops, yes, I meant when
, sorry!
We just merged the v0.2 branch into master, it would be best to build on top of it. I'm curious to see what you come up with
from hoodie.
We just merged the v0.2 branch into master
Ehm, ok. Are we rushing to get something out the door, or what's going on?
from hoodie.
The current state of the JS version was already better than the CS version. And I wanted to work on some of the open issues and didn't want to do it based on the CS version. No rush, just pragmatism
—
Gregor Martynus
On Sat, Jun 29, 2013 at 10:34 PM, Morgan Roderick
[email protected] wrote:
We just merged the v0.2 branch into master
Ehm, ok. Are we rushing to get something out the door, or what's going on?
Reply to this email directly or view it on GitHub:
#51 (comment)
from hoodie.
Well, that was what I was disagreeing with and why I am dedicating my Saturday to writing this. But, the test setup in the 0.2 branch is far from easy to work with, so I don't really see it as being very pragmatic to force it upon everyone.
from hoodie.
don't worry about it, if you come up with a better suggestion, we'll apply it together. I'm looking forward to see what you'll come up with
from hoodie.
Am putting it into a folder structure as we speak :-)
Should be visible tomorrow
from hoodie.
I've focused on the Events
constructor, as that is the base of everything else.
I've put my codified thoughts into it's own respository: https://github.com/mroderick/hoodie-51
from hoodie.
@mroderick I personally don't see why this couldn't have been added to the current code, testing is fairly accessable and not far off from what you've put together with buster.js.
However, https://github.com/mroderick/hoodie-51
is a good demonstration of your approach. 👍
Would you mind pointing us to the improvements in your code over the event system that's currently in place?
from hoodie.
@mroderick I personally don't see why this couldn't have been added to the current code, testing is fairly accessable and not far off from what you've put together with buster.js.
It might be fairly accessible for you. I wasn't having much luck with it. When there were failures/errors, it spewed so many lines into the console, that not all of them were captured.
Would you mind pointing us to the improvements in your code over the event system that's currently in place?
I tried to keep as close to the original as possible, as the point of this whole exercise (issue 51) was to port hoodie.js to JavaScript and not re-implement it with an entirely new architecture.
(I also came across MicroEvent during my investigations this weekend)
In my rewrite, I've optimised for
- making the code easier to read
- use of builtin language features over self implemented featuers
I think that the code shows more of the intention, and is easier to read. A nice side effect is less code.
(Oh, and one
actually works in my rewrite)
Ensure well defined value, instead of constantly worrying about undefined or null
By moving the resposibility of defining the property object that holds all the subscriptions to the constructor (https://github.com/mroderick/hoodie-51/blob/master/src/events.js#L17-L25), we don't have to do stuff like:
// https://github.com/hoodiehq/hoodie.js/blob/master/src/events.js#L17
calls = this.hasOwnProperty('_callbacks') && this._callbacks || (this._callbacks = {});
// https://github.com/hoodiehq/hoodie.js/blob/master/src/events.js#L53-L57
list = this.hasOwnProperty('_callbacks') && ((_ref = this._callbacks) !== null ? _ref[ev] : null);
if (!list) {
return;
}
// https://github.com/hoodiehq/hoodie.js/blob/master/src/events.js#L84-L88
list = (_ref = this._callbacks) !== null ? _ref[ev] : null;
if (!list) {
return this;
}
Prefer builtin methods
By relying on builtin methods, the code becomes clearer (all of them have documentation and specs) and allows for better optimisation of execution (JavaScript engines have a much easier time optimising code in their space as opposed to user space).
Array.map
Array.forEach
Array.indexOf
Object.create
(as inheritance method, instead of utils/deepExtend)
Size
Stats porn!
Original | hoodie-51 | |
---|---|---|
Lines (ohcount) |
63 | 53 |
Minified (uglify) |
1332 | 1199 |
Min + gzip | 537 | 490 |
from hoodie.
I agree that your code is better to read, and that pretty much all files, especially the tests need some time to cleanup after the remained CoffeeScript → JavaScript. I'd also tend to use ES5 features and let people use shims if they need to support older browsers. Code readability is a high priority for us so your contribution to help on that is much appreciated! Just send pull requests, maybe open up issues beforehand so we don't conflict with our work, that'd be great. Cheers!
from hoodie.
ES5 Arrays tend to be slower using the Array.prototype.forEach
methods. They MAY be optimized later, but for
loops are just as optimizable and are clear even to beginner programmers.
Unless the function is already predefined and used somewhere else, AND smaller code size is important...
It's only my two cents. My guess is this: if they are reading the library and want to learn more, they know what a simple for loop does.
for(var i = 0, _len = arry.length; i < _len; i++){
callFunc(arry[i]);
}
Don't get me wrong, I still like the idea of using the Array.prototype,forEach method when performance doesn't matter too much.
from hoodie.
Don't get me wrong, I still like the idea of using the Array.prototype,forEach method when performance doesn't matter too much.
This would be one of those cases
from hoodie.
Noted! It still works very quickly.
from hoodie.
Related Issues (20)
- share data between users and groups HOT 1
- Hapi deprecation warnings
- npm start command fails HOT 3
- Unable to store data on CouchDB v2.2.0 HOT 3
- `options.account` and `options.store` not passed to hoodie-server
- Some question about hoodie HOT 1
- Compatible pouchdb-Browser versions HOT 10
- Keep items in local IndexedDb after signOut HOT 3
- store.findAll() return deleted items if pouchdb-browser is initialized with a low “revs_limit” and “auto_compaction: true”
- any plan for php port of the backend ? HOT 4
- Project status? HOT 8
- Good code HOT 1
- can't register hoodie plugin in hapi: Invalid register options "value" must be of type object HOT 2
- Website is down HOT 5
- Site down
- Image elements do not have [alt] attributes HOT 6
- improve UI HOT 3
- Hoodie Chat Link is broken on CONTRIBUTING.MD HOT 2
- Project Status / Maintenance HOT 6
- [Bug]: Different cursor on different buttons on landing page HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hoodie.