Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2017 JavaScript Rising Stars

risingstars.js.org

Post reply on HN
Print view View original

71–80 of 101 posts

Re: 2017 JavaScript Rising Stars

#71

Post by z3t4 »

nothrabannosir wrote: post #39
krapp wrote: post #37

Earlier quoted context omitted.

> Well then do you think no language that "compiles to machine code" really creates new language primitives, either? No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor. >The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead. Fair enough, but it doesn't actually cha…

> No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor. This is a psychological distinction, not a technical one. There is no fundamental difference between machine code, byte code, or a “real” programming language. There were machines that executed lisp, and at the dawn of time people programmed in assembly. Heck, people…

It's funny when languages like C where you have to baby-sit the memory handler "compiles" to JavaScript, where all memory handling is completely abstracted.

Re: 2017 JavaScript Rising Stars

#72

Post by uallo »

AJRF wrote: post #31

From the Vue.js information page on that site, 'The concept of single-file component that includes template, logic and styles in a single file .vue file is really nice.' NO IT IS NOT!

That is a very good argument you have here...

Aside from that, single file components are completely optional.

Re: 2017 JavaScript Rising Stars

#73

Post by jondubois »

whazor wrote: post #19
ernsheong wrote: post #18

Why is Polymer left out of frameworks top 10? It has 18k stars and should be No. 3... https://github.com/polymer/polymer https://risingstars.js.org/2017/en/#section-framework

As it is ranked based on new stars in 2017, not total amount of stars.

And it doesn't say much about usage. There are projects which get a lot of stars because people think that it looks cool at a glance but which nobody uses.

Re: 2017 JavaScript Rising Stars

#74

Post by chrisco255 »

mlsarecmg wrote: post #67
pablobaz wrote: post #62

Earlier quoted context omitted.

From your link, in the last year alone Vue has had approximately a 5-fold increase in the number of downloads. Describing this trend as "mostly flat with a slight upward bend." is very misleading.

See it in context. The fastest growing framework on npm right now for instance is Preact (as per official report posted by Lauri Voss last week), but Preacts userbase is so small that it could grow hundredfold with insane growth rates percentually without scratching a competitor. That also applies to Vue. React gets more users in a week than Vue in its entire lifespan. Go 2 years back on that page and you see a clear…

To be fair, Vue did embrace JSX in it's 2.0 release. I think Vue is leaps and bounds ahead of Angular in elegance and usability. I like Vue, I just don't think it has the ecosystem that React has. Maybe it will catch up eventually.

Re: 2017 JavaScript Rising Stars

#75

Post by BatFastard »

zachrose wrote: post #69
kevmo314 wrote: post #22

Earlier quoted context omitted.

Reading over the Elm documentation, I respect the ideals a lot, it looks like a fantastic language, but why does it need to be a completely new language instead of a framework in js? It's not particularly convincing to my co-workers if I have to convince them to try a completely new syntax instead of just a new framework. Actually, I think this is why something like cycle.js is more tractable.

It’s as much about what Elm _doesn’t_ have. The biggest thing here is that Elm does not allow mutation. This turns out to be great because it eliminates little pockets of state that make your app’s behavior hard to predict and that eventually cause bugs. It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance ben…

Trying to understand, I am still looking for my next front end language.

Isn't immutability a problem in a garbage collected environment? I come from a C++ and ActionScript background, and on the ActionScript side garbage collection was a major issue. Would I not have the same if not worse issues in Elm?

Re: 2017 JavaScript Rising Stars

#76

Post by anonova »

allover wrote: post #17

First I'd heard of dva [1] (#6 in the frameworks section), interesting that it eases use of redux-saga as well as the usual abstractions over redux. redux-saga has been something I've avoided after initial evaluation (I also avoid redux unless absolutely necessary), but might take a second look with this. Hope the project gets some more English translations! https://github.com/dvajs/dva/issues/1#issuecomment-33433418…

I'd expect if it gets popular enough, it'll have to go through a rebranding, given the name and assets are from the video game Overwatch [1]. Though I guess it never stopped Shopify with batman.js [2].

[1]: https://playoverwatch.com/en-us/heroes/dva/

[2]: http://batmanjs.org/

Re: 2017 JavaScript Rising Stars

#77

Post by ausjke »

After comparing react vs vue.js a _lot_ i finally decided to use React instead, for the long run. The real reason is not technical, but that I'm concerned about hit-by-a-bus-factor. Life is too short to bet on it.

I hope the big guns like Alibaba or someone else acquire Vue.js and make it a real competitor to React.

Re: 2017 JavaScript Rising Stars

#78

Post by kevmo314 »

mixedCase wrote: post #65
kevmo314 wrote: post #56

Earlier quoted context omitted.

But why does that need to be tied to the framework? It seems that Elm provides two things that work together well: new language primitives and a functional framework. Tying the success of each component to the other doesn't seem like a great choice.

The Elm experience simply cannot work on JavaScript. It demands a pure, strongly typed functional language that guides developers from any background into the right direction.

I disagree, after all it's compiled to js. As I mentioned, cycle.js is a good example of a functional js framework. Perhaps the experience is much better with a typed, functional language, but saying it can't work without it is disingenuous and haughty. After all, this is how Angular works: the experience is much superior with Typescript, but you can use it with JavaScript if you really want.

Re: 2017 JavaScript Rising Stars

#79

Post by kevmo314 »

zachrose wrote: post #69
kevmo314 wrote: post #22

Earlier quoted context omitted.

Reading over the Elm documentation, I respect the ideals a lot, it looks like a fantastic language, but why does it need to be a completely new language instead of a framework in js? It's not particularly convincing to my co-workers if I have to convince them to try a completely new syntax instead of just a new framework. Actually, I think this is why something like cycle.js is more tractable.

It’s as much about what Elm _doesn’t_ have. The biggest thing here is that Elm does not allow mutation. This turns out to be great because it eliminates little pockets of state that make your app’s behavior hard to predict and that eventually cause bugs. It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance ben…

> It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance benefits of assuming everything is immutable.

Or you could have a runtime development option to detect mutations similar to existing redux-type solutions. This also still doesn't explain why the need for a new language instead of decoupling the two. As I mentioned in another comment, all these features make working in Elm probably a superior experience, but I fail to see why it's mandatory and the mandatory-ness is what makes this a much harder sell.

Re: 2017 JavaScript Rising Stars

#80

Post by dawnerd »

jondubois wrote: post #73
whazor wrote: post #19

Earlier quoted context omitted.

As it is ranked based on new stars in 2017, not total amount of stars.

And it doesn't say much about usage. There are projects which get a lot of stars because people think that it looks cool at a glance but which nobody uses.

Flip side I rarely Star anything I use because, well really doesn’t do anything for me. If anything they should be using npm data instead and seeing what real usage is rather than someone clicking an icon on github.
Post reply on HN