Add eslint and maybe flow? about hyperapp HOT 14 CLOSED

Thanks for the suggestion @itrelease think this is great! I'm busy re-writing this using es6 but think it might suit typescript a lot more, (personally flow is abit, ify).

from hyperapp.

@maraisr I'm sorry, but I'm not going to make HyperApp three times larger just so that we can use ES6 in the source code.

EDIT: In retrospect, the comment above was pretty ignorant.

from hyperapp.

@maraisr Interesting. Let's continue the webpack discussion #29.

By the way, in real production environments, users will use https://www.npmjs.com/package/yo-yoify to transform html templates into raw h calls or babel to transform JSX into raw h calls.

So, we still need to provide each module html/app/h (and possibly toString in the future) separately.

from hyperapp.

Hi,

Going back to the eslint issue I would go with standard because it's really easy to setup, has no configuration and, above all, your code is almost standard, so the changes are minimal. If you agree, I'll make a PR

from hyperapp.

For eslint (so that unix/windows/linux devs) can avoid errors because of their OS (if using the airbnb style guide):

    "rules": {
        "linebreak-style": "off",
    }

from hyperapp.

I'd be willing to give flow a try, since we use it at work too, but I don't know if it'd be really worth it for a project this size.

As for eslint, I think it'd be futile, since HyperApp is mostly written in ES3 with some ES5 bits here and there. Also, I don't fancy the idea of upkeeping an .eslint file.

I'd be willing to give https://github.com/feross/standard a try though!

from hyperapp.

@maraisr Why are you rewriting HyperApp in ES6?

from hyperapp.

@jbucaran purely for developer experience. Webpack, Vue, React all the majors all wrote their source files in es2015 and there is a great reason for it too.

The people using the CDN through raw git, use the es3/5 compatible builds through that webpack offer. My es2015 build has babel.

In terms of the standard, yeah anything is fine. Feel like with you @jbucaran being the product owner you should be setting the code standard you're comfortable with. SO if you want that standard imposed, yeah sure.

from hyperapp.

@maraisr Don't get me wrong. I don't fancy ES3 neither. Many of the HyperApp examples posted in the README use a quite aggressive and modern JavaScript.

How much does the new bundle differ in size with the current bundle?

from hyperapp.

@jbucaran really good build is 3.4kb gziped, and like 8 ungzipped. With webpack, we get tree shaking so I'd imagine the this is quite a lot smaller than the browserfy individual module build we had going before.

from hyperapp.

Its not 3x the size, remember this contains all the code for app, h and html including its dependencies. And just not that this bundle right now isn't es6. Will be significantly smaller smaller once es6 kicks in.

from hyperapp.

Current:

which is 3988 bytes + 1089 bytes + 6493 bytes, so 11570 bytes, which is 11.5Kb.. Webpack wins.

from hyperapp.

@danigb Yeah, maybe.

I'm trying to migrate to rollup (that's if we manage to make it create smaller bundles). You can go ahead and send a PR and we'll get to it eventually.

Thanks!

from hyperapp.

Nothing actionable we can do here. Don't really think HyperApp needs either one.

That's not to say I don't recommend using them in your application. That'd be most fine. But HyperApp is tiny and okay without it.

from hyperapp.