2017 JavaScript Rising Stars(risingstars.js.org)
risingstars.js.org
2017 JavaScript Rising Stars
https://risingstars.js.org/2017/en/
100 コメント
If I recall correctly, the state-of-JS survey did not even have an "Other: ____" field for the Flavors category [1]. Which means that people going to the survey had no way to even mention alternative languages.
The set of languages on state-of-JS is therefore artificially constrained to what the creators of the survey think deserves a place there, rather than the actual community thinks.
[1] https://stateofjs.com/2017/flavors/results
The set of languages on state-of-JS is therefore artificially constrained to what the creators of the survey think deserves a place there, rather than the actual community thinks.
[1] https://stateofjs.com/2017/flavors/results
They included purescript (compilers), so why not elm, which has orders of magnitude more users?
Do you have anything to back up the assertion that it has orders of magnitude more users?
I'm a fan of elm, but but overall population of functional programmers is quite small, so I wouldn't be shocked of Elm, PureScript, and Reason had similar populations of developers.
I'm a fan of elm, but but overall population of functional programmers is quite small, so I wouldn't be shocked of Elm, PureScript, and Reason had similar populations of developers.
Similarly, I wonder if they included Nim[1]. While it's use as a compile-to-js language is more niche I think it deserves to be among the likes of ClojureScript.
1 - https://nim-lang.org
1 - https://nim-lang.org
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 benefits of assuming everything is immutable.
Elm also removes classes, inheritance, == vs ===, and a bunch of other JS junk drawer stuff that turns out to be unnecessary when you have immutability and a thorough type system.
“Perfection is not when there’s nothing more to add, only when there’s nothing more to take away.”
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 benefits of assuming everything is immutable.
Elm also removes classes, inheritance, == vs ===, and a bunch of other JS junk drawer stuff that turns out to be unnecessary when you have immutability and a thorough type system.
“Perfection is not when there’s nothing more to add, only when there’s nothing more to take away.”
> 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.
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.
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.
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.
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?
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?
Because a framework can't bring new language primitives, such as types?
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.
It doesn't work like that in the case of Elm. You can implement the Elm architecture with React, Redux and Redux-saga, but that's just a poor imitation of the API.
The point of Elm is not just the architecture, it's the language that allows you to write robust websites with little to no debugging necessary, all maintaining that robustness no matter how much you extend, tweak and refactor the codebase without having to be an expert in the language.
"Zero runtime exceptions" is no exaggeration, it's a reality in practice guaranteed by the compiler, meaning "after all it's compiled to js" makes no sense.
The point of Elm is not just the architecture, it's the language that allows you to write robust websites with little to no debugging necessary, all maintaining that robustness no matter how much you extend, tweak and refactor the codebase without having to be an expert in the language.
"Zero runtime exceptions" is no exaggeration, it's a reality in practice guaranteed by the compiler, meaning "after all it's compiled to js" makes no sense.
You're still arguing features of the language, not why the framework requires them.
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 and other side-effects without Elm the language is nothing more than convention, so you're not doing any better than Redux+Redux saga on that point.
I'd suggest you try out Elm in a small project and see for yourself why it makes no sense to try to make it fit in the context of JavaScript.
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 and other side-effects without Elm the language is nothing more than convention, so you're not doing any better than Redux+Redux saga on that point.
I'd suggest you try out Elm in a small project and see for yourself why it makes no sense to try to make it fit in the context of JavaScript.
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.
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.
No language that "compiles to javascript" really creates new language primitives - it would have to rewrite the interpreter to do that. What it does do - simulating new language features in javascript - could theoretically be done with a framework as well.
Well then do you think no language that "compiles to machine code" really creates new language primitives, either?
The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
> 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 change the grammar of the language, because those new "primitives" have to be implemented in, and interpreted as, javascript.
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 change the grammar of the language, because those new "primitives" have to be implemented in, and interpreted as, javascript.
> 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 programmed in machine code (punch cards) and assembly was a programming language!
Scala introduces a hell of a lot of “new primitives” over jvm bytecode, and type erasure compiles it all down to the jvm anyway. Or JavaScript, if you use scala.js.
This is, in fact, precisely what compilers do (or transpilers—again: psychological distinction, technically the same thing). That is their job, their function: translating from one language into another. As long as both are Turing complete, you can do anything.
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 programmed in machine code (punch cards) and assembly was a programming language!
Scala introduces a hell of a lot of “new primitives” over jvm bytecode, and type erasure compiles it all down to the jvm anyway. Or JavaScript, if you use scala.js.
This is, in fact, precisely what compilers do (or transpilers—again: psychological distinction, technically the same thing). That is their job, their function: translating from one language into another. As long as both are Turing complete, you can do anything.
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.
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.
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.
> 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.
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.
But that's the grammar I was talking about, so no it doesn't.
Just like no language that compiles to machine code can create new x86 assembler instructions.
So sure, what Elm gives you can be done with just a framework, but it wouldn't be very productive. There is a reason why hardly anybody programs in assembler anymore (unless they have a good reason). Higher-level languages provide better abstractions, allow you to write more expressive code, are safer etc.
So sure, what Elm gives you can be done with just a framework, but it wouldn't be very productive. There is a reason why hardly anybody programs in assembler anymore (unless they have a good reason). Higher-level languages provide better abstractions, allow you to write more expressive code, are safer etc.
No, you wouldn't get the required compile time checks. (Transpile time checks in exact)
A compiler takes input in one language and converts it to another language. That the web community has a fundamental misunderstanding of this and created a derivative word with the same meaning is unfortunate. That it is now being used in misguided pedantic arguments reflects poorly on our community.
The transpiler add-on in the comment wasn't meant to be meaningful anyhow. The main point were the compile time checks, which aren't to be achieved when using a library. Thanks for the correction though!
> Elm exists solely to excel at front-end web development.
Except that it unfortunately falls short of that.
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?
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.
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.
Super anecdotal / off topic but still fun. In 2014 I emailed with a guy who worked at Google to take over control of a domain he wasn’t using. All was well and he gave me access. I checked his Github project. Some tiny SPA framework with three examples and a handful of github stars. Looked nice. Fast forward three years.
Over 2017 me and my (former) small dev team embraced Vue.js, built a non trivial checkout flow and visited the first Vue.js Conf Poland. I’m neck deep in Vue for other projects.
That guy in 2014 was of course Evan You, creator of Vue.js, and I guess I bought the domain for one one of the candidate names for Vue.
Over 2017 me and my (former) small dev team embraced Vue.js, built a non trivial checkout flow and visited the first Vue.js Conf Poland. I’m neck deep in Vue for other projects.
That guy in 2014 was of course Evan You, creator of Vue.js, and I guess I bought the domain for one one of the candidate names for Vue.
Another anecdote. I have been working on a large mobile game in Unity for over 3 years. I need to write a tool to manage the virtual (game) item database so we could add content to the game without updating the app. I could build this app with any environment I wanted (desktop or web, any language/framework).
I chose to make a desktop app with Electron and Vue and Element UI without having any experience with any of those and hardly any JS experience. I had a full working app that synced with a server and allowed multi-user editing with auto updates in under 3 months.
Shared libraries and projects are definitely accelerating developers' abilities to quickly build things.
I chose to make a desktop app with Electron and Vue and Element UI without having any experience with any of those and hardly any JS experience. I had a full working app that synced with a server and allowed multi-user editing with auto updates in under 3 months.
Shared libraries and projects are definitely accelerating developers' abilities to quickly build things.
Hmm, this feels very misleading. What is the correlation between Github stars and real world usage? This is not statistics, it's just 1 variable.. It almost feels like Vue.js is going to take over React just because it received more Github stars? I use React already for years, never gave it a star on Github, and I think many with me.
Stars are pretty useless for what they wanted to measure. Real-world data paints a different picture http://www.npmtrends.com/angular-vs-react-vs-vue-vs-@angular...
Even searching Github for 'import React from 'react' and 'import Vue from 'vue' results in similar percentages. Roughly 7-8 million projects in Github on React, under a million on Vue.
Despite the hype, Vue has been mostly a flat over the last 2 years with a slight upward bend, but only to the point where it begins to catch up with the old Angular 1.x.
Even searching Github for 'import React from 'react' and 'import Vue from 'vue' results in similar percentages. Roughly 7-8 million projects in Github on React, under a million on Vue.
Despite the hype, Vue has been mostly a flat over the last 2 years with a slight upward bend, but only to the point where it begins to catch up with the old Angular 1.x.
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.
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 clearer picture, yes it did grow, but relatively contained compared to its competitors, specifically React.
And is it any wonder to anyone? I really ask myself. Would you go back to a stryingly typed templating framework with a complex api and ever changing ruleset, reliant on dependency injection and all the other stuff we went through with Angular? I don't think anyone would. It rather looks like Vue is catching the last remaining Angular 1.x refugees, but there isn't an ever increasing supply of those.
Go 2 years back on that page and you see a clearer picture, yes it did grow, but relatively contained compared to its competitors, specifically React.
And is it any wonder to anyone? I really ask myself. Would you go back to a stryingly typed templating framework with a complex api and ever changing ruleset, reliant on dependency injection and all the other stuff we went through with Angular? I don't think anyone would. It rather looks like Vue is catching the last remaining Angular 1.x refugees, but there isn't an ever increasing supply of those.
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.
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.
Vue has a bigger ecosystem than you're thinking.
https://github.com/lyonlai/blessed-vue
Either way, it's not such an issue. It's not hard to build on React when you want react and Vue when you want vue. They're easy to pick up the concepts on.
https://github.com/lyonlai/blessed-vue
Either way, it's not such an issue. It's not hard to build on React when you want react and Vue when you want vue. They're easy to pick up the concepts on.
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 way.
As it stands npms numbers coincide with all the other sources you could pull: projects on github, tracked project dependencies, size of eco system, job market, etc.
As it stands npms numbers coincide with all the other sources you could pull: projects on github, tracked project dependencies, size of eco system, job market, etc.
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.
I think I was overstating Alibaba and Tencent's use of Vue with that of other Chinese developers or software shops.
We've had some questions on how libraries were selected. Basically, they were manually added and tagged on http://bestof.js.org, and we then reused the data to build the Rising Stars rankings.
So if you see a library missing, it could be because we didn't know about it and didn't add it to the database, or maybe tagged it in a way that excluded it from a specific category. Feedback welcome!
So if you see a library missing, it could be because we didn't know about it and didn't add it to the database, or maybe tagged it in a way that excluded it from a specific category. Feedback welcome!
Hey Sacha, we both spoke at NordicJS where we met. You mentioned your survey found a bunch of stats on my library's growth, and I know it has gone up by +3K in 2017 (total of 7K+ now), yet it seems unfortunately left out because gun isn't "tagged" as anything more than a database, not even a NodeJS framework (when it is, at least as much as Feathers is).
30+ projects were highlighted with less than 3K+ increase in stars, so it is just frustrating/disheartening to see mine left out. :/ Any chance there could be a "Everything Else" category or adding "NodeJS Framework" as a tag to us?
30+ projects were highlighted with less than 3K+ increase in stars, so it is just frustrating/disheartening to see mine left out. :/ Any chance there could be a "Everything Else" category or adding "NodeJS Framework" as a tag to us?
The article mentions that Ava differs from Jest because of its focus on speed. Just figured I'd mention we are in the process of migrating from Ava to Jest, and we gained a 5x speedup in running our entire suite.
Jest improved so much since its first release, in the beginning it was mentioned only to test React components. Ava made the speed its first selling argument but Jest may be even faster, now... Thank you for your remark, we are going to update the comments accordingly, to say only "AVA emphasises on speed", removing "Compared to Jest".
I never understood the Ava speed claim. Always was much slower than either Mocha or Jest.
I don't know for sure, but I think Ava embraced testing concurrently before the other testing frameworks did.
Somewhat predictably, the (static, non-interactive) page took about 30 seconds to load, thanks to all the Javascript.
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 textual + hyperlink content took under 10 seconds, images slowly came in after that over a longer period.
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 textual + hyperlink content took under 10 seconds, images slowly came in after that over a longer period.
> 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.
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.
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.
The site took me less than a second to load, and I have a mediocre Pc. Problem is on your end.
You're the 2692389284th person writing this comment on HN and frankly it gets a bit tiring.
Tried to upvote but javascript paywall
JS makes up about 300 of the site's 950kB weight. How does it alone contribute to a 30 second load time for you?
It is a bit much, but this article is pretty heavy for a 250kbps connection even with just html and images.
It is a bit much, but this article is pretty heavy for a 250kbps connection even with just html and images.
Are you sure it wasn't just all the images? There's quite a lot of them. Also you can click on each project to show more info, so it's somewhat interactive.
It is interactive - you can uncover more info by clicking in the lists.
Hmm, mine was done in four seconds, on my phone.
I actually find this very informative, it gives a good overview of the js landscape right now. I'm however perplexed as to why the back button doesn't work, which makes navigation really hard particularly annoying on android mobile as pressing back ends up closing the browser. It uses react, so I thought that was pretty much supported out of the box. Any idea?
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-334334184
https://github.com/dvajs/dva/issues/1#issuecomment-334334184
Ditto with Ant Design (#14 on most popular projects) where most of their community is Chinese: https://github.com/ant-design/ant-design/issues. Their UI framework is the most comprehensive I have seen.
I am sure english will remain the dominant language for a while but I wonder if it makes sense to start learning new (human) languages just to open up the number of communities you can learn from?
I am sure english will remain the dominant language for a while but I wonder if it makes sense to start learning new (human) languages just to open up the number of communities you can learn from?
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/
[1]: https://playoverwatch.com/en-us/heroes/dva/
[2]: http://batmanjs.org/
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
https://github.com/polymer/polymer https://risingstars.js.org/2017/en/#section-framework
First of all, that is "stars added in that year", not "stars total".
Secondly, shouldn't the fact that that would have made Polymer #3 given you some thought?
Polymer has ~19k stars total.
React has ~85k stars total.
Vue has ~80k stars total.
AngularJS (v1) has ~58k stars total.
Angular (v2+) has ~32k stars total.
Ember has ~18.6k stars total.
Preact has ~17k stars total.
So Polymer is behind React, Vue, AngularJS and Angular on total stars, having just surpassed Ember. Placing it 3rd in the rising stars list would have placed it before Angular.
I'd think "Polymer is more popular than Angular" would have been pretty newsworthy.
Secondly, shouldn't the fact that that would have made Polymer #3 given you some thought?
Polymer has ~19k stars total.
React has ~85k stars total.
Vue has ~80k stars total.
AngularJS (v1) has ~58k stars total.
Angular (v2+) has ~32k stars total.
Ember has ~18.6k stars total.
Preact has ~17k stars total.
So Polymer is behind React, Vue, AngularJS and Angular on total stars, having just surpassed Ember. Placing it 3rd in the rising stars list would have placed it before Angular.
I'd think "Polymer is more popular than Angular" would have been pretty newsworthy.
Oops, my bad. I guess this is the reality I didn't want to embrace. Everyone reinventing their own "standards".
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.
Note, this ranking is based on number of new GitHub stars in 2017. Vue.js currently has ~79k stars and, number two on the list, React has ~85k stars. Vue.js is poised to surpass React this year in number of GitHub stars. Whatever that is worth.
It's great to see Vue.js getting so much love. I've been extolling it's virtue on HN and elsewhere for years now. The fact that it has gained so much traction and is not the baby of one of the big Internet megacorps is a testament to it's genuine quality as a frontend Web framework. After many devs finally realized that Angular sucked even though, or especially because, it was backed by Google, it was sad to see the same people jump on to the React bandwagon, in a large part, because it was backed by Facebook. There are legitimate reasons for liking React but a lot of its adoption has been due to FOMO. Vue.js stands on its own.
It's great to see Vue.js getting so much love. I've been extolling it's virtue on HN and elsewhere for years now. The fact that it has gained so much traction and is not the baby of one of the big Internet megacorps is a testament to it's genuine quality as a frontend Web framework. After many devs finally realized that Angular sucked even though, or especially because, it was backed by Google, it was sad to see the same people jump on to the React bandwagon, in a large part, because it was backed by Facebook. There are legitimate reasons for liking React but a lot of its adoption has been due to FOMO. Vue.js stands on its own.
Michael speaking, from Best of JavaScript project. One year ago, when "JavaScript Rising Stars 2016" was published, the topic was hot on HackerNews, there were a lot of questions about the data.
What was compiled here is only the variation of the numbers of stars on GitHub, over the span of one year.
Of course it's just one metrics we picked, but we hope it will give you a good understanding of what was the JavaScript landscape in 2017.
ClojureScript surpassed CoffeeScript. That has to be a milestone, or some end of an era and the beginning of a new one, or something along those lines.
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.
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.
Most promising project for larger enterprise I discovered in 2017:
Single SPA - a Javascript Meta Framework https://github.com/CanopyTax/single-spa
>>Use multiple frameworks on the same page without refreshing the page (React, AngularJS, Angular, Ember, or whatever you're using) >>Write code using a new framework, without rewriting your existing app >>Lazy load code for improved initial load time.
Unfortunately also missing in lists like this one.
Single SPA - a Javascript Meta Framework https://github.com/CanopyTax/single-spa
>>Use multiple frameworks on the same page without refreshing the page (React, AngularJS, Angular, Ember, or whatever you're using) >>Write code using a new framework, without rewriting your existing app >>Lazy load code for improved initial load time.
Unfortunately also missing in lists like this one.
> You want to add new features to the language... such as "type checking".
Feel free to put that in scare quotes, as if you can barely register its existence! In fact, that whole enterprise is probably misguided and full of falsehoods, anyways, having witnessed the lies and attacks, first hand, for years! Better nip it in the bud now, while you still can!
Feel free to put that in scare quotes, as if you can barely register its existence! In fact, that whole enterprise is probably misguided and full of falsehoods, anyways, having witnessed the lies and attacks, first hand, for years! Better nip it in the bud now, while you still can!
>scare quotes
I don't think the author had malicious intent.
Unfortunately, we use quote marks for at least 2 different meanings:
(1) <scare_quote>type checking</scare_quote> ... as dismissive sarcasm
(2) <term_of_art_quote>type checking</term_of_art_quote> ... as a delimiters for industry vocabulary
Based on all the other uses of quotes in the blog post, he's using it as (2) terms of art. Some style guides suggest using italics instead of quotes for terms of art but a nice property of "quotes" is that it survives copy & paste into plain text files.
I don't think the author had malicious intent.
Unfortunately, we use quote marks for at least 2 different meanings:
(1) <scare_quote>type checking</scare_quote> ... as dismissive sarcasm
(2) <term_of_art_quote>type checking</term_of_art_quote> ... as a delimiters for industry vocabulary
Based on all the other uses of quotes in the blog post, he's using it as (2) terms of art. Some style guides suggest using italics instead of quotes for terms of art but a nice property of "quotes" is that it survives copy & paste into plain text files.
Ah i see.. my mistake, thank you.
Great for vue, my favorite frontend framework for a while now.
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!
NO IT IS NOT!
Yes it’s a different language that compiles to JavaScript, but unlike other languages that do this, Elm exists solely to excel at front-end web development.
Ironically, that Redux and React equivalents are some of the “batteries included” in Elm can make it harder to pitch because at first it seems like you’d have to add that stuff in.