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

91–100 of 101 posts

Re: 2017 JavaScript Rising Stars

#91

Post by mixedCase »

kevmo314 wrote: post #89
mixedCase wrote: post #88

Earlier quoted context omitted.

I already told you, go use React, Redux and Redux-saga, Elm the framework makes little sense on JavaScript where you cannot enforce many of the constraints the framework is designed around and you'd be doing yourself a disservice by forcing it in. In Elm you don't have exceptions, so the framework does not accomodate for them like, say, React does. It's also a pure language, so the separation of main state mutation a…

So, essentially you're saying that Elm is not a framework, it's just a language. Okay, that works too.

Nope, that's not it either, since you can use Elm the language without importing Elm.Html ("Elm the framework").

It's simply that Elm the framework was designed without regard for the problems of other languages, and making full use of the features of Elm the language.

On the other hand, Redux was inspired by Elm to replicate the same model in JavaScript while accounting for the deficiencies of that language. The closest you can get to Elm is probably that.

Re: 2017 JavaScript Rising Stars

#92

Post by mlsarecmg »

bpicolo wrote: post #83
chrisco255 wrote: post #74

Earlier quoted context omitted.

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.

I don't think it needs the ecosystem React has. It has all of the components you need to build excellent software - great debugging experiences, testing, routing, state management. At that point it doesn't really matter all that much what else you've got.

Honestly that is like saying Windows Phone doesn't need the apps.

React has a self sufficient cross platform eco system. I don't think people using primarily web frameworks even realize the implications of that yet. React works outside of the browser, and not just natively on mobile but literally everywhere. Imagine you use React as you always would to make a native command line application (https://github.com/Yomguithereal/react-blessed), but now you want to have a store or move things around, so you `npm install react-redux react-motion` and you just apply it (https://github.com/gaearon/react-blessed-hot-motion). Look at the code and try to picture the overhead if you had to do this in C++.

