Twitter | Search | |
Henrik Joreteg
Things that should not end up in production clientside code: 1. Bluebird 2. Moment 3. Lodash 4. PropTypes 5. Polyfills for things that 90%+ of your users already have in their browser's. 6. history.js 7. babel-polyfill 8. node shims for browser stuff (url, etc)
Reply Retweet Like More
Henrik Joreteg Aug 23
Replying to @HenrikJoreteg
I swear if everyone used a selective polyfill approach like the entire web would shed 20% of its JS weight.
Reply Retweet Like
Henrik Joreteg Aug 23
Replying to @HenrikJoreteg
9. intl.js 10. es6-promise 11. whatwg-fetch 12. React-router (/me ducks)
Reply Retweet Like
Henrik Joreteg Aug 23
Replying to @HenrikJoreteg
I'm not trying to hate on these libraries. My point is that everything you include had better be justified. For example spending 20kb min+gzip to include all of lodash just for .get() and .filter() makes zero sense in most cases. At least do atomic imports.
Reply Retweet Like
zoozoo Aug 23
Replying to @HenrikJoreteg
oooh. any alternative to react router though? just history.pushState?
Reply Retweet Like
Henrik Joreteg Aug 23
Replying to @aulisius_
Reply Retweet Like
Mark Brown ☕ Aug 23
Replying to @HenrikJoreteg
You lost me at Moment. Is there a lighter alternative that you prefer? Date is crumby
Reply Retweet Like
Jens Alm Aug 23
Replying to @HenrikJoreteg
Just to be devil’s advocate – it depends. We ship a desktop web app for schools working on 100 Mbit broadband. They work for 30-120 minutes per login, JS size is a non-issue for us. We have tons of DB optimizations to do first.
Reply Retweet Like
Henrik Joreteg Aug 23
Replying to @markbrown4
Look at: And frankly, for what most people do native Date() is just fine. toLocaleString with options can get you a long way.
Reply Retweet Like
Tobias Viehweger Aug 23
Replying to @HenrikJoreteg
I'd say it depends. If you are only formatting dates, I guess you could skip moment. But if you are doing extensive date & timezone handing in JS, I'm not sure you'd really want to do that by hand..
Reply Retweet Like
Henrik Joreteg Aug 23
Replying to @doculmus
Ok, but that's not the norm. Each case is unique, know your users.
Reply Retweet Like
Anders Olsen Sandvik Aug 23
Im also curious about moment. How do we suggest we do duration calculation. Im not familiar with any native apis for this
Reply Retweet Like
Henrik Joreteg Aug 24
Replying to @Andersos @markbrown4
If you really feel like you need a lib, look at . But a little util and a basic understanding of native Date can go a long way.
Reply Retweet Like
Nicholas Griffin Aug 24
Replying to @HenrikJoreteg
I disagree with moment, a must have if you're doing anything complicated with dates or just want to ensure that's it's valid, I've had big problems with date in the past. That said, you should only load moment where you need it, which isn't every page.
Reply Retweet Like
Henrik Joreteg Aug 24
Replying to @NGRIFFINtn
Reply Retweet Like
Nicholas Griffin Aug 24
Replying to @HenrikJoreteg
That is nice, the issue would be switching what you already have on moment over and making sure that other devs know that. It's pretty ingrained in the code that I work on, across environments and for a few KBs, not sure I need to do it.
Reply Retweet Like
Henrik Joreteg Aug 24
Replying to @NGRIFFINtn
Many people will 'npm install moment' Not realizing they just added 60kb+
Reply Retweet Like
Bigo Aug 24
Little did one know only moment does timezone correctly and acceptably atm
Reply Retweet Like
Ivan Čurić Aug 24
Replying to @HenrikJoreteg
How do you handle shipping async/await code? I usually end up making 2 bundles — a legacy one with babel-polyfill and regenerator-runtime and a modern one.
Reply Retweet Like
Henrik Joreteg Aug 24
Replying to @_baxuz
Right now, I'm just not.
Reply Retweet Like