Echo JS 0.11.0

<~>

tracker1 comments

tracker1 3631 days ago. link 1 point
The modal itself presents a single issue I see a lot in modals... in that if the vertical space on the screen doesn't show correctly, the modal won't scroll, also, the page in the background does scroll[1].

I generally put in the effort to work around this.

[1] https://github.com/juanbrujo/tinyModal/issues/4
tracker1 3631 days ago. link 1 point
IIRC, flow doesn't/didn't work on windows, which is a non-starter for a lot of users... not sure where this stands now, last looked at it when using flow types to be able to use angular 2 without typescript, as I mentioned, I didn't see the point as I still needed bits from babel.
tracker1 3631 days ago. link 1 point
But flow adds type support (same as typescript), and can also be used with babel... flow only does one thing, so better integration.  Typescript doesn't offer much beyond types (and flow does that) over babel.. and as you say, you're using babel anyway.
tracker1 3631 days ago. link 1 point
Because at runtime, typescript doesn't provide type checking... ie: when interacting with a foreign API... Beyond this, with small, well-organized modules, TypeScript tends to only add boilerplate, and doesn't tend to prevent as many errors as the time to write boilerplate prevents.

I can see why some would like it, I just don't find much value in it.
tracker1 3632 days ago. link 2 points
I'm going to agree with several of the comments that async/await sugar around generators would have been more welcome than non-nullable types.

Then again, I kind of find TypeScript itself of questionable value over es2016 + stage1 via babel.
tracker1 3632 days ago. link 1 point
Will have to look into this, may be interesting to add additional rules/transforms.
tracker1 3632 days ago. link 1 point
I'm not sure why jQuery isn't using the built in Promise with v3, and/or requiring or even including a shim, only if it isn't available/set.  I know that bluebird will show an error if there's an uncaught rejection in their implementation, pretty sure browsers are heading in that direction.
tracker1 3633 days ago. link 1 point
Pretty good comparison, although this is a really limited use case and will favor some frameworks over others.  Also many apps won't be making this many DOM changes in this short of a time.

I'm particularly interested in the production payload size for inferno vs preact.  I've used preact for a few small thing because the payload size is so small by comparison.  The inferno memory footprint looks similar, so for a similar payload size, it might be worth switching them out.
tracker1 3636 days ago. link 1 point
I know monotype is probably making their comment in jest... just the same, specifically ng2 vs react, I think that ng2 has a *lot* in the box, however I find that once you get past how to initially use react (specifically jsx, and a state management library like redux), there are very few gotchas, and some room to tweak.  With angular 2, at least from my limited experience, there were a *lot* of wtf moments, and places where you can easily shoot yourself in the foot.

I admit, I'm biased, but there is support for that bias.  Not to mention, I tend to solve most problems with a more functional mindset.
[more]