Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

301–306 of 306 posts

Re: State of the Art JavaScript in 2016

#301

I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number". Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your…

> TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that…

ADTs can be very easily replaced with visitors.

  type Maybe = (v:{just(x:T):V, nothing():V}) => V
  
  let just = (x:T):Maybe => (v:{just(x:T):V}) => v.just(x)
  let nothing = ():Maybe => (v:{nothing():V}) => v.nothing()
  
  let values:Maybe[] = [just(6), nothing()]
  
  values.forEach(maybe => {
    alert(maybe({
      just: x => 'got: ' + x,
      nothing: () => 'nothing'
    }))
  })

Re: State of the Art JavaScript in 2016

#302

Ember.js is already proved, the best framework out there nowadays. Corporate ready, production ready, future proof. I'm really looking forward, that Type Script support will be landing soon in the framework, so it will be a concrete solid environment. The whole addon ecosystem, with Ember Data and Ember CLI is just top-notch. You can check here with this tutorial, how easy to write a complex application with Ember.js…

From my experience, the most important aspect of a single page app framework is the component api. Here's the doc for ember's: http://emberjs.com/api/classes/Ember.Component.html Versus react's: https://facebook.github.io/react/docs/multiple-components.ht... Versus angular's: https://docs.angularjs.org/guide/component If you compare them, you can see that react and angular focus heavily on component oriented architec…

Ember implemented React and Redux concept a year ago, the component layer is based on Virtual DOM. You can see here all the hooks what you can find in React, maybe with a little bit different function names... a modern Ember app is full of components. ;) http://emberjs.com/api/classes/Ember.Component.html (Tick the check-boxes, Ember.js is nicely object oriented, so you can get a lot from parent classes.)

Re: State of the Art JavaScript in 2016

#303
>> "You’ll be able to package your application and distribute it like any other desktop application, complete with an installer and auto-updates."

Yep, Electron is excellent. However, Electron is built on top of V8 and V8 does not provide a way to protect the JS source. More than the technical problem this becomes legal issue for businesses that want to develop applications/tools rapidly with electron.

refer: https://github.com/atom/electron/issues/2570

Cons of other options that I know: 1. Obfuscation is not ideal to hide the source from competitors.

2. Writing nodejs modules in C++ is not so easy way. Once could prefer to develop entire app with C++ than the learning curve associated with node modules in C++.

3. V8 snapshots maybe a way to go with nw.js. But doesn't work great and it is hard to isolate issues while packaging.

4. EncloseJS looks promising. There is no company behind it and no guarantee it will be supported. (I personally have been following up with issues in packaging an open source app with encloseJS. No luck so far with support.

5. nexe is interesting. But not easy and no clear way to work with it.

What are your opinions? Any alternatives?

P.S: I'm framing a base with Java (most likely C++ too) to develop an app that runs on client machine but on browsers. Performance and source protection are my goals. Might open source its architecture eventually.

Re: State of the Art JavaScript in 2016

#304

Earlier quoted context omitted.

Well, I guess I can count myself amongst the "haters". Specifically, I noticed your > 4. I hate dynamic typing ... but I absolutely disagree with the phrasing. Your underlying assumption seems to be that "dynamic typing" is a Good Thing, by definition. I want to challenge that. Thing is... I don't hate dynamic typing[1] as long as everyone is being "consenting adults" about it (GvR)... I just LOVE static type checkin…

Yes. But my point is that not every discussion needs to be dominated by the well-known split between two factions who both have strong feelings about type systems. You have every right to evangelise - but try and try and avoid making top level comments on the matter unless it's on a post that specifically is discussing static vs dynamic typing. The subject gets enough airtime and it's good for other topics to get a l…

Ah, true. I think I may have missed your point entirely, but I'm not sure the blame rests entirely with me, FWIW. I think being more explicit about your point up-front ("the tease") and then elaborating ("the payoff") might have served your purposes better.

I must say, I'm also not a fan of the almost-always-fake "balance" thing we see so much in journalism and television, FWIW.

(Just as a trivial example there can be no "balance" between a Homeopath who claims to cure toothaches and a dentist. One is supported by massive amounts of a-priori plausible evidence and the other... isn't. Sorry about that mini-rant :).)

Re: State of the Art JavaScript in 2016

#305

Earlier quoted context omitted.

> TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that…

ADTs can be very easily replaced with visitors. type Maybe = (v:{just(x:T):V, nothing():V}) => V let just = (x:T):Maybe => (v:{just(x:T):V}) => v.just(x) let nothing = ():Maybe => (v:{nothing():V}) => v.nothing() let values:Maybe [] = [just(6), nothing()] values.forEach(maybe => { alert(maybe({ just: x => 'got: ' + x, nothing: () => 'nothing' })) })

Easy, but absolutely horrid on a large scale. (I mean, just try to enumerate the amount of redundancy you have in that short snippet you posted!)

Re: State of the Art JavaScript in 2016

#306

At work we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything. It's been a huge boon. PS Ramda it eats lo-dash and its imperative API for lunch. It's for power users, everything curried, higher levels of abstractions. Pick it up and learn it, it'll make you a better programmer. Next stop Clojurescript. Om next is a library where you can get a feel for a Falcor…

Lodash v4 has its FP module included with it: require('lodash/fp') for immutable, auto-curried, iteratee-first, data-last method modules.
Post reply on HN