Being able to transfer code and knowledge, and seeing new renderers pop up for the wildest platforms each day, as well as official renderers made by big vendors (https://github.com/Microsoft/react-native-windows), the idea of a web-bound Angular-like framework seems odd in 2018. I wouldn't expect Vue to get the same kind of popularity without at least competing or doing something new.

Re: 2017 JavaScript Rising Stars

#93

Post by ausjke »

bpicolo wrote: post #82
ausjke wrote: post #77

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.

There's plenty of community, it's just well-driven by Evan. I wouldn't be worried about bugs going unfixed if Evan weren't on the project anymore.

believe so, another point is that React Native seems really nice, that Weex for Vue.js seems a lot weaker, ideally with React you will be easier to leverage it with React Native.

Re: 2017 JavaScript Rising Stars

#94

Post by erezsh »

worble wrote: post #61
indexerror wrote: post #57

Earlier quoted context omitted.

> Elm exists solely to excel at front-end web development. Except that it unfortunately falls short of that.

In what ways? Bearing in mind it's still in development and doesn't claim to be production ready by any means.

Umm.. That's pretty damning. Why would a technology that isn't production ready yet be featured in a "most popular" list?

Re: 2017 JavaScript Rising Stars

#95

Post by zachrose »

erezsh wrote: post #94
worble wrote: post #61

Earlier quoted context omitted.

In what ways? Bearing in mind it's still in development and doesn't claim to be production ready by any means.

Umm.. That's pretty damning. Why would a technology that isn't production ready yet be featured in a "most popular" list?

In my experience there’s a difference between being production ready and claiming to be production ready.

Quite a few projects (Node.js and Backbone) achieved wide adoption before 1.0.0.

For the record I’m not sure the Elm project has any claim one way or another, apart from the current version of 0.18 and the main contributors having large code bases in production at private companies.

So maybe it’s not that damning, and we still haven’t heard the GPs thoughts on how Elm has fallen short for them.

Re: 2017 JavaScript Rising Stars

#96

Post by azemetre »

mlsarecmg wrote: post #68
azemetre wrote: post #64

Earlier quoted context omitted.

Does this account for development done in Eastern Asia/China? It's my understanding that Chinese developers have heavily embraced vue over react and I don't know what limitations the great firewall has on frontend tools like npm or repositories such as github, maybe the stats are biased towards Western development.

Github and Npm are both used in China all the same. I don't know about firewall restrictions, many chinese companies publish directly on Github. React is the most used in China in polls as well (stateofJS), with some of the biggest names and websites using it. If China would be excluded in these stats, that would impact Reacts outlook more for sure, any exception one could make would directly affect React in the same…

I see, I wasn't too sure.

I think I was overstating Alibaba and Tencent's use of Vue with that of other Chinese developers or software shops.

Re: 2017 JavaScript Rising Stars

#97

Post by zachrose »

kevmo314 wrote: post #79
zachrose wrote: post #69

Earlier quoted context omitted.

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 m…

Yes, but using Elm has convinced me of the significant difference between runtime checks and compile time checks.

In a large enough codebase, reaching every code path is non-trivial. It’s very easy to write code that only runs when it gets a certain response from a server, and at that point you need an entire integrated environment, plus a humongous space of configuration and use cases. (Or highly detailed mocks and 100% test coverage, which is even more rare.)

By contrast, you get that much certainty every time an Elm program compiles.

Maybe it’s possible to statically analyze JS to the point where you can get the same guarantees as compiling from a stricter language, but that seems very very hard.

Re: 2017 JavaScript Rising Stars

#98

Post by krapp »

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…

Ten hours later and it's obvious from the all but unanimous negativity that I'm wrong about something.

But, I don't think the distinction is entirely psychological. Every numeric type is implemented in javascript as a floating point Number, that's all javascript has. New types aren't added to javascript when other languages compile to it, they're compensated for within the limits of what a javascript parser considers valid code, either through existing javascript types or facades which imitate types. Whatever Scala or any other language considers an Int, BigInt, Double, etc. must still be implemented as a Number when compiled to javascript, or some object which imitates the semantics of the original language. But an Int() object in javascript is still not an integer.

It doesn't make sense to say that languages which compile to javascript add anything to the language. Or maybe I just don't understand types, and they really do, and it really doesn't matter. But to me, the distinction seems to matter.

I should probably stop tilting at this particular windmill, though.

Re: 2017 JavaScript Rising Stars

#99

Post by krapp »

jstanley wrote: post #40
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…

> it doesn't actually change the grammar of the language Yes it does! That's the entire point. It doesn't change the grammar of the language that the generated code is using, but you don't care, because you're not writing in that language.

>It doesn't change the grammar of the language that the generated code is using, but you don't care, because you're not writing in that language.

But that's the grammar I was talking about, so no it doesn't.

Re: 2017 JavaScript Rising Stars

#100

Post by joncampbelldev »

tinus_hn wrote: post #59
joncampbelldev wrote: post #23

Earlier quoted context omitted.

Nope, javascript is less than 1/4 of this page, time for the "above the fold" render for me (on standard laptop + broadband) is under 0.5 seconds. Please examine other possible causes for a 30 second page load, unless you're running on an 1st gen raspberry pi, 56k modem and a browser with a showstoppingly bad js engine. EDIT, using chrome's dev tools I tried loading with the "slow 3g" preset, rendering of useful text…

> using chrome's dev tools I tried loading with the "slow 3g" preset, rendering of useful textual + hyperlink content took under 10 seconds, images slowly came in after that over a longer period. That is not an achievement.

On a page crammed full of images its alright, they're going to be slowing down the loading of everything.

If it were a plain text document and it was only JS loading and parsing that slowed it down then it would indeed be embarrassing.

My response is to the person asserting that JS is the reason this page is slow. I'm not making a statement that this is the greatest and fastest loading page on earth.

Post reply on HN