JavaScript 2017 Rising Stars
slowwaker.work
JavaScript 2017 Rising Stars
1–10 of 25 posts
Re: JavaScript 2017 Rising Stars
#2The article only talks about quantity, not quality and that is the main problem with javascript.
Not so long ago I had to work with graphs in javascript and none of the graph libraries I found explained the implementation details or the complexities of the algorithms.
It turned out that the implementations were ad-hoc and the time complexities were bad so I had to implement my own because they did not work for real life usage, only the example projects.
I'd rather have 1-2 options for solving a problem which are well documented and implemented properly instead of having zounds of crappy libs which don't worth a penny.
Re: JavaScript 2017 Rising Stars
#3> With big project like Vue.js and React, it’s almost becoming a pleasure to design your interface using Javascript. (...)
> DisplayJS (...) is lightweight (100kb for the entire library)
React + React DOM is around 100kB, Vue is 86kB.
Re: JavaScript 2017 Rising Stars
#4The article only talks about quantity, not quality and that is the main problem with javascript. Not so long ago I had to work with graphs in javascript and none of the graph libraries I found explained the implementation details or the complexities of the algorithms. It turned out that the implementations were ad-hoc and the time complexities were bad so I had to implement my own because they did not work for real l…
But Javascript is mostly open source! Why not publish your library [1], make a PR with improvements to the existing ones or donate to the authors so they can dedicate more time on those?
Re: JavaScript 2017 Rising Stars
#5The article only talks about quantity, not quality and that is the main problem with javascript. Not so long ago I had to work with graphs in javascript and none of the graph libraries I found explained the implementation details or the complexities of the algorithms. It turned out that the implementations were ad-hoc and the time complexities were bad so I had to implement my own because they did not work for real l…
It appears to me that due the Github-CV-driven startups, everyone is publishing stuff just to show to such companies.
The end result are piles of unmaintained libraries, with dubious quality, making quite hard to find battle tested useful libraries.
Re: JavaScript 2017 Rising Stars
#6The article only talks about quantity, not quality and that is the main problem with javascript. Not so long ago I had to work with graphs in javascript and none of the graph libraries I found explained the implementation details or the complexities of the algorithms. It turned out that the implementations were ad-hoc and the time complexities were bad so I had to implement my own because they did not work for real l…
Javascript graphing libraries are a pain in the arse, whenever graphing comes up at work we all cringe at the prospect of having yet another go at picking a library out of the millions that is: not painfully slow, not terribly written and not poorly designed even though they are all written on top of D3. I've also submitted PRs so some that I will not name in an attempt to optimise them semi successfully, but you start to realise that none of these were designed with performance in mind, most are just arbitrary collections of declarative D3 bundled together into predefined graphs and some user configuration passed through.
But to be a little more fair, I think a big part of the problem is that graphing is such a subjective problem to solve, that's why there are a million libraries - because there is no correct way to do it, and so it's all spread so thin.
... with some exceptions, for what I do, that's scientific graphing, if you want this you will find that all but two libraries are just not fit for purpose. What you will want is matplotlib - but that is python. The closest thing i've found in JavaScript is Plotly, and frankly, even from a non scientific graphing perspective I'd still choose this library, it's quite fast (for something object/D3 based) and is simultaneously comprehensive and customisable, to put a cherry on top it can also use it's JSON schema to define all aspects of a graph. - but it's not new and trendy, so it's not on the list.
Re: JavaScript 2017 Rising Stars
#7> With big project like Vue.js and React, it’s almost becoming a pleasure to design your interface using Javascript. (...) > DisplayJS (...) is lightweight (100kb for the entire library) React + React DOM is around 100kB, Vue is 86kB.
Coming from an angular world I went full spartan and just used jQuery (I tried to go native but the DOM interface is rather long winded) - it felt so good, suddenly you realise that for most things model view control is pretty simple to do with a few lines of code and you have the advantage of being able to see exactly what is happening.
Re: JavaScript 2017 Rising Stars
#8fuzzy sorting with no mention of fuzzball?! surely an error
/shameless self* promo :P
*as much as porting something from another language can be self promo
edit: ok technically launched dec '16 so not meet criteria, omission acceptable
Re: JavaScript 2017 Rising Stars
#9The article only talks about quantity, not quality and that is the main problem with javascript. Not so long ago I had to work with graphs in javascript and none of the graph libraries I found explained the implementation details or the complexities of the algorithms. It turned out that the implementations were ad-hoc and the time complexities were bad so I had to implement my own because they did not work for real l…
Javascript graphing libraries are a pain in the arse, whenever graphing comes up at work we all cringe at the prospect of having yet another go at picking a library out of the millions that is: not painfully slow, not terribly written and not poorly designed even though they are all written on top of D3. I've also submitted PRs so some that I will not name in an attempt to optimise them semi successfully, but you sta…
I think GP was referring more to graphs as the abstract mathematical concept, rather than graphical plots.
Re: JavaScript 2017 Rising Stars
#10> With big project like Vue.js and React, it’s almost becoming a pleasure to design your interface using Javascript. (...) > DisplayJS (...) is lightweight (100kb for the entire library) React + React DOM is around 100kB, Vue is 86kB.
There's something really upsetting to me about how DisplayJS works - coupling variable names to HTML seems like a good idea for a lot of common use cases at first, but the library's API method calls, DisplayJS.var() and .target(), have no semantic meaning to me. It seems overly simplistic. And if I have to manually call .var() in my target callback, I'm missing much of the benefits of reactivity in Vue / React.