Hacker News new | comments | show | ask | jobs | submit | nilliams's comments login

Sure but that's not a common use-case and won't affect people who want to use Atom as a day-to-day code editor.

But it is a use-case. I always have to keep Sublime Text around for the times I need it.

I wish Atom would prevent me from opening such files, as an option. I sometimes accidentally open large minified files and have to wait.

I don't think that the belief that feature X was created at the expense of feature Y is a reasonable assumption. Who knows how this feature came about? It could have been a Githubber's 20% project, or weekend hack project, or largely down to a 3rd party library.

I didn't assume it was, I hoped it wasn't.

Well for one 'class Foo extends Bar' will work without any further code to make inheritance work in the way you'd expect, including use of super() etc. Whereas your second example is using non-trivial framework code, that some framework author has to write. See Backbone's extend() for a clear example of what is required [0]. That's work that every framework author is potentially going to implement differently, needlessly.

And the fact that almost every major framework has implemented something similar themselves is proof enough (for me at least) that the ES6 sugar is valuable. It has nothing to do with Java, it's simply a useful pattern that everybody was already using.

[0] http://backbonejs.org/docs/backbone.html#section-247


A note that using extends Component will cost you the function auto-binding that [p]react.createClass provides. In my specific case, using extends produced code that read more poorly.

But it's sad that not more framework authors tried StampIt or similar instead of reimplementing inheritance (more or less badly)

https://github.com/stampit-org/stampit


The question is whether that ~15 lines of code, written once, is worth the substantial increase in the surface area of the language, especially when overlapping so much with the existing prototypal inheritance mechanism. The choice to use Java/C++-style inheritance is a design pattern that doesn't necessarily reflect the only (or even the best) way to accomplish things.

ES6 classes do not use Java/C++ style inheritance, they are still the same as writing:

  function Foo() {

  }

  Foo.prototype = Object.create(Parent.prototype);

  ....
It's just sugar, nothing more.

The semantics of JS classes are still different in enough subtle ways: constructors and constructor subclassing, (lack of) object properties, hoisting, etc. That is on top of the new keywords, new function syntax, etc. All that needs to be mapped onto the model of "classical" Javascript in order to completely understand the language. There are enough gotchas there to disqualify JS classes from being simply sugar.

You can add object properties to a ES6 class's prototype, no?

EDIT: Just tested in Firefox and indeed you can.


Not in the class declaration, though. Why force the programmer to go through the prototype, when ES6 provides such a "convenient" abstraction around it?

Coming to the spec soonish and already supported in Babel - https://github.com/jeffmo/es-class-fields-and-static-propert...

Being a C++ developer during the day and a web dev at night, this syntactic sugar is actually a breath of fresh air.

I'm not yet convinced that it's just syntactic sugar. For example, what (generic) code is `super` syntactic sugar for?

