Echo JS 0.11.0

<~>

amitport comments

amitport 96 days ago. link 2 points
"Add support for ESM. This is currently behind the --experimental-modules flag and requires the .mjs extension. node --experimental-modules index.mjs" 👍
amitport 215 days ago. link 1 point
clicking 'getting started' just says to come back in a few months— whatever it is, it hasn't arrived...
amitport 218 days ago. link 1 point
There are ISec companies that maintain this kind of lists as part of their main business. They test against penetration tools and review against all CVEs. I worked in such a company, but unfortunately, I don't remember specific patterns and couldn't disclose any if I did.

I know I'm not being extremely useful. In any case, I think it is important to clearly state that companies with critical security requirements should probably not rely solely on this.
amitport 218 days ago. link 1 point
Nice, but the rules are somewhat minimal IMHO. It will be nice to mention that in the readme.
amitport 273 days ago. link 3 points
You are just linking to a commercial site. No added value. You will avoid the down votes when you'll write an interesting technical report, publish an open source project, or be the first to report something new in the field (e.g., es2019 features).
amitport 356 days ago. link -1 point
As someone who is regularly introducing javascript to other programmers. I got the say that since ES6, prototypes are no longer a core concept that is practically needed to get you started and this does wonders to the learning curve. Really people just get into the language and code base *a lot* faster, and no, they don't encounter side-effects for not knowing prototypes. That's because our code is mostly sane and prototypes are used scarcely (which should be the case for most projects).

Don't get me wrong, it will be a good thing that programmers *eventually* understand prototypes, but it really shouldn't be a core concept blocking use of the simple inheritance paradigm.
amitport 727 days ago. link 2 points
The thing is jspm, browserify and webpack are not exactly comparable. They do some different things and do them differently. 

What I was trying to say is basically this:
If you ask a general question people will answer based on their perspective, which isn't necessarily aligned with your requirements and thus not really helping your decision making.

You should focus on your specific requirements and work from there.

For me, gulp takes care of pre-build/deployment issues, so I don't need those features from webpack. On the other end, jspm, beside including a module loader (systemJs) is also a 'package manager' that is comparable to bower but more generic. I find this to be very useful when you start mixing packages from different sources that use different module systems.
[more]