5 ms·

JavaScript 2017 Rising Stars

70 points by kazup 9y ago

edem 9y ago
The 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.
- franciscop 9y ago
  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? [1] https://xkcd.com/927/ https://xkcd.com/927/
  - edem 9y ago
    Two reasons: - I only use javascript if I really have to - Most javascript libraries are so horrible that I'd rather write something from scratch than touching existing code I donate to the Java/Kotlin ecosystem though.
- pjmlp 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - rushabh 9y ago
    That is very cynical comment. Libraries are made to fill a gap. The reason they come up so fast is that the underlying technology keeps changing. It is so easy to forget that these are open sourced libs with permissible licenses that you can hop in and fix if you you want them better.
    - pjmlp 9y ago
      Rather a comment based on a few decades of work experience. We have libraries since programming is a thing, only now we have a Github-CV-driven portfolio fashion going on, not even with Sourceforge in its golden days did it happen.
    - edem 9y ago
      It is not that easy to hop in and fix stuff especially if you are not versed in that technology or if the code is crap. There are a lot of very good libraries which are quite easy to maintain and a lot of horrible monstrosities which you'd rather not touch. I also think that there are a lot of libraries which are experiments and don't try to fill the gap. A lot of folks write something to learn a tech and put it on GitHub to show off. This is a win-win and I don't have any problems with that. In case of Java there is a hard barrier: putting things on Maven Central. If you pull something from there you can be sure that the author went through the hoops to be able to publish stuff there and he/she is serious about his stuff. With Javascript the barrier is so low that npm/yarn is flooded with crap.
- tomxor 9y ago
  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.
  - auxym 9y ago
    I think GP was referring more to graphs as the abstract mathematical concept, rather than graphical plots. https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) https://en.wikipedia.org/wiki/Graph_(discrete_mathematics)
    - tomxor 9y ago
      my mistake, he said "graph libraries" and a graphing library is in the article's short list.
  - jdpigeon 9y ago
    Would you recommend Plotly for real-time charts that update visually around 60fps? At work we wrote wrote ours in pure D3, but it was as pain in the ass
methyl 9y ago
> 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.
- tomxor 9y ago
  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.
  - dbkaplun 9y ago
    jQuery's bread and butter is DOM manipulation. However, for even moderately small use cases (even an interactive form) it is useful to use React, Angular, or some data binding framework, as state changes in jQuery quickly become unmaintainable.
    - tomxor 9y ago
      It _can_ become unmaintainable but it entirely depends on how you define your view state, you can still create large applications with jquery if you refrain from creating overly complex state UI (speaking from experience). One thing I find overly shunned in favour of heavy MVC is CSS, CSS is a bloody state machine, it's perfect to manage your UI, you need one DOM call to update one piece of state... define the reset in CSS and your MVC UI component suddenly seem over engineered.
- lobo_tuerto 9y ago
  "If you were disappointed with Vue.js, React, etc... If you want something super simple to build UI, just try DisplayJS! We hope you'll choose DisplayJS next time you do something great!" I think it's really hard to be disappointed with Vue.js. Or will hardly find anyone that is. (That's from DisplayJS' homepage at https://display.js.org/ https://display.js.org/)
nol13 9y ago
fuzzy 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
- nol13 9y ago
  not that fuzzysort not great or anything, i like the scoreFn and prepare api's ;) diff algs for diff things

70 points by kazup 9y ago

edem 9y ago

The 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.

franciscop 9y ago
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? [1] https://xkcd.com/927/ https://xkcd.com/927/
- edem 9y ago
  Two reasons: - I only use javascript if I really have to - Most javascript libraries are so horrible that I'd rather write something from scratch than touching existing code I donate to the Java/Kotlin ecosystem though.
pjmlp 9y ago
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.
- deleted 9y ago
  [deleted]
- rushabh 9y ago
  That is very cynical comment. Libraries are made to fill a gap. The reason they come up so fast is that the underlying technology keeps changing. It is so easy to forget that these are open sourced libs with permissible licenses that you can hop in and fix if you you want them better.
  - pjmlp 9y ago
    Rather a comment based on a few decades of work experience. We have libraries since programming is a thing, only now we have a Github-CV-driven portfolio fashion going on, not even with Sourceforge in its golden days did it happen.
  - edem 9y ago
    It is not that easy to hop in and fix stuff especially if you are not versed in that technology or if the code is crap. There are a lot of very good libraries which are quite easy to maintain and a lot of horrible monstrosities which you'd rather not touch. I also think that there are a lot of libraries which are experiments and don't try to fill the gap. A lot of folks write something to learn a tech and put it on GitHub to show off. This is a win-win and I don't have any problems with that. In case of Java there is a hard barrier: putting things on Maven Central. If you pull something from there you can be sure that the author went through the hoops to be able to publish stuff there and he/she is serious about his stuff. With Javascript the barrier is so low that npm/yarn is flooded with crap.
tomxor 9y ago
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.
- auxym 9y ago
  I think GP was referring more to graphs as the abstract mathematical concept, rather than graphical plots. https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) https://en.wikipedia.org/wiki/Graph_(discrete_mathematics)
  - tomxor 9y ago
    my mistake, he said "graph libraries" and a graphing library is in the article's short list.
- jdpigeon 9y ago
  Would you recommend Plotly for real-time charts that update visually around 60fps? At work we wrote wrote ours in pure D3, but it was as pain in the ass

methyl 9y ago

> 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.

tomxor 9y ago
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.
- dbkaplun 9y ago
  jQuery's bread and butter is DOM manipulation. However, for even moderately small use cases (even an interactive form) it is useful to use React, Angular, or some data binding framework, as state changes in jQuery quickly become unmaintainable.
  - tomxor 9y ago
    It _can_ become unmaintainable but it entirely depends on how you define your view state, you can still create large applications with jquery if you refrain from creating overly complex state UI (speaking from experience). One thing I find overly shunned in favour of heavy MVC is CSS, CSS is a bloody state machine, it's perfect to manage your UI, you need one DOM call to update one piece of state... define the reset in CSS and your MVC UI component suddenly seem over engineered.
lobo_tuerto 9y ago
"If you were disappointed with Vue.js, React, etc... If you want something super simple to build UI, just try DisplayJS! We hope you'll choose DisplayJS next time you do something great!" I think it's really hard to be disappointed with Vue.js. Or will hardly find anyone that is. (That's from DisplayJS' homepage at https://display.js.org/ https://display.js.org/)

nol13 9y ago

fuzzy 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

nol13 9y ago
not that fuzzysort not great or anything, i like the scoreFn and prepare api's ;) diff algs for diff things