<div dir="ltr">> <span style="font-size:12.8px"> javascript-fatigue is partly the realization from naive newcomers that you almost always end up with spaghetti-code after integration, no matter how hard you fight it</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">And don't you think the lack of OST is in part fueling this situation?</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 7:44 AM, kai zhu <span dir="ltr"><<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>more ranting.</div><div>tldr - javascript-programmers are more productive spending their limited-time documenting and writing validation-code for endpoint-level rest-apis instead of for code-level business-logic (swagger/openapi is more useful than OST/flow/typescript).</div><div><br></div><div>i'm generally a javascript-architecture skeptic.  from my experience in industry, there is zero-correlation between careful architecting (*cough* bikeshedding) and successfully getting over the javascript-integration hump to ship a product.  the “best" architecture/design for any given web-project is whatever ad-hoc hacks/rewrites/fire-fighting it takes to get you past the integration-stage (and javascript-fatigue is partly the realization from naive newcomers that you almost always end up with spaghetti-code after integration, no matter how hard you fight it).  it might be different at microsoft/facebook/google, but their abnormal tooling environments (and resulting skewed world-view of javascript) are hardly representative of the industry as a whole.</div><div><br></div><div>what does correlate with successfully shipping a product, is having well-documented endpoint rest-apis, so the frontend-folks aren’t completely clueless during integration when they try talking to the backend, and it doesn’t respond or timeout for some reason.  a web-project has a higher chance of shipping successfully if you spend your limited engineering-time doing integration-level documentation and validation-checking (using swagger as shown in following screenshots) instead of code-level OST which nobody talking to your server during integration cares about:</div><div><br></div><div>(these screenshots are from real-world endpoint rest-apis that have been documented with integration-level type-checking using swagger - <a href="https://kaizhu256.github.io/node-swgg-google-maps/build..beta..travis-ci.org/app/" target="_blank">https://kaizhu256.github.io/<wbr>node-swgg-google-maps/build..<wbr>beta..travis-ci.org/app/</a>)</div><div><br></div><div><img id="m_5750721939234744701D8907E8F-0A15-4EF7-B601-9BB4727DFDEE" width="715" height="339" src="cid:3A8FDF4F-7618-476E-9700-ECF1D79DB4C9"></div><div><br></div><div><img id="m_575072193923474470121FA6592-27BF-4BCF-A003-451714B96CA3" width="501" height="184" src="cid:3932E4A5-EB20-4DD6-AD12-E59E7DB4973D"></div><div><br></div><div><img id="m_5750721939234744701CE3E4B84-3F29-47F9-9AA0-25A8E158D507" width="498" height="151" src="cid:EF2E1434-B919-44CC-BE08-782F76F0E48E"></div><div><br></div><div><img id="m_5750721939234744701CFDE8CC5-2936-4B5C-83D8-061C98162A44" width="505" height="119" src="cid:95F40D19-DFBD-4CE3-9F93-4D98E95BEC95"></div><div><br></div><div><img id="m_5750721939234744701B147BD76-E0D9-4EBA-B407-FDB5D991BAE7" width="502" height="144" src="cid:E7A11E1B-4347-43EB-A010-31F4C83C57CF"></div><div><br></div><div><img id="m_575072193923474470194BBA50C-E993-4962-AC43-EB45CE0E3016" width="712" height="713" src="cid:DDDE99AC-F90E-4066-9BD8-C2BC85DEA5CA"></div><div><br></div><div><img id="m_57507219392347447014A578E6E-7758-4CC4-BF82-FDFED509B15C" width="706" height="339" src="cid:087F45E9-FA3F-4C42-B00D-569DCFCCD142"></div><div><br></div><div><img id="m_5750721939234744701B4F147FC-1645-4277-8715-4393C57FAEE7" width="709" height="719" src="cid:2C37C2CD-CF0F-4139-B4C4-9059599CBE74"></div><div><br></div><div><blockquote type="cite"><span class=""><div>On Jan 11, 2018, at 10:01 PM, Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> wrote:</div><br class="m_5750721939234744701Apple-interchange-newline"></span><div><div dir="ltr"><div><span class=""><div>From a quick read, I'm more in favor of something that's a little more restricted to start, something like what Python has. Python has optional static type annotations, but the Python interpreter just ignores them. They are present purely for the purposes of tooling, and are silently ignored at runtime.<br><br></div></span>Conversely, PHP took a similar approach and initially also made it cosmetic to start, only later taking advantage of *some* type annotations by adding runtime behavior to some of the simpler ones (like primitives).<br><br></div><span class=""><div>One of the reasons why I'd prefer a simpler approach to start is that TypeScript and Flow, the two main implementations that add syntax, have a *very* similar syntax, but have several nuances that would make a heavier proposal much harder to accomplish:<br><br></div><div>- Flow has `?Foo` for optional types, TypeScript just uses unions.<br></div></span><span class=""><div>- TypeScript has mapped/index types, where Flow uses special named types.<br></div></span><span class=""><div>- Flow allows omitted parameter names in function types, TypeScript only allows named parameters with implicit `any` types.<br></div></span><span class=""><div>- Flow has exact types, TypeScript doesn't.<br></div></span><span class=""><div>- Flow has `opaque type`, TypeScript only has `type`.<br></div></span><span class=""><div>- Flow constrains with `T: Super`, TypeScript uses `T extends Super`.<br></div></span><div>- Flow has 3 different ways of importing bindings a module (depending on what's being imported), TypeScript only has one.<br></div><span class=""><div>- Flow has existential types, TypeScript doesn't.<br></div><div><br></div></span><div>Also, both TypeScript and Flow are still working out how to properly type some of the more advanced JS (like variadic functions and auto-curried functions), so their syntax is *still* not exactly stable enough I'd feel comfortable encoding much into the spec. (They do have a stable core, though.)<br><br></div><div>One other thing is that multiple active proposals could end up requiring TS and/or Flow to substantially change parts of their syntax, including:<br><br></div><div>- Private [fields][1] and [methods][2] (stage 3 and 2 respectively, affects TS)<br></div><div>- [First class protocols][3] (stage 1, affects both TS and Flow)<br></div><div>- [Typed literals][4] (stage 1, affects TS mostly)<br><br>[1]: <a href="https://github.com/tc39/proposal-class-fields" target="_blank">https://github.com/tc39/<wbr>proposal-class-fields</a><br>[2]: <a href="http://github.com/tc39/proposal-static-class-features/" target="_blank">http://github.com/tc39/<wbr>proposal-static-class-<wbr>features/</a><br>[3]: <a href="https://github.com/michaelficarra/proposal-first-class-protocols" target="_blank">https://github.com/<wbr>michaelficarra/proposal-first-<wbr>class-protocols</a><br>[4]: <a href="https://github.com/mikewest/tc39-proposal-literals" target="_blank">https://github.com/mikewest/<wbr>tc39-proposal-literals</a><br></div></div><div class="gmail_extra"><span class=""><br clear="all"><div><div class="m_5750721939234744701gmail_signature" data-smartmail="gmail_signature">-----<br><br>Isiah Meadows<br><a href="mailto:me@isiahmeadows.com" target="_blank">me@isiahmeadows.com</a><br><br>Looking for web consulting? Or a new website?<br>Send me an email and we can get started.<br><a href="http://www.isiahmeadows.com/" target="_blank">www.isiahmeadows.com</a></div></div>
<br></span><div class="gmail_quote"><span class="">On Thu, Jan 11, 2018 at 3:09 AM, Pranay Prakash <span dir="ltr"><<a href="mailto:pranay.gp@gmail.com" target="_blank">pranay.gp@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">I'm still yet to read the entire proposal, but with a quick skim, it seems to me like this is essentially what Typescript or Flow offers you: i.e. an opt-in type system?<br><br></span><span class="">I'm wondering if you have any good reasons to want there to be a standardised static type annotation syntax within ECMAScript instead of a "Bring Your Own Type Checker" system.<br>If you do have some thoughts on this, you might also want to include that as a preface on your Github's README.You have a "Rationale" bit that seems to ignore the existence of these existing systems.<br><br></span>Waiting to hear more thoughts on this :)</div><div class="m_5750721939234744701HOEnZb"><div class="m_5750721939234744701h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, 11 Jan 2018 at 11:56 Brandon Andrews <<a href="mailto:warcraftthreeft@sbcglobal.net" target="_blank">warcraftthreeft@sbcglobal.net</a><wbr>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's been a year and a half since my last post and I've made a number of small changes and corrections over 2.5 years. The proposal is still on my github at:<br>
<br>
<br>
<a href="https://github.com/sirisian/ecmascript-types" rel="noreferrer" target="_blank">https://github.com/sirisian/ec<wbr>mascript-types</a><br>
<br>
I've talked to a lot of people about it, but I haven't gotten much criticism or suggested improvements. I'm a bit in over my head in trying to flesh out all the details or all the nuanced syntax changes that a championed proposal would be expected to do. That said I've been making more changes lately to try to find edge cases and potential problems.<br>
<br>
<br>
I've been jotting down issues here: <a href="https://github.com/sirisian/ecmascript-types/issues" rel="noreferrer" target="_blank">https://github.com/sirisian/ec<wbr>mascript-types/issues</a> I closed a number of them recently as I made changes.<br>
<br>
If anyone has any comments on what I should expand, look into more, or change I'm open to discussing them here or on github.<br>
<br>
One issue in particular is this: <a href="https://github.com/sirisian/ecmascript-types/issues/15" rel="noreferrer" target="_blank">https://github.com/sirisian/ec<wbr>mascript-types/issues/15</a> It covers whether I should introduce a new assignment operator to my proposal. Maybe there's another way to look at it or a different solution. I need fresh eyes on the whole proposal really to get a list of new issues to tackle this year.<br>
<br>
I'm also not against having one or multiple people champion it and working on it without me. (I haven't been able to dedicate time to read the ECMAScript spec and really understanding the grammar fully so having someone qualified to take over would help the proposal a lot).<br>
<br>
<br>
Thanks for reading the proposal for anyone that has the time.<span class=""><br>
______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br>
</span></blockquote></div>
</div></div><span class=""><br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br>
<br></span></blockquote></div><br></div><span class="">
______________________________<wbr>_________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br></span></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>