5 ms·

One major difference being that Vue.js doesn't really quite support TypeScript even with d.ts files provided. It will work only to a point until things fail to

One major difference being that Vue.js doesn't really quite support TypeScript even with d.ts files provided. It will work only to a point until things fail to typecheck due to generative aspects of Vue's API.[1] I think a useful comparison is taking a look at t7[2], trueadm's template library. Last I knew, it wasn't ready for use with Inferno yet, but that is a peek at the direction it is heading. It's rather similar to Vue's templates minus the v-directives magic in favor of leveraging JS for things like control flow. I'm not 100% sure I'm sold on it, myself, as I rather like beating out Vue templates in Jade rather than doing everything in JavaScript with template strings. That being said, I haven't directly tried to implement anything with Inferno or t7 yet to turn in an informed opinion on working with it. Inferno is one of the few other library than Vue I'd even bother looking at, however, at this point in time. They both aren't horribly bloated, are rather quick and have a mostly sane model to work with. Cito.js[3] is also interesting and works with t7, if you're looking for even less frills. It is also worth noting that if you care about licenses, Vue is MIT and Cito.js and Inferno are using a much more heavily restrictive license, MPL 2.0, which will matter if you're a commercial developer doing standalone apps. For this reason alone I have to throw Inferno and Cito.js into the trash at work. [1]: https://github.com/vuejs/vue/issues/478 https://github.com/vuejs/vue/issues/478 [2]: https://github.com/trueadm/t7 https://github.com/trueadm/t7 [3]: https://github.com/joelrich/citojs https://github.com/joelrich/citojs

ausjke 10y ago
Thanks and this is very insightful. Yes it looks like typescript will be an essential part of the js-ecosystem sooner than expected.
rpwverheij 10y ago
ah thank you for the summary of the licences. that moves inferno off the table for me too. sadly though, cause I was really getting interested with it being written in typescript.
- skrebbel 10y ago
  I dont understand. Afaict, MPL only requires you to publish the changes you make to MPL'ed libraries, not all source that uses it. Why does that stop you from using Inferno?
  - JSQuagmire 10y ago
    It is the difference between amending documentation (MIT) and producing infrastructure (MPL/LGPL) to ensure that whatever is currently in-tree and covered by the license is exactly what is available for download in the event anyone ever patches it... else you are out of compliance. It isn't just changes, either, it's the files in their entirety.[1] In a perfect world, no company would balk at having a GitHub account and having a public fork available, but many companies out there right now are still rather conservative about these things. Some barely use source control. MIT is simply one of the easiest licenses for these places to comply with. In my personal experience working at unglamorous places like these, they're fine returning patches as long as they never have to think about the legal implications or feel like there's a burden for using the code in the first place. The MPL is a poor choice for this sort of code because it makes the assumption that distribution is a given and will happen automatically, but if you're doing application development rather than web development that simply is not true that the code will always be a 'View Source' away. There are certainly applications where this license would be more appropriate, but I do not think an isomorphic vDOM library would be one of them, since this is rather foundational glue. It would be rather nice if trueadm would reconsider, if possible. [1]: https://www.mozilla.org/en-US/MPL/2.0/ https://www.mozilla.org/en-US/MPL/2.0/ [1a]: https://tldrlegal.com/license/mozilla-public-license-2.0-%28mpl-2%29 https://tldrlegal.com/license/mozilla-public-license-2.0-%28...
    - trueadm 10y ago
      Thanks for filling me in on the details of MIT vs MPL. I'll switch over to MIT now that I know this.
      - JSQuagmire 10y ago
        Fantastic, thank you so much for the hard work!

ausjke 10y ago

Thanks and this is very insightful. Yes it looks like typescript will be an essential part of the js-ecosystem sooner than expected.

rpwverheij 10y ago

ah thank you for the summary of the licences. that moves inferno off the table for me too. sadly though, cause I was really getting interested with it being written in typescript.

skrebbel 10y ago
I dont understand. Afaict, MPL only requires you to publish the changes you make to MPL'ed libraries, not all source that uses it. Why does that stop you from using Inferno?
- JSQuagmire 10y ago
  It is the difference between amending documentation (MIT) and producing infrastructure (MPL/LGPL) to ensure that whatever is currently in-tree and covered by the license is exactly what is available for download in the event anyone ever patches it... else you are out of compliance. It isn't just changes, either, it's the files in their entirety.[1] In a perfect world, no company would balk at having a GitHub account and having a public fork available, but many companies out there right now are still rather conservative about these things. Some barely use source control. MIT is simply one of the easiest licenses for these places to comply with. In my personal experience working at unglamorous places like these, they're fine returning patches as long as they never have to think about the legal implications or feel like there's a burden for using the code in the first place. The MPL is a poor choice for this sort of code because it makes the assumption that distribution is a given and will happen automatically, but if you're doing application development rather than web development that simply is not true that the code will always be a 'View Source' away. There are certainly applications where this license would be more appropriate, but I do not think an isomorphic vDOM library would be one of them, since this is rather foundational glue. It would be rather nice if trueadm would reconsider, if possible. [1]: https://www.mozilla.org/en-US/MPL/2.0/ https://www.mozilla.org/en-US/MPL/2.0/ [1a]: https://tldrlegal.com/license/mozilla-public-license-2.0-%28mpl-2%29 https://tldrlegal.com/license/mozilla-public-license-2.0-%28...
  - trueadm 10y ago
    Thanks for filling me in on the details of MIT vs MPL. I'll switch over to MIT now that I know this.
    - JSQuagmire 10y ago
      Fantastic, thank you so much for the hard work!