Even if it is just syntactic sugar, that syntactic sugar makes it much more approachable for devs who want to use classical inheritance (not that I'd encourage that).


> what (generic) code is `super` syntactic sugar for?

  super.propertyOnSuper ~= this.__proto__.propertyOnSuper

  super() in constructor ~= ParentConstructor.call(this)
and some tools provide such things like this.super_:

https://github.com/isaacs/inherits/blob/3af5a10c6b51f9e99d9f...


Thanks for the response. If the choice is between manually specifying that (type of) code for every kind of object (and likely moving to a #create factory method) or using a native syntax for class declaration, I can see why people would choose the latter.

It's to a degree for people who are not primarily JS developers and often have no clue about prototypical inheritance. It also to a good degree reflects how V8 or some other engine actually treating your code under the hood.

The language surface area has already increased. The decision has been made.

You have 2 possibilities yes, but afaict Angular 2 doesn't push you to use 'its way', unlike the early days of Angular 1 where 'the way' to do state was $scope.

So I could see how you could comfortably use Angular 2 with Redux as long as your team was on-board to always do state the Redux way.

-----


Give a developer an inch and they'll take the football field. Maybe that's an acceptable risk, but I wouldn't take that risk.

-----


To be fair, not everyone is suggesting you need a scripted build system, but you do need some sort of build step, because <script> tags just aren't sufficient for anything beyond a trivial app. (Also ultimately, you do need to minify your code for production).

This build step can just be 'browserify main.js -o bundle.js'. This is where I suggest people start or go back to if they are intimidated by all the various options.

-----


'class' wasn't added to make it look like Java. It was added as sugar for a common pattern that everyone was already using. Many languages other than Java have a class keyword.

-----


> Many languages other than Java have a class keyword.

Yes many classical oop languages have the class keyword and that's why javascript added it.

-----


Because it's a useful pattern, that people were using heavily. Not sure why you're trying to suggest some kind of ill-intent.

A nice thing about prototypal inhericance is that classical inheritance can be implemented in it. People were doing that commonly enough that it made sense to add sugar to do it more directly, and signal intent more clearly to the reader.

-----


It's mainly useful for 3rd party (or 'minified') HTML, just to make it readable. It's rare you'd want to use it on HTML you've written yourself.

-----


Yeah it's really bad. I feel for anyone that has stuck with these old-school 'cross-platform toolkits' over the last few years, they have really been missing out for a while now. On top of this, the whole scene is just stagnant and decades out-of-date from my experience (trying to get into Qt a couple of years ago). There are no devs there, you're basically on your own.

If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron [0] and NW.js [1]. Then you can tap into the web ecosystem with its (enormous, company-backed) massively vibrant frameworks, libraries, tools and communities.

It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore (opinion - willing to be proved wrong).

[0] http://electron.atom.io/ [1] http://nwjs.io/

-----


I think you are wrong on pretty much everything you've stated here.

> There are no devs there, you're basically on your own There is an extremely active mailing list and IRC channel (several official ones actually) where you can almost always get in touch with the actual Qt devs and others who use it for support without paying them anything. There are over 500 people in the IRC room right now.

> If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron [0] and NW.js [1].

Maybe when Web Assembly (or whatever its called) becomes a thing performance will be tolerable but I have yet to come across a web application that doesn't run incredibly slowly. I use Atom for a basic code viewer right now and it is pathetically slow compared to any native applications (GEdit, Kate, Geany, etc)... and this is on a desktop machine. I can't imagine anyone creating a remotely complex web application on mobile and expecting any sort of reasonable performance. Text editors should be some of the faster applications -- imagine creating something that's media rich like a music player, a video or photo editor; it would be a disaster.

Also regarding your "with opportunities for mobile too" comment, you know Qt is supported on iOS, Android, WinPho, BlackBerry, Sailfish right?

> massively vibrant frameworks, libraries, tools and communities Yeah, its not like the native software community doesn't have that or anything. Unlike web tools, native tools have been developed for far longer and they are more robust and reliable.

>It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore Yes, if you don't care about performance and all the things web frameworks miss out on (how's that GL support looking? Native is getting ready to support Vulkan -- WebGL is still stuck on the ES2 equivalent) then jump on board the web app hype train.

You're also completely overlooking embedded where Qt specifically is used extensively. Kiosks, IVIs, small displays for smart appliances, etc.

I don't like the Qt model of using the GPL as a way to get people to go for their very expensive commercial offering and I think a model like Unreal Engine's (give us a share of your revenue) makes more sense as an additional option for smaller devs.

-----


I don't agree with your characterisation. GP was complaining about downvotes to anti-MS comments, and that's nothing to do with 'attracting a readership'. More like the specific criticism of Microsoft demonstrated in this thread so far is the same tired old crap and not relevant to the actual topic.

-----


...that, or "PR bots" at work.

I guess I'll see by the downvotes this comment receives. ;)

-----


> A lot less hassle then dealing with this over engineered client side bullshit.

I like to deal with client-side apps which talk to a simple JSON API. It's a lot less hassle than dealing with this over engineered server side bullshit.

-----


JSF with Java EE. That was over engineered.

This Redux flux capicator, isomorphic, 4 Terabyte NPM install, 45 Babel plugin, flow, dumb component pure functional, immutable js, virtual dom. Now that's over engineered.

I built more complicated stuff with Knockout.js in 2011 then half the stuff I see people building with React(which from what I see is just news sites and forum software)

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: