Tell HN: Please bring back comment scores - <AUTHOR> I miss comment scores.<p>Perhaps we could strike middle ground by displaying a range, eg. 1,  2-5,  5-10,  10+ <comment><USER2> People can be wrong about things, and comment scores are useful information that helps us know if they are.

"that is not how mysql works" with 2 Points And "that is not how mysql works" with 102 points Are not the same piece of info.

I don't see any benefit to hiding this from people. It also helps newbies understand the customs here (they can get feedback on other people's comments)

edit now that I'm not on my phone:

When you google things, you probably skip over results like daniweb, about.com, or expertsexchange.com, and hope for a stackexchange page.

The little URL at the bottom of the description tells you "hey, this is from $foo source" and you're a smart human being that can put this information to good use.

Of course, you _could_ make a case that this is bad, because you should read each one of the results and judge it based on its merits. Maybe we should even strip all of the identifying information away from the page, and just let it stand on its own (this would be a neat experiment, actually [and that's the experiment that I think we're performing here]).

The point counts on the comments act just like the URL does on google results. It's not saying "this is definitely 100% accurate", but it is useful piece of information that we can put to good use. Depriving us of this information doesn't _break_ the comments, but I have certainly found myself reading comments a bit less lately as a result of it (instead of actually reading comments, I'm usually just skimming them now). With comment scores, things seem to have a bit of order to them, without, it just feels like a lot of people shouting at one another.

(Maybe this was the point?)

Naturally, I'm never going to stop reading HN; it is by far my favorite website on the internet. Complaining about the lack of comment points here is like complaining that my favorite bar switched to a new, very slightly different glass. I can see the difference, but it's not really going to change my habits.

<comment><USER3> You can see how agreeable a comment is by how far up the page it is.

I think having the scores hidden is a good decision. It means that we concentrate on content rather than a 'karma game'.

" _"that is not how mysql works" with 2 Points And "that is not how mysql works" with 102 points Are not the same piece of info._ "

In my opinion, both of those comments are bad comments unless they further qualify the statement. I don't think karma should be used to infer whether a statement is correct.

<comment><USER4> Just expand the example: pretend it was "that is not the way mysql works blah blah explanation". I agree that I don't want to read this if it has 2 points but I do if it has 100.

<comment><USER5> So many of the discussions around these points here center around the "TL;DR" point of view.

I wonder how these people ever managed to make it through a newspaper without scores telling them which articles are worth it.

Learn to survey, skim, and dive in. All your endeavors will be the better for it.

PS. Your method (don't read if don't like score) also ensures you won't be soiled by accidentally reading an unpopular but truthful point of view.

<comment><USER6> A better example would be choosing which newspapers to read based on your friend's recommendations, versus choosing by yourself. All articles from the same newspaper share a source and it already ensures some quality.

<comment><USER5> > _All articles from the same newspaper share a source and it already ensures > some quality_

You make an excellent point, applicable here: newspaper brand = web brand.

Articles not flagged [dead] on news.ycombinator.com already ensure some quality, and both similarly share a "front page".

<comment><USER6> Wait, are you talking about articles on HN? Because only comments have their score hidden, you can still see how many points each article has.

My point was comparing newspapers brands/articles to HN _comments_ , not articles, since you don't have much guidance anymore over what _comments_ are worthwhile or not.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The only place I really miss having them is in older articles and on searchyc.com. I feel a much greater compulsion to engage each comment on its merit when voting and when reading, and I feel like reading HN has become more intellectually stimulating.

However, this is more of a problem when I'm trying to assess information in areas that I'm not already familiar with. If I'm searching for information on which DNS providers are best and I find an Ask HN from 4 months ago, I can no longer tell what the true community consensus on it is. I expect the current masking of comments will provide less biased voting, so I think displaying comment scores on stories that are more than two months old would eventually provide the best of both worlds.

<comment><USER8> ABSOLUTELY.

Comment scores in the midst of an active discussion narrow thinking. Comment scores on historical artifacts are useful for research.

<comment><USER9> I think if people in general see a comment that has been upvoted heavily they are less likely to contribute their opinion to it if they agree with it. I like not being able to see its weight as I feel like more readers will comment with their opinions rather than just upvote, which creates more discussion, etc (I have no numbers to back this up, just what I believe).

<comment><USER10> This is true for me--I have felt more encouraged to contribute to discussions now that the votes are hidden as opposed to before; As long as the higher voted comments bubble up to the top I don't see a reason to see the votes count with a comment.

</comment></comment></comment></comment><comment><USER11> I really like the lack of comment scores. Things are still sorted, so the cream floats to the top, and it made me realize I felt group-impulses based on the score.

Now, there is little to no incentive to one-up someone, and I don't consider people refuted based on their score, but rather based on what I think of their comment. That last part has nurtured my curiosity, I find myself exploring thoughts I didn't on the 'old' HN

<comment><USER12> This is my dilemma, and based on pg's recent poll may be part of why that vote was split. Basically, I feel that I'm interacting more intelligently _but_ receiving less value from the conversation.

I feeling that I am contributing differently, assessing comments more on merit and adding my own thoughts less. I'm certainly voting on comments less (both up and down).

But I find I lack context in many of those discussions - when there are two different views on technical matters, I can't tell the difference in the group's opinion (especially if one is a reply to the other, so not comparable by which is 'higher' in the tree). Group think is bad, by blhack's mysql example is positive group interaction.

I also notice a similar lack of feedback on what is and isn't acceptable by the group. If a snide one-liner sits at the same level as a well-reasoned response, there's nothing to tell us all that one has 15pts in support and one has 1pt (an extreme example - other, more subtle ones, are now only noticeable if someone is greyed out for a negative score). There's no opportunity for us to learn from other's experience.

All in all, I want them back.

<comment><USER13> How do you vote down?

<comment><USER12> When you get to a certain level of Karma, you will have the ability to vote down comments (but not articles). The figure changes - I think the level is currently 500 (it was less when I rose through the system, but there were fewer members so fewer votes to go around back then).

</comment></comment></comment></comment><comment><USER14> Nah, I like not seeing the comment scores.

But today I did think of a different improvement I'd like to see, which for lack of better place to put it, will say here:

When I click on "reply" to a comment, it takes you to a page with just that comment and a text box. I'd like to see that comment's parents all the way to the OP, to give me some more context as I frame my reply.

I think it would improve discussion as you'll see the context in which the person you're replying to replied, and might interpret their words a little differently.

</comment><comment><USER15> I'm struggling to understand why you need comment scores to know what to think about something. I can make up my mind about a comment's quality using the info available to me right now.

Let's take the oft-repeated example in other comments: two comments on MySQL, one with a handful of points and the other with a lot of points. There are a number of indicators of comment quality:

>> comment sorting works very well

>> if a low-vote comment is controversial, you will surely find spirited discussion below it--the volume of discussion would be an indicator of community disagreement

>> hit up Stack Overflow and find out if MySQL works as stated in the low-vote comment or if it works like the high-vote comment describes.

The arguments for visible points boil down to "I don't know how to think about this statement, so I need external confirmation." Indicators of comment quality still exist, and karma gamesmanship looks like it has decreased a lot. Finally, you _really_ want to avoid groupthink--hiding scores accomplishes that pretty well.

</comment><comment><USER16> I like the new system. It discourages winning an argument with numbers. 20 people upvoted the previous comment so that guy must be right.

<comment><USER17> so why cant we start down voting with less karma, as opposed to now it being 500. so more people could counteract your issue. AND i think that if a comment has more upvotes, then they DID win the argument and that should be seen that they won.

<comment><USER16> I think you're missing the point. Logic wins arguments not upvotes.

<comment><USER18> Yes, logic wins arguments, but to continue with metaphors, I'm sure you have heard of the halting problem. Without upvotes, the thread will go on forever. Vote counts allows for closure. So threads are shorter and I'm happy to extract more information faster.

</comment></comment></comment></comment><comment><USER19> The most important aspect of the comment scores was that they let me know what the HN community thought of a particular point or argument. I'm capable of making up my own mind about any topic. I find it interesting and useful to see what other people think. As a geek I miss being able to see that "people agreed with this side of the argument at +20 as opposed to that side at +10".

If some people want to treat it as a "who can get more points" game, then so be it. I find that I can learn a lot from looking at which way public opinion is leaning.

<comment><USER20> |The most important aspect of the comment scores was that they let me know what the HN community thought of a particular point or argument. I'm capable of making up my own mind about any topic. I find it interesting and useful to see what other people think

That seems like cognitive dissonance to me and a rationalization. If you truly make up your own mind about something then why would you care so granularly about how much/little HN likes a comment. The ordering of the comments allows you to know where the comments all compare, so I don't see what you're really missing other than the exactness.

<comment><USER21> Why care? Because up votes are also coming from the community and I believe we are all here because we respect the opinions of the people here.

Also, comments sort within threads. Sometimes the best reply is to a no-so- great parent comment.

<comment><USER20> |I believe we are all here because we respect the opinions of the people here.

What does that even mean? That by not showing the comments we're somehow disrespecting those opinions?

|Sometimes the best reply is to a no-so-great parent comment.

And even then those replies are sorted again... what is your concern? Time? If you were saying hey, I only have so much time, I could maybe understand. But... I think it would be better for HN as a community to train people for more thought out discussions, fewer flame wars, and more of a focus on actually reading the comments and evaluating them based on their own content and not just on what others have said.

As someone in this thread also pointed out, it also ends the perception that an argument can be won by popularity or upvotes-- I believe this has been especially beneficial at preventing/reducing typical fan-boy flaming. I think HN has already begun to benefit for the changes. Also, I would rather read fewer threads with _better_ comments, than more threads with worse comments.

Note: _Better_ subjectively being defined as more thought out, less antagonistic, more discussion based, more logic, and more citations/sources.

<comment><USER21> | What does that even mean? That by not showing the comments we're somehow disrespecting those opinions?

What I was trying to say is that I value the votes of the community. The culture at HN is that "+1" type comments are noise, but 73 upvotes gives me an indication that the comment resonates with this community (whose collective opinion means alot to me).

</comment></comment></comment></comment></comment><comment><USER22> I found the comment scores a good motivation for thinking about what I'm typing before hitting that 'add comment' button. Good imperative to participate instead of troll.

The opposite is true for others, I'm sure.

<comment><USER23> Adding +1, since you can't tell if the parent comment has been upvoted.

EDIT: this -> parent comment

<comment><USER24> The author of a comment can tell if it's been upvoted - no one else. I really wouldn't like to see comment threads full of posts similar to yours; it lowers the signal:noise.

<comment><USER23> Obviously it would be terrible if everyone posted 'I agree' comments, that's the point. Numbers show the viewers sentiment towards a comment without clogging the thread.

<comment><USER25> It is self-evidently true that removing visible comment scores mostly removes methods for trivially measuring "viewer sentiment". It is the contention of those in support of non-visible comment scores that trivial measurement of viewer sentiment harms, rather than aids, discussion. You have made no argument against that point.

<comment><USER23> Trying to aid discussion by limiting information is fine, unless you happen to want that information.

</comment></comment></comment></comment></comment></comment><comment><USER26> I don't usually want to post, "me too" posts but...

I really miss the comment scores.

Sometimes I am not totally familiar with whatever the original post is talking about, often the top rated couple of comments give me some good insight or jumping off points to look into it further.

I respect the HN community and have learned a lot here. I generally trust their judgement and I have found if a comment is rated highly, it most likely adds a lot of value to the discussion.

Sometimes I disagree with the highest rated comment(s). I then see my opinion is in a minority and maybe I re-examine it or stand firm and make a comment to the contrary.

</comment><comment><USER27> Without the comment scores we're confronted with a wall of text that is hard to filter. Should I have to read every single comment just to find the gems? Comments scores have their downsides but they make filtering out noise much easier.

Unfortunately I don't think everyone has time to judge each comment on its own merits -- there are simply too many comments -- so we need a little crowd- sourced ranking. It does lead to some group think at times but that's a (relatively) small price to pay.

<comment><USER5> In my experience, "wall of text" and "TL;DR" began as terms used by those generally uncomfortable with literacy or focused attention.

Skimming is a valuable skill, becoming even more important as the world generates information ever faster.

<comment><USER27> How about just having a finite amount of time in which to read the news?

I'd prefer to focus on attention on filtered comments rather than waste time skimming hundreds of comments.

<comment><USER5> Focus on "filtered" comments is a completely different discussion, and offering users an unnumbered slider to set personal threshold for where the grey vs black text divider falls on a percentile line between top and bottom scored remarks of the given thread, would accomplish 90% of what the TL;DR crowd want w/o all the problems of showing scores.

<comment><USER27> It's not really a different discussions if you viewed scored comments as filtered comments.

</comment></comment></comment></comment></comment><comment><USER28> Cant we have a "showcommentscores" option for displaying comment scores? Personally, I really ( _really_ ) miss seeing comment scores, but its apparent that there are a lot of people who like HN the other way.

<comment><USER29> The problem is that part of what we like about not displaying the comment scores is the effect it has on other people's behavior. Letting others opt in to seeing the scores would defeat a large part of the purpose.

<comment><USER30> > The problem is that part of what _you_ like about not displaying the comment > scores is the _apparent_ effect it has on other people's behavior.

That, I believe is more correct. I miss the scores, personally, and found them rather useful.

</comment></comment></comment><comment><USER31> Previously, I used to read the comments first and then the article. Now I'm reading the article first and ignoring the comments/vote.

</comment><comment><USER32> I think that people are missing the point. A comment's quality is not measurable by it's score. If anything, that is a rough aggregation. By this logic, Ke$ha is a better musician than Joshua Bell.

Top comments on HN were becoming more "top 40" and something had to be done before people started posting links to Trollface, etc.

One approach would be to use category-based voting, which adds a lot of complexity.

One approach would be to implement some sort of vote weighting sytem (time based, reputation based, context based), but that's ad-hoc and may not fix the problem.

And one approach is to simply hide numerical comment scores from all but each user's own comments. This turns the quest for high karma into a personal battle against one's self, not a sport.

PG wisely chose to make Karma a personal Everest for each individual to care about (or not).

</comment><comment><USER33> FWIW, I find myself up/down-voting less without the scores. I guess I mostly tend to vote to rectify imbalances. If a comment has a lot of upvotes already, I probably won't upvote (I figure once it's near the top, it doesn't matter much anyway). But if its popularity seems unwarranted, I may be more likely to downvote.

Conversely, I tend to upvote mostly what appear to be underrated comments that are low on karma. Not saying there's anything admirable about this approach -- what am I, some kind of Karma Robin Hood? -- but the new system definitely discourages it.

</comment><comment><USER34> Another thing (and some might accuse me of "doing it wrong" this way) is that lack of score showing changes my motivation for voting overall.

Some comments are so awesome, they deserve 50+ upvotes. Other comments are pretty good, and deserve maybe 8. I do not/did not personally try to upvote every single comment. I try to add upvotes to the comments that seem "best" in a particular thread discussion, and allocate votes in this way.

Perhaps my behavior is something that pg was attempting to fix with this change, but I have a feeling I'm not alone in this regard.

</comment><comment><USER35> Since I registered a username here on HN 890 days ago, I've seen a lot of comments about comment karma and about upvoting and downvoting. The most significant statement I have seen about comment voting here on HN was posted recently by pg, the founder of HN, in a thread-opening post 22 days ago titled "Ask HN: How to stave off decline of HN?"

<http://news.ycombinator.com/item?id=2403696>

He wrote, "The problem has several components: comments that are (a) mean and/or (b) dumb that (c) get massively upvoted."

So the founder of HN thinks that before the recent experiment there was a comment voting problem: (a) mean comments were getting too many upvotes, and (b) dumb comments were getting too many upvotes, and (c) too many of the comments that got the most upvotes were either mean or dumb or both. Let's stop and think about what that means. That means that, according to pg posting as of that moment, comment karma scores were often NOT reliable signals of good comments, comments worth finding rapidly when skimming a thread.

With that condition of HN less than a month ago in mind, how do the highest- voted comments visible in the bestcomments list

<http://news.ycombinator.com/bestcomments>

look to all of you recently? Are there fewer mean comments than before? Are there fewer dumb comments than before? Are the comments that are "massively upvoted" since the experiment began mostly comments that are reasonably kind and well-informed, helpful comments on the whole? In most of the treads you visit, do helpful, thoughtful comments seem to rise to a position of prominence, while mean or dumb comments gray out?

A link and comment in another recent metadiscussion thread largely sums up the back-and-forth about visible comment scores as a signal on comments in active threads:

<http://news.ycombinator.com/item?id=2465357>

>> Please bring back the comment scores. It helps a lot in parsing the comments and assigning a proportional weight to each when reading them.

> I had to think about this a bit, and I disagree so far. I'm finding that I'm > not pre-judging comments as much. It's nice to be able to read someone's > comment without knowing first that 70 or 80 or 3 other people thought it was > worthwhile.

My impression too is that even with comment scores not visible, it is still convenient to browse threads to find thoughtful, informative comments, but now there is less anchoring bias

<http://www.sciencedaily.com/articles/a/anchoring.htm>

of most votes on a comment converging to one score level that shows up early in a thread's development, and more engagement by readers of HN in actively reading comments and upvoting (or downvoting) based on each comment's characteristics in light of the context of the thread. So far I can still find good comments quite readily here on HN. Indeed, I think that since the experiment began I am seeing more good comments more readily than before.

The main motivation stated by pg for the current experiment with making comment karma scores less visible is to "stave off decline of HN," and that is what will decide if the experiment was successful. If the previous visibility of comment karma scores led too many casual readers of HN to upvote mean or dumb comments, and too few readers to upvote thoughtful, informative comments and to downvote mean or dumb comments, the arguments on the side of reader convenience aren't going to be convincing. It isn't convenient for ANY reader of HN if the comment scores are a poor signal, and if bad comments become more prominent and good comments get skimmed right over by readers in a hurry. If a change of rules here makes every reader read comments more carefully and more thoughtfully, and vote based on comment inherent quality rather than on crowd appeal, that is a feature rather than a bug. For comment scores to be a good guide to every reader here, every reader can help by actively upvoting informative, helpful comments, and also by downvoting comments that are either mean or dumb--and especially comments that are both. As I recall, the experiment has also involved some changes in the effects of flagging, so flagging inappropriate comments is also helpful.

After edit: many comments in this thread ask about the karma rules and voting rules imposed by the software. We can all read the news.arc software ourselves

<https://github.com/nex3/arc/blob/master/news.arc>

if we would like to see what the rules do (except I think that maybe a few aspects of the current experiment are hidden from the current distribution of the source code), as previous HN threads have pointed out.

<http://news.ycombinator.com/item?id=1307128>

<http://news.ycombinator.com/item?id=2034449>

<comment><USER2> One of the big assumptions that's being made here is that people are dumb calculators.

I can tell the difference between a stupid comment that got a lot of points for being stupid, and a useful comment that got a lot of points for being useful.

When I look at amazon and see that twilight has 3000 5 star ratings, I don't assume this means it's a great piece of literature, but it _is_ useful information to me: it's a popular book.

Same goes for comments.

I'm not stupid, I can tell the difference between "popular because it's funny/pandering" and "popular because it's useful"

<comment><USER35> _I'm not stupid, I can tell the difference between "popular because it's funny/pandering" and "popular because it's useful"_

Let me make sure I understand correctly what you mean in light of what pg said about the reasons for the current experiment (quoted in my post to which you reply). Is it simply a mistake to say that high comment scores on comments that are mean or dumb is a problem? I ask, because pg has said that there has been a recent problem with comment scores.

 _One of the big assumptions that's being made here is that people are dumb calculators._

I think that there is a huge body of research showing that all human beings, without exception, high-IQ or low-IQ, are "cognitive misers"

<http://www.psychwiki.com/wiki/Cognitive_Miser>

[http://blogs.discovermagazine.com/cosmicvariance/2009/11/04/...](http://blogs.discovermagazine.com/cosmicvariance/2009/11/04/are- you-a-cognitive-miser/)

(there is a good self-test at the link above)

[http://lesswrong.com/lw/2ey/a_taxonomy_of_bias_the_cognitive...](http://lesswrong.com/lw/2ey/a_taxonomy_of_bias_the_cognitive_miser/)

in the sense of preferring less effort-demanding problem-solving techniques to more accurate, but more effort-demanding, techniques. Snap judgments spare mental effort for everything else that we are busy with.

Here on HN, the only thing most participants contribute to the community is good comments and good submissions and votes about other participants' submissions and comments. A few founders, pg and his core of curators (editors),

<http://ycombinator.com/newsfaq.html>

do actual work to keep the site running, and they get the best compensation for their volunteer efforts if all the signals about story quality and comment quality are true, thoughtful signals rather than noise.

</comment></comment></comment><comment><USER34> One of the things I liked about the Slashdot comment system was that you assigned a rating "Insightful" "Funny" "Helpful", etc.

</comment><comment><USER36> Removal of the comment scores is a great innovation that has improved the quality of Hacker News.

With scores visible, most "discussions" end up as little more than opinion polls.

</comment><comment><USER37> Seeing comment scores helps me to quickly scan comments to find the ones of most interest. It's not about "who's right" or "who's wrong" --- but what comments are more insightful and interesting. This is what the community of HN provides in voting people's comments up and down. This concept is missing now.

All in all, not showing comment points is a step backwards in helping people get the most out of the site in the most efficient way possible.

</comment><comment><USER38> I understand the minimalist theme at HN, but would a simple toggle switch to show/hide comment scores be a terribly bad idea? These could be set by logged in users (wouldn't apply to drive-by or anon users).

</comment><comment><USER39> Please do.

But also, please split upvotes from downvotes. There's a huge difference between a +25 / - 24 comment (apparently a controversial one) and +1 / -0 (probably a mediocre one).

Or perhaps, display only upvotes, and use some weighted form of (UPVOTE * U_WEIGHT - DOWNVOTE * D_WEIGHT) for positioning the comment among other ones.

</comment><comment><USER40> Removing comment scores seems to have increased the amount of mediocre/poor comments around contested topics: I am noticing more more brother/sister comments that are basically reiterating each other and more debates that veer to uncontrollable levels of indentation when the key points were already covered in the top level post and first child.

The relative absence of these black holes of discussion is one of the things that brought me to HN in the first place, and I think that showing comment scores discouraged them on multiple levels. Public upvoting lets people express their view on the topic without posting points similar to those already expressed. When two comments have a lopsided point spread it lets one "side" of the debate feel more comfortable letting the other have the last word.

</comment><comment><USER41> Ah, no, don't. Stop fixating on the score and trying to write comments that other people like instead of writing what you actually have to say.

</comment><comment><USER3> How about allocating a 'hotness' quotient to comments?

At the moment, a comment that's down-voted past zero becomes lighter. Perhaps very popular comments could be made more visible, or highlighted?

I think this kind of _fuzzy_ indication of popularity might be a good compromise.

<comment><USER42> I agree. One of the more useful things I used comment scores for was to be sure to avoid missing useful comments that were down low on the page. Having a mechanism for setting apart well-regarded comments would be useful.

It would likely have to be normalized based on the score of the submission or the total number of comments on that submission, though, which might be more complexity than pg wants.

</comment></comment><comment><USER30> No one on this thread has picked up on the 'range' suggestion by Maro yet, so I'll add a thought:

For my purposes, displaying actual scores within the range -4 -> 10 would be sufficient. the low end is already capped, and the high end could either just have a ceiling of 10 or a score of 10+.

I am occasionally a "someone is Wrong on the internet!"[1] type and my inclination to wade in is directly proportioanl to the perceived traction of the inaccuracy. Without such a heuristic the choices are: reply to all, none, or a random sample which result in "poor information", "needless pedantry", and " undefined behavior" respectively.

[1] <http://xkcd.com/386/>

</comment><comment><USER43> Disagree. I believe that I can make a fair judgement of the quality of a comment by simply reading it. I don't do TL;DR on comments that I care about, so using scores as a proxy for quality doesn't mean much for me.

</comment><comment><USER44> Hidden comment scores help us avoid groupthink.

<comment><AUTHOR> But make it harder to filter information. I feel safe from groupthink, hence the post.

<comment><USER44> Definitely agree on that as well - it's a pros and cons argument. Frankly I miss the scoring for the reason you mention, but I think this method promotes merit. Of course, now we are all subjected to whatever secret algorithm pushes comments to the top of the page, but I'll naively trust that it's doing its job properly ;-)

</comment></comment></comment><comment><USER45> I have been quite surprised at how my enthusiasm for contributing to Hacker News has diminished at the removal of comment scores. Not necessarily a bad thing for anyone.

</comment><comment><USER46> By removing comment scores, does it increase/decrease traffic to HN?

My gut is telling me that traffic is likely to be lower. Reality might be different of course.

</comment><comment><USER47> The only issue I see with not being able to see the scores of comments is that joke or off-the-cuff comments are probably getting a lot more points.

If there was a comment that made me laugh (while sticking to the point) I will be more likely to upvote it, but if it already had 10+ upvotes a laugh on my part probably didn't justify another upvote.

</comment><comment><USER48> I really miss comment points on book recommendations. I can't tell you how many books ive purchased over the years based on a highly rated HN comment.

I second what others have mentioned that it would be good to re-display comment scores on older posts. This way we could at least see the community consensus after some time has passed.

</comment><comment><USER49> I like the lack of comment scores (to avoid everyone piling on one comment), but I think I would like it more if I knew what went into how high a comment was on the page. Is it a fact that the first displayed comment will be the one with the highest score? I know some different inputs are used, such as the karma of the submitter, how new it is, etc. but I guess we don't know "for sure".

I don't think the solution is to bring back scores, though. A possible "simple" solution could be to color/star a comment above 50/100 points, etc. Comment scores could also be displayed as percentage or on a scale of 0 to 1, 0 to 10, etc. I'd be more likely to read a comment with a score of 95% than one with a score of 20%. This way you at least get an indication of the helpfulness of the comment other than just its position on the page.

<comment> T-hawk > I'd be more likely to read a comment with a score of 95% than one with a > score of 20%.

Seconding this idea, I really love it. The biggest problem with a linear point count is the large dependency on a comment's visibility and number of impressions, which in turn leaves posters competing for that as much as for inherent comment quality. The implementation would be up for discussion, maybe something like show a comment's positive percentage once it garners a sample size of 5 or 10 votes, and maybe round off to the nearest 10% so you can't triangulate back to the actual score from the change inflicted by your single vote.

</comment></comment><comment><USER50> I think a middle ground would be good. I understand the reasons for dropping comments scores but it makes it harder for me to get a quality experience out of the site and easily find the information I need. The scores mean something to me.

I liked someone's suggestion of basing the comment score on "upvotes per view" so older comments don't dominate, and I also like the idea of using a dark-to- light gradient (dot) instead of a concrete number.

Just sorting to the top (kinda) really just makes it hard to wade in, and makes me less likely to take a look at a topic I know little about and would like to see a couple of definitive words on it. It may be groupthink to some extent but this is a damn smart group.

</comment><comment><USER51> Remove scores/points for people entirely.

That way only posts/comments get points/scores, not people.

</comment><comment><USER52> I'd prefer a system that reveals the score of comments you've already either replied to, or voted on. Gives you some kind of feedback on where the rest of the community's mind is with regard to that comment.

</comment><comment><USER53> One observation: I think that comment ordering is an inadequate substitute for numerical scores. A lot of interesting information goes missing when reducing a scale from interval to ordinal.

</comment><comment><USER54> My initial reaction was also "just bring em back".

With reflection, I think a good idea might be to show the score _after_ you vote.

This way you get the feeling of making some difference i.e. immediate feedback, but also the knowledge that your vote wasn't subconsciously affected by a visible score beforehand.

The main downside of this would be people voting out of curiosity to see what a comments current score is. Perhaps displaying the score of a comment once it reaches a certain age (maybe three or four days old) would mitigate against this.

<comment><USER55> [...people voting out of curiosity...]

If voting reveals the score, then there would need to be a new way to abstain and reveal the score.

<comment><USER56> Why? If you feel positively or negatively towards a comment, then vote thusly. Abstaining to reveal the score is far too easily gamed with a secondary account.

</comment></comment></comment><comment><USER57> With the comment score not being displayed, I find myself commenting less often for some reason. Others have echoed a similar sentiment in some of the earlier threads.

</comment><comment><USER58> I found it particularly hard to read the recent Amazon Outage thread. There was so much information to sift through. It had me missing the comment scores.

</comment><comment><USER59> I'm not going to read all the comments when they're more than 50. Finding insightful comments is hard without any number next to them. But I understand that it might bring more karma to "stupid comments" instead of "really insightful comments"... but who cares, the insightful comments is still there and probably going to get more karma than it would without any number next to it.

</comment><comment><USER60> Ok I just had another idea, so thought to write it here, in case PG gives it a look. How about showing votes after you took an action on a particular post. Say you upvoted a post, or replied to it, then you are eligible to seeing the points that it has.

This helps because even if in hindsight, I would know if the comment was the general consensus or a popular one or not?

</comment><comment><USER61> I would like it if the comment rating was only available in an html data attribute (eg data-rating="10"). That way my old user script would still be able to sort and high light comments.

You would have to go out of your way to see the score but could still be used by us hackers who like to customize our experience.

</comment><comment><USER62> I wonder if showing the rating of a comment only after you had voted on it would work? That would prevent some level of groupthink by forcing people make their own evaluations before seeing what others thought. That would require a +0 vote option, though, to prevent some obvious failure modes.

</comment><comment><USER63> Ignorance is bliss. I'm happier not knowing that the crowd disagrees with my judgment of a comment's worth.

I also feel like people are avoiding posting crappy comments with the intent of tapping into a popular vein for a high score.

This could be a placebo, or perhaps, if real, it's instead caused by an improvement in voting.

</comment><comment><USER64> Comment scores help me get to the best points (even if they are in disagreement) without spending a lot of time reading the whole page.

I'm reading a lot let now because there are no scores; I just skim the top and then move on.

Comment scoring allows the community to reveal quality.

</comment><comment><USER65> I wonder how Hacker Monthly (<http://hackermonthly.com/>) will pick out the "best" comments.

<comment><USER66> Supposedly via <http://news.ycombinator.com/bestcomments> I don't think that upvote count alone determines which are to be picked, but I could be mistaken.

</comment></comment><comment><USER67> It's interesting to see an 8 hours post that has 374 points, and 156 comments on the second page instead of being on the first page.

</comment><comment><USER68> I didn't even notice they were gone at first...

</comment><comment><USER69> Button to make comment scores visible, please.

</comment><comment><USER70> I much prefer it without. I like it like this

</comment><comment><USER71> I would make it an option.

</comment><comment><USER72> No middle ground. Please bring exact score number.

</comment><comment><USER73> <http://hackerne.ws/item?id=2477527>

My comment here explaining it has made me comment less has 40 points. I think a lot of people agree.

<comment><USER74> It's interesting because (although I can't explain why) it actually freed me to post more comments, and I have far lower karma (and avg/post).

So the system could lead to more posts by undesirables (me) and fewer posts by those with more knowledge (you).

</comment></comment><comment><USER20> I disagree. It forces people to read the comments and judge them on their own merit. Often times the highest voted comment seemed to be highest voted comment simply because it was the first comment and kept being upvoted for being upvoted by others.

Also, the ordering of the comments does the same thing as having the comment scores!

I do wish there was a way to still search for the highest rated comments on searchyc.com, but I still think it's a small sacrifice for an overall better community/environment. I have definitely seen less iOS/Android/Windows flaming, so I think the site is already benefitting from the changes.

<comment><USER18> _It forces people to read the comments and judge them on their own merit_

I understand your argument. Just keep in mind that there are multiple ways that HN is useful. Some of us want to go deep into a topic, will read all the comments. And some of us are in a hurry and want to a quick feel and extract a summary.

In the first case (I call it "researcher mode"), not having votes is a good thing. But it prevents me from browsing in the second mode (the "quick update mode").

I wish you could set this in my preferences, but it wouldn't fulfill pg's original goal of staving the decline of HN (that I don't see - but that's another discussion).

</comment></comment><comment><USER75> When i am interested in the subject, i usually read ALL comments. Having them in order of popularity helps, but does not really discourage me from reading on. Scores don't really matter.

There is a tendency for short comments to sink down, regardless of how informative they are, simply because people spend less time on them, so they're less likely to hit that upvote button.

Also, like all forums, the first upvoted comments get more replies creating a positive feedback loop, not necesarily because they are the best, but because people know their replies will be more visible.

It would be interesting to have the statistics of number of upvotes vs position of the comment in the page.

</comment><comment><USER76> +</comment>


How it feels to learn JavaScript in 2016 - <AUTHOR> https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.l8ak5j3gz <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=12628921](https://news.ycombinator.com/item?id=12628921) (19 hours ago, 108 comments)

</comment><comment><USER3> In my experience, the developers who fall into this trap of despair almost always do so because they aren't consciously choosing what tools to use; instead they are letting the tools choose them.

They see job descriptions demanding AngularJS or ReactJS and they think that they must learn it, or someone posts an article here and they don't want to feel left behind.

Choose a library or tool because it improves your development process. If it doesn't appear to improve it, don't use it (at least not unless external forces compel you to). Especially don't use it if it appears that it will retard your performance ( _cough_ Angular _cough_ ).

For example, after months (years?) of finding ever more efficient ways of enforcing object interfaces (or even basic types) at runtime, I eventually reached the limits of what JS and unit testing alone could acomplish and found myself researching Typescript, Flow, and the like.

That's not to say I'm a user of either of those, but if I do choose to adopt one in a project, I will know exactly what performance gain I am expecting from it. I'm still very productive without them.

In fact, I've successfully avoided a lot of fads in the industry for most of my career. It turns out that being able to explain why I _don 't_ use a tool makes me look like I know what I'm talking about and not just cargo culting. Employers quite like that.

Incidentally, this isn't unique to the front-end. I've seen the same thing happen with the SQL->ORM->Mongo->Couch->SQL nonsense, or the myriad of templating engines written for PHP, a language that itself _is_ a templating engine.

<comment><USER4> How would you suggest developers actually figure out what tools to use? It is next to impossible to make an informed decision without digesting a good portion of what the OP is talking about. You need to start somewhere.

<comment><USER5> Where the OP falls off is with stuff like "OMG don't use jQuery" or "no one uses HTML anymore". There's nothing wrong with using those -- and frankly using plain old javascript and HTML is fine. Remember we reached for jQuery in the first place because the browser lacked features we wanted, and because it handled cross browser stuff for us. That is, it simplified things _we were already doing manually_. So the trap is bad advice like "use these 58 libraries" combined with an inexperienced person making the architecture choices. I'd say instead (if you're the inexperienced person) just start building stuff. Then every time you said "this is repetitive, I wish there was a library that did this for me" \-- there will be. Go out and get it, and you'll then understand why it exists.

<comment><USER6> I've been to more than one interview where I defaulted to jQuery and was immediately disqualified, based on the looks on the interviewers' faces. As a ruby developer, it certainly feels like keeping up-to-date on JS takes more work than the other 90% of languages that I'm familiar with.

<comment> lloyd-christmas Interview question: "iterate over an array":

      angular.forEach([1,2,3] ...

      $.each([ 1, 2, 3 ], ...

      [1,2,3].forEach(...

One of these things is not like the other. I hire people that know javascript, not ones that only know the tool we use. The tool we use today may not be the tool we use 6 months from now. I've never asked a javascript question that required framework knowledge unless it was explicitly about concepts of the framework. Someone taking the time to include jQuery is instantly out the door. Walking through people's code demonstrates whether or not they default to other people's solutions than their own.

This isn't to say your experience didn't happen, I'm just pointing out that there is a lot more that goes into it than just which framework the cool kids are using nowadays.

<comment><USER3> I have to say, this strikes me as an odd way of filtering out bad developers. jQuery is a time-saving library.

It seems like you're presuming that they must lack proficiency in the DOM if they're choosing to use jQuery. Perhaps you're trying to say you want to see them demonstrate that they're not just copy/paste coders.

Given your code example above, I wouldn't want a candidate to know the difference between each `forEach` method, but I would expect them to know that each provides a means of iterating over a set of values.

<comment> lloyd-christmas > I have to say, this strikes me as an odd way of filtering out bad > developers.

I don't use this in my interviews, and I'm surprised everyone took this literally given that we have a weekly blog article about the villainy of technical interviews and how they destroy the very fabric of software development. I'm using a hyperbolic example to demonstrate what I perceive as a negative trait; A reach for unnecessary tooling to solve simple problems. My hiring experiences have pointed towards it being indicative of a comfortable one-trick-pony.

> Given your code example above, I wouldn't want a candidate to know the > difference between each `forEach` method, but I would expect them to know > that each provides a means of iterating over a set of values.

Likewise. However, if I'm hiring someone for a back end role, I'd expect them to be able to know basic SQL and not just their language's ORM. I'd expect them to be able to type `cd` and not just navigate through their IDE. I don't think there is anything different between that and the relationship of jQuery/angular and vanilla js. jQuery isn't written in jQuery. Debugging rarely stops at the script tag/require statement.

<comment><USER6> My original comment was actually in the opposite direction: the interviewers were looking for comfort with a framework other than jQuery that showed that I knew more than vanilla JS. That was the frustrating part.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I'm a web dev, been doing this 11 years. But i totally feel past it, granted i code less and less nowadays so i havent kept up with new technologies.

I've hired people that are much better at web dev than me and let them accomplish a task with pretty much whatever tech they want to use, because i believe you shouldn't constrict a developer if you dont have to. Even for a simple app that it'd take me 20 - 30 hours for me to create in basic jQuery, bootstrap and simple PHP/MySQL, the tendency is to pull in Angular, Laravel, gulp or grunt, composer dependencies and a whole host of code for doing something really simple. It ends up becoming a frigging nightmare to maintain and deploy, i just want to do a git pull and thats it deployed, but instead i've gotta do artisan commands, migrations, grunt commands etc etc etc.

Anyway, i tell myself that what their doing is a better way of doing things and i'm just someone with outdated knowledge, because when i do it, i use basic tech and accomplish the same task in less time and with WAAAY less lines of code. While its maybe not the best practices, its simple.

I still feel like a bad coder because i'm not doing it their way. :(

<comment><USER8> _Even for a simple app that it 'd take me 20 - 30 hours_

If your entire job is doing small apps that take a week of work, these tools are not much better than the previous generation (personally I'd use Rails but that's just one generation on from PHP/MySQL). Especially when you add in the cost of non uniformity if you let everyone choose their own slightly different flavour of the innumerable javascript tools available.

But as part of a team that has migrated a 5 year old codebase from Rails to React in the last year, whilst I was skeptical at first, React has been an absolute godsend. Everything we build now is so much more modular and much closer to how non tech people view our website (and so how they ask for features), which makes it easier to develop. React isn't designed to help "I need to build this 20 hour website quicker".

I think the problem is mostly cargo culting. Smart and outspoken developers use these tools, but they're also the ones dealing with complex problems at their jobs, not everybody needs to solve the problems they are solving. And "Honestly Rails is good enough for this app" doesn't make for a very sexy meetup presentation.

<comment><USER9> Sorry, I'm confused: what do you mean by "migrated a 5 year old codebase from Rails to React"? What are you using as your backend?

<comment><USER10> Just one of the many ways that modern Javascript baffles me - people pretend the client and server are equivalent.

<comment><USER8> The more technical details you include the more people pick up and discuss minute technical details instead of the point of what I was trying to say, which is that my experience with a large codebase was these modern javascript tools have solved a lot of problems we had.

If you want all the gory details here they are: it was a Rails 3 app using Postgres and Elasticsearch that we migrated to React + node.js + webpack + babel, elastic search as the data store and using Keystone.js for backend data manipulation (which uses mongodb). Rails was indexing its data in Elasticsearch already so we could start serving data through node.js immediately without having to migrate all the data backend, which is being slowly moved to keystone.js.

</comment></comment></comment></comment></comment><comment><USER11> It's easy to show how complex those systems are. It's easy because they _are_ complex. And that's pretty normal. Let someone talk about Java Enterprise development, the symptoms of your body and their diagnoses or just try to explain how to build a pencil ([https://en.wikisource.org/wiki/I,_Pencil](https://en.wikisource.org/wiki/I,_Pencil)).

We're professionals, after all, and TypeScript and React were not build by some teenage hackers.

I think the problem is that everybody remembers how they build that one website using jQuery in the early 2000s and now wonders why everything's so complex now. The reason is that we started to build complex applications instead of enhancing grandma's blog using jQuery.animate, get over it.

And if a software developer talks about all of this tools in the same manner you've described, he has poor social skills, nothing related to the tooling.

He could also talk about the intricacies of scaling web services using k8s and OpenStack and you'll find another bunch of tools and concepts. If someone would actually talk like you've described it, he would play buzzword bingo in any domain of expertise like medicine students who want to sound smart using latin words.

<comment><USER12> > We're professionals, after all, and TypeScript and React were not build by > some teenage hackers.

Overall correct

> The reason is that we started to build complex applications instead of > enhancing grandma's blog using jQuery.animate, get over it.

And this is where we disagree

Complexity is needed sometimes, needless complexity only brings the overall value down

If I want to do a website using Django I need to get: Django. Period.

I may need some other libraries, but they're much fewer than any basic node.js project, even with things like Flask

I have one package manager: pip. It works

With express.js you need a library to _parse an HTTP request body_ ffs. [https://github.com/expressjs/body-parser](https://github.com/expressjs/body- parser)

<comment><USER13> > I have one package manager: pip. It works

Funny, because this is not the general sentiment in the Python community. See links like [1], [2], [3]. Thankfully, things are improving.

[1] [http://lucumr.pocoo.org/2012/6/22/hate-hate-hate- everywhere/](http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/)

[2] [https://www.reddit.com/r/Python/comments/zrm3h/there_have_be...](https://www.reddit.com/r/Python/comments/zrm3h/there_have_been_a_string_of_posts_on_packaging/)

[3] [https://blog.ionelmc.ro/2015/02/24/the-problem-with- packagin...](https://blog.ionelmc.ro/2015/02/24/the-problem-with-packaging-in- python/)

<comment><USER14> I found Python packaging very easy. pip install works for tons of packages.

</comment></comment></comment></comment><comment><USER15> Thank god we have all these libraries. I mean remember the days when the back button worked, pages rendered quickly without 3-second ajax spinning animations, the browser remembered where you were when you clicked back, your phone didn't randomly jump around the page when you're trying to read something, and a syntactical fuckup didn't prevent your entire site from being rendered? Oh, and you could scroll normally too. And crawlers other than Google could index your content, and blind people could listen to it. But right, javascript is awesome, I probably just don't understand enough yet.

</comment><comment><USER16> I feel like knowing which tools are useful, which ones are currently dominating, and which ones are going to continue being supported in the future is the best place to start learning JavaScript. This is difficult because the ecosystem is so wildly fragmented and insane. You'll get a lot of different opinions if you go searching for them, so here are mine.

ES2015 is the place to start, it is a finished stable release of the latest version of JavaScript. It represents the single largest update to the language in a long time and includes many features that make development easier. It is being phased into web browsers natively and is the future of the language.

For maximum browser support you need a transpiler, this would be a matter of preference because it isn't for you, it's for the computer. TypeScript however is a very very clean transpiler and it offers optional features which are for you, should you choose to use them.

Once you have that setup, you really don't need anything else. You don't need jQuery unless you're trying to support IE8, which is a tiny proportion of the browser market and that will gum up your code significantly.

Speaking of gumming up your code, nearly every single library out there is bloat and can or should be avoided. React is very popular but it suits one very specific use case, it should be used almost nowhere else. Particularly since it is still new and evolving, it is going to cause more headaches than it will resolve. Webpack is an enormous bloated nightmare for example, it messes with even static html for little or no perceivable benefit and honestly just avoid all of it if you're trying to learn JavaScript.

If you want the full-stack experience, Node.js is rapidly becoming the largest JavaScript community on the net. You'll have your questions answered quickly and there are modules for everything you want to do. Choose a markup tool for html and css, such as pug and less.

There you go. State of the art front end JavaScript with two tools. Full stack with five. If it wasn't for the whirlwind massive chaos of the JavaScript community currently, fewer new developers would feel discouraged from becoming involved.

<comment><USER17> > React is very popular but it suits one very specific use case, it should be > used almost nowhere else.

Which use case?

I've never worked with React but from yesterday's stateofjs.com I got the impression it's currently the go-to framework for everything.

<comment><USER16> It gives you components. If your webpage is loaded and significantly complex with a need for different things all over the place then it's for you. It was built for Facebook, which has stuff everywhere on every page.

If all you want is a normal webpage, like a blog, like all of the websites out there I'd say you do not need components. Just build your own object. That is a lot of stuff just to do something that has been done for decades without it, battle tested so to say. Another one of the problems with the JavaScript community currently is the number of people who treat their favourite tool like a religious experience.

React is a large hammer being used quite often to close a twist tie. The ecosystem of tools which have sprung up around it is far worse than React itself. Each one a larger amount of overkill than the last.

<comment><USER18> I'm sorry, but once you feel comfortable using React there are very few things that React would not be a good fit for, however small the task.

I started coding in JavaScript two years ago, right at the point React was gaining popularity. I made a gamble going for it 100%, and since then both the company I was working at back then and the one I started working at recently have fully switched to React for all new front-end development after seeing how much easier it is than anything they'd ever used before (jQuery, self- rolled prototype-based things, Backbone, Angular 1, Ember).

Yes, sure, you have to get the basics set up every time, and yes, sure you have to package React on every page. But as a gigantic win, you get a uniform way of dealing with the DOM every single time. React has well-defined best practices by now. When every Javascript coder in your workplace is familiar with React, it's usually best for you and for them to simply continue coding in React.

<comment><USER16> I feel that you are marginalising the amount of complexity you are adding to projects which might not need it. There are multiple routes toward completing the same task in development. My concerns surrounding additional complexity I feel are well founded, there are costs associated with such a thing.

If all you are doing is DOM manipulation, without doing a huge amount of it, that isn't such a complex task that it should require an entire framework. If you're doing more than that it outscopes what React can do.

<comment><USER18> That's just it. If all your developers are familiar with at least the basics of React and Webpack, you aren't adding any complexity. Once you know how things work, a simple Webpack configuration with Babel and 2 presets isn't complex anymore.

What would be complex, however, is introducing DOM logic in yet another way. We're all used how you just define the desired state in React and letting it figure out the transitions. When you suddenly ask your developers to write code that manually manipulates the DOM and has to take care of all the transitions between states, you end up with complex, unclear code that takes everyone a long time to understand.

<comment><USER16> Webpack alone requires hundreds of dependencies. You are populating your node_modules directory with megabytes of code, any of which could stop working. If you plan to maintain your code for years into infinity then it's no problem. Otherwise the shop down the street doing the same thing without it will be much better off.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I have no trouble at all "keeping up" with the "insanity" that is front-end development. If you're confused learning new things, it means you're learning.

At my company, we have moved a lot of our front-end code to eslint-checked ES6 with some plugins, writing react/redux powered interfaces. New hires generally learn the codebase fast, you're well protected from shooting yourself in the foot thanks to type checking and linting and the absence of globals. Our team is many times more productive with this stack than with the es5 + knockoutjs code we built with before.

If you're building a hobby project, just start with a <html> tag with inline ES5 and css, and refactor and iterate from there. Use server-side templates. "keep it simple". But when building client-side interfaces at a higher complexity level, React is king.

<comment><USER20> > _I have no trouble at all "keeping up" with the "insanity" that is front-end > development. If you're confused learning new things, it means you're > learning._

This naive view though assumes that all learning and all stuff to learn is created equal and is all good.

That is, that the IT industry can't possibly produce junk for people to learn ("busywork", programming fads, over engineered platforms, oversold technologies, etc).

People who have been through the J2EE-hell of mid-noughties, which even its creators condemned and abandoned several years later, but which at the time was touted as "THE WAY" to build enterprise software, and you just had to "man up" and learn it, respectfully disagree.

</comment></comment><comment><USER21> JavaScript is a very special language, I think.

When I learned it in 2011 it was already strange to me, coming from years of work with PHP. Also, Java and C in university.

It was nerver meant to build big applications and had a few issues that many people tried to assert.

Old implementations which needed stuff like jQuery to normalize the APIs, no native module system so everyone implemented their own stuff (ExtJS, CommonJS, AMD, etc.), strange scoping rules forcing variable aliases and wrapper functions all over the place, functions as first class objects intruducing people to a new world of possibilities with ideas from FP, prototype based OO which comes with a different set of problems than class based OO.

The whole "we want new stuff now" movement forced many tools onto us to build our software, which before could simply be run in a browser without compilation. So we got rid of a few problems with a whole set of new problems.

</comment><comment><USER22> I know it's super fashionable to hate on javascript, but I'd be very interested to see a similar rant on another area of software. I'm pretty convinced this is just how the industry works.

<comment><USER23> The same _kind_ of rant applies to things like automake, but only Javascript has this incredibly high rate of churn. Possibly it's easier to build a new toolchain than to understand someone's existing one.

<comment><USER24> That's been my annoyance too. Instead of iterating on what's there everyone makes their own thing and tries to reinvent build tools, frameworks, web components, module loaders, transpilers, package mangers etc... It is improving somewhat. Some tools seem to be winning out and clearing the orbit around them but were still in the primeval js solar system with a few planets forming.

</comment></comment></comment><comment><USER25> Occasionally designers seem to seek credit merely for possessing a new technology, rather than using it to make better designs. Computers and their affiliated apparatus can do powerful things graphically, in part by turning out the hundreds of plots necessary for good data analysis. But at least a few computer graphics only evoke the response "Isn't it remarkable that the computer can be programmed to draw like that?" instead of "My, what interesting data".

\- Edward Tufte

</comment><comment><USER26> People writing these kind of articles are really not looking at their current stack objectively.

If I'm doing backend, I have to pick from various languages, I often will still need build tools (often more complicated) for various reason), you need to spin up a server (or make an AWS account....maybe use S3, maybe not!), you still have dependency management, etc etc.

Remember when Maven picked up, the bitchfests that surrounded it?

And debugging a server side app in production by picking at memory dumps, profilers, etc? Its not exactly easy.

The difference is that those problems are understood, and everyone knows the barrier for entry is higher.

The web platform used to feel like it had a low barrier for entry because it was so limited and there was only so much you could do. Those barriers were removed, so now its just as hard as anything else, except its not quite as understood (the barriers were removed recently). So all of the peanut gallery goes in thinking they can change the world in JavaScript, then realize they actually need to learn to engineer.

A good example of that problem is all of the big companies and startups hiring "full stack" engineers, which is code name for "pure backend engineer who has 10+ years of experience doing backend...and has heard of HTML".

Of course, that kind of people won't go far.

</comment><comment><USER27> The worst is, if you don't keep up with this, good luck getting a web job five years from now, you'll be the equivalent of a Cobol programmer. Can't get off the train.

<comment><USER28> And the best is, if you have a fundamental understanding of _plain, vanilla javascript_ all these new frameworks are pretty easy to pick up. I went from jQuery -> Angular 1.x -> Ember 1.6 -> Ember 2.0 -> React and Redux in basically no time. It really wasn't that hard.

<comment><USER29> There's some truth to that.

My own experience was in writing a lot of vanilla JS, being pretty happy with it, and then wanting to grow bigger I investigated some of the frameworks. At the time, Angular 1.x was considered _the_ thing, so I implemented a project in that (multiple drag and drop lists, items from lists into other lists, and so on), and tried to follow best practices as far as I could tell. DRY, decoupling, etc. It was pretty horrendous. I ended up with so many different services, service providers, components, dependency injectors, and all kinds of (to me) really quite complex abstract boilerplate that had nothing to do with the actual business problems.

I eventually got it all working, and thought I was doing pretty good. I then took a break from that project and came back to it 2 months later, and couldn't make head nor tail of it. So many angular-specific concepts and terminologies.

I've since come across mithril.js, and found it (for me) perfect. It's designed to let you build stuff really fast, and modularise things around your business logic, rather than have the whole of you application design enforced from the framework. Leo's blog posts [https://lhorie.github.io/mithril- blog/](https://lhorie.github.io/mithril-blog/) are fantastic, and I think made me understand a lot more of javascript itself, and how to design applications in much more 'well designed, but not framework specific' ways.

</comment></comment></comment><comment><USER30> I do feel that the javascript people have made C++ look simple. Not so much the language perhaps, but making programs in it..

<comment><USER24> I dunno I think they are on par as far as toolchain goes. autotools, cmake etc.. are no worse or better than gulp, webpack etc...

</comment></comment><comment><USER31> I spend my time in C++ and Python land the majority of the time. I have had to jump in to fix front end bugs a few times... This page reflects my experience fairly well. I spend hours trying to find the magic incantation of bower, grunt, less, npm and/or make, shell, versions to make one line of JS change. And I sincerely hope it gets better. I _want_ to develop web sometimes, but every time I approach a new code base, I feel like I am starting from ground zero.

</comment><comment><USER12> Very accurate

And if you go for X instead of Y you're obviously a non-hipster loser that hasn't been up to this week's fad

<comment><USER32> The later part of your point is salient: the weird hipster 'magpie' culture in front-end programming has a lot of drawbacks.

<comment><USER33> The part I find funny is considering how often the "latest great thing" changes so quickly is that it shows a decent developer can shift to another thing in the ecosystem quickly. Making the "if you aren't using Brand X, then you're behind" attitude seem kind of silly. Considering the response can easily be "give me a few hours and I'll be using Brand X". I've shifted through a dozen or so "latest thing" in my career without much trouble at all.

</comment></comment></comment><comment><USER34> As these rehashed JavaScript versions of [http://harmful.cat-v.org/software/xml/soap/simple](http://harmful.cat-v.org/software/xml/soap/simple) are on front page of Hacker News every other day, I can't even begin to imagine what kinds of rants we will see in the next 15 years or so.

<comment><USER35> "How it feels like to learn Machine Learning in 2025" (9 years from now, 671 upvotes, 158 comments)

</comment></comment><comment><USER36> In defense of JavaScript, there is an article that appeared here not long ago:

[http://mrmrs.io/writing/2015/07/27/too-many- tools/](http://mrmrs.io/writing/2015/07/27/too-many-tools/)

Basically all these new terms come out because people are constantly trying to improve the ecosystem and make it better according to their own standards, be it more modular, more robust, or more scalable.

Eventually winners will emerge and the losers will die out. Give it a few more years and it will stabilize.

</comment><comment><USER37> I've always been of the mentality to use a tool only when the efficiency gains outweigh the learning curve. This is, of course, impossible to judge without spending a lot of time understanding exactly where your efficiency bottlenecks are.

The truth is, a complex application is going to be complicated no matter what tool you use. I look at application programming like this: the more complicated it is, the more likely it is that you've missed key requirements early in the process. This means you will likely need to refactor, rearrange, add/remove features, etc. Choose tools that make this inevitable process as quick and painless as possible. For me that's the number one goal.

I reject tools that make picking a project back up a week or two difficult because of dependencies or weird hacks, syntaxes, or configurations that worked fine when they were fresh in your mind but required an hour of your life to retrace how you got there using the tool.

For example, I chose to use a library that used generators to eliminate callback hell in a screen scraping project of mine. I did this for no other reason than it was too hard to modify the scrapper when everything was nested 8 levels deep. I didn't know what generators or coroutines were before that, but I had spent enough time with my problem to know that I was going to hit a serious maintainability wall unless I found a more clear syntax to write my app. In that case, it was worth the inital overhead of learning new parts of ES6 and programming language concepts.

</comment><comment><USER38> Unfortunately this is pretty accurate..

</comment><comment><USER39> I can not emphasize this enough. Keep it simple. I see to many software written through solutions just because they are a hype. Pick the right tools for the job.

</comment><comment><USER40> In my experience the whole complex JavaScript comes when you try to build the entire thing using JavaScript.

If you are developing a web app, restrict JS to the client side only, get something like react to do it.

On the server side I stick with Go(lang). This separation helps me and my team think of these two separate problems, well.. separately. Isomorphic this isomorphic that is when things start to go all in sane.

tldr; JS for front-end. Go for back-end.

</comment><comment><USER41> And that's way I feel much more comfortable in Dart ecosystem:

\- sane SDK and sane - not surprising - lang without _this_ hell

\- jquery like functionality built in

\- one package manager and package repository

\- can be used on server as well

\- nice tooling (WebStorm-IntelliJ, VisualStudio Code)

<comment><USER42> Would have preferred that Google had put their resources behind something like GopherJS instead of yet another C#/Java-like, feature-creep prone language.

<comment><USER41> their reasoning was AFAIK - lang needs to be C#, Java like to reach mainstream web devs

</comment></comment></comment><comment><USER43> Funny, but it's not quite that complex.

How about "Here's a link to a CLI utility or git repo which will give you a working project in 2-3 hours"?

I took a break from web dev for some years and had barely used any JS frameworks besides jQuery, until June, when I began working on an ambitious project and quickly got up to speed with the state of JS.

I'm using React/Redux/Sagas/Webpack/etc. for the client, and Express (with ES6 and what have you) for the API.

Developing with these new technologies has been a delight, especially compared to hacking bits of jQuery together.

Sure I've had to learn a lot of new concepts, particularly after being away from this world for so long, but this has always felt like a continual learning process to me.

We are the early adopters, the cutting-edge types. If you want to work with aging technologies there are plenty of companies invested in them.

Otherwise you can learn React in a few hours. What's the big deal?

<comment><USER17> > which will give you a working project in 2-3 hours

> you can learn React in a few hours. What's the big deal?

Assuming we are still using the same example (filling a table with some data and filtering it), I think 2-3 hours is a good example of how long it takes to write that in plain Javascript and testing it on every browser back to IE6 while having lunch in between.

<comment><USER44> Funny, I actually had that last year in a 2 hours midyear exam, access to Internet authorized. I was the only one to complete the exam and had the best mark, didn't use internet, just my own code lying around my pc, finished in half an hour, vanilla js/php LAMP.

But many of my class couldn't do it.

</comment></comment></comment><comment><USER45> Sometimes jQuery is all you need. Sometimes you don't even need that.

</comment><comment><USER46> Lucky for him he didn't ask about tests :)

</comment><comment><USER47> "I need to display data on a page, not perform Sub Zero's original MK fatality."

This sums up my opinion of the whole React+Redux+Webpack+SatansSeventhCircleOfHellLib combination.

</comment><comment><USER48> I think people that don't like to constantly learn new stuff shouldn't be developers in the first place ... personally this is the part about web development I like most. I love to write prototypes and experiment with new stuff.

Second JS is not changing so fast imho and there are not so many frameworks that stand out of the crowd. Yeah there are lots of frameworks and libraries on github and even this is a good thing because it shows JS has a vibrant community that loves to create stuff. But it's not like you need know all of them, if you are really lost and don't know what to choose, just ask other developers around you or check out websites like [http://stateofjs.com/](http://stateofjs.com/) and you will notice that there are not that many frameworks that get used by a lot of devs.

</comment><comment><USER49> A common problem when I try to switch to platform that I haven't been paying close attention to. It is very difficult to quickly figure out what is the current stack of libraries and tools you should use if you are starting now. For example jump to the .NET and it is not so obvious should go for Core, Asp.net Core, how to do data access, which version of EF to use and so on.

Usually it is very difficult to find this information from anywhere. Articles and blog posts get outdated fast. Material produced by vendors is usually a bit biased. You get to see all the good things, but they might forget to mention stuff that is still under development. If you are new to the field, you don't know the right people and right blogs.

<comment><USER26> And that's why no amount of good will and side projects will make up for hard, real world experience.

</comment></comment><comment><USER50> There's no need to jump straight into the deep end of tooling.

An iterative approach works really well here - do a brief survey of what tools there are and what problems they solve. Then, when that problem starts soaking up a lot of time, you can read up on the available tooling in greater detail.

There _are_ a vast amount of libraries in the js ecosystem, and it'll take time to fully understand all the different pieces. It took me nearly 2 years to achieve an understanding of most of the buzzwords in that article (and even then, there are some I still haven't worked with directly).

In my personal experience, learning JS is very much a BFS process.

</comment><comment><USER51> Very accurate. The web is still highly immature and the rate of change is proof of that. Very much looking forward to WebAssembly (and its full adoption by web browsers) so then we can end this madness once and for all.

<comment><USER52> I hear this a lot, but I don't get it. How would this help make things simpler or stop "this madness"? If anything it opens up the possibility for even more crazyness. The only difference is you (maybe) get to pick your favourite language instead of learning new ones.

<comment><USER51> It's not so much about picking your "favourite" language. That's what drove NodeJS to exist. But more about picking a more _appropriate_ language that has a well engineered base class library and third party libraries. They will come. This comes down to choosing the best tool for the job at hand.

JavaScript developers have been able to, in recent years, benefit in some ways by being able to write their server-side in JS as well (see NodeJS). There are various buzzwords to describe this capability. WebAssembly will help normalise this so that other languages can also have this capability. By being able to share types between the server and web browser client, there are large productivity and program correctness gains to be unlocked.

<comment><USER53> People are hyping up webassembly way too much. Don't get me wrong it's going to be awesome being able to compile C++ and C programs that run on the Web runtime.

But it's not going to be without it's own issues. For one developers will likely have to wait for things like simd, pthreads or 64bit ints until later versions.

Also it won't magically make compiling your language of choice to the web less painful unless it's C++ or it fits into the C++ language model. Even when it gets the ability to hook into a garbage collector (I wouldn't count on it happening any time in the near future) it will likely have to fit in with the way js engines expect.

</comment></comment></comment></comment><comment><USER54> The frontend frameworks wars are pathological. It's useful, to me, to remember _why_ that's the case: because web sites/apps have to support every browser make and model out there. But how do we know that? Presumably from testing. So its funny that there's isn't any mention in the article about browser testing, or harnesses, or what-not. So now there needs to be another iteration of this series where we step through PhantomJS, Selenium, AWS Device Farm, etc. etc. (and shout-out to Quirksmode and Caniuse).

</comment><comment><USER55> Loved the Trump-ism buried in the middle of the dialog.

</comment><comment><USER56> JavaScript devs have an embarrassment of riches when it comes to tools/frameworks. It is overwhelming yes, but this anecdotal ranting is counterproductive. JQuery still works excellently, and so does ReactJS if you have the patience and time to learn it. One just needs discretion when distinguishing the tools of the avant-guard from the tools of the pragmatic workhorses.

</comment><comment><USER57> Why I Hate Frameworks (2005) is climbing back up the charts, probably because of this very news thread. Here's the link to that: [https://news.ycombinator.com/item?id=12635142](https://news.ycombinator.com/item?id=12635142)

</comment><comment><USER58> No seriously it's crazy. I tried doing some MEAN stuff for a while(I'm backend and can do some WPF UI MVVM ). Anyway it was insane I'm not doing any javascript development. Why would I ? Come to .NET we have cookies.

</comment><comment><USER59> To me, this topic highlights the difference between a developer/programmer and a software engineer. As a small business owner, If I'm hiring a developer/programmer, I'm looking for specific skill sets in a given language/framework. I don't expect to hire a PHP programmer and throw them into React/Mobx/Webpack/Gulp/Babel/Websockets without a tremendous amount of training. Frankly, I don't even expect them to know SQL in any sort of advanced way. I'm paying less for that person and getting less in return. I'm taking on the challenge of "growing" them into what I want them to be in the future or letting them go if our project pivots

When I hire a software engineer, however, I'm paying more and getting more (hopefully). I expect software engineers to understand engineering principles and be able to work in almost any language. At a foundational level, they understand the basics of compiled vs interpreted languages, OOP vs functional programming, client vs server, optimization, testing, databases, networking, software release life cycle...and how to employ all of those. I expect to give them a business problem and have them develop an entire technical solution using whatever tools are best suited for that job.

In most cases, projects are a good mix of both software engineers and developers/programmers. The two can balance each other out and produce amazing things.

Lastly, everyone should be looking to improve their knowledge of their own industry. If you are a developer/programmer/software engineer, you should be looking at what is new/upcoming in the industry. You need to remain fresh or you become obsolete. In a very small example, the move from Python 2 to Python 3 has been a long road. If you are not aware of the improvements in Python 3 over Python 2, how can you actually determine if Python 3 is a good choice for your project? How can you take advantage of the improvements? What about Go vs Python 3? How does Erlang/Elixir fit in to the equation?

</comment><comment><USER60> I feel like everyone needs to be reminded that this post is probably more of a joke than anything. Not criticizing JS so much as a buzzword-iness surrounding it

</comment><comment><USER61> Holy shit these articles are truly tiresome.

I am learning Javascript in 2016. I also learned it in 1998. It was a simpler time back then, sure, BECAUSE YOU COULDN'T DO MUCH. Rollovers, alerts, scroll some annoying text in the status bar of a browser. This was about the extent of it.

I can do SO MUCH COOL STUFF with 2016 Javascript. Much of it comes with a complexity cost, but of course I'm free to code "raw" Javascript in the browser just like I used to. Instead, I choose to learn some new tooling, because the leverage it gives me to execute my ideas is worth the effort.

</comment><comment><USER62> Damn I feel so far away from reality..I am still using vanilla JS (plain old JS not the framework) & JQuery....yet I have no problem.

</comment><comment><USER63> "-Ever heard of Python 3?" (go to top)

<comment><USER17> People love to joke about Python 3 and I totally get it. But compared to Javascript, the mess is _nowhere nearly_ as great.

To make python 2 code compatible with python 3, a few things need changing. For 99% of the code it's very simple, and for the 1% big changes, well, you just need to go through it and refactor some of your code. People have been postponing this but we are well on our way. During the transitioning period, new stuff gets written in py3 and old stuff still runs with the py2. People have both installed. No big deal.

Now Javascript. There is plain javascript with slight variations for every browser. There are a million frameworks, a new one that becomes majorly popular about every two years, and they all work very differently. There is no single, straight upgrade path, it's almost like using completely different languages. There is no "we are nearly done with the transition". Instead there is five new frameworks to look at every year, each of which uses five others as dependencies (angular 2's tutorial is a good example, last time I checked) and one of which will become popular next year, by which time you're outdated if you haven't tried all five. The only new thing that needs explaining in py3, as far as I know, is byte objects vs string objects. Then a few syntax changes (I think OOP changed a little bit) and you're done.

<comment><USER63> I totally agree that Python is much less problem compared to Javascript but I think that it's not fair to compare a backend language to a frontend language. My only complain is that Python is not great at async operations so people have to create unstable async libraries such as gevent and it's usually cause trouble in production. Luckily Python 3 solves this problem but backward compatibility is one of the most important things that is important in a programming language. People usually develop backend services once and maintain it for years but frontend is subject to change more often.

<comment><USER64> > My only complain is that Python is not great at async operations

For most asynchronous IO operations, the old standby of threads works an absolute treat. There are certain pathological corner cases where a single thread can be blocked, but for the other 99.9% of use cases, it works fantastically.

Build your synchronous and stateless web code and throw it into a thread. Done. Even the more complex cases of a single worker needing to make multiple asynchronous calls can be handled easily without even having to leave the standard library.

Now then, this falls apart a bit when you have to deal with global state (and the assorted locks and deadlocks), but most web backends aren't too hard to write statelessly.

<comment><USER65> But spawn enough threads in Python and you risk entering scheduling hell, thanks to the global interpreter lock. EDIT: if you are CPU bound at all. If you are really really IO bound it's not a problem.

Event-driven programming is my go-to for nontrivial backend async in Python, and in Python 2 you almost certainly want to use a third party library for that.

(But maybe I'm just lazy. I try to avoid the headache of threads in python if I can.)

Python 3 has asyncio, which looks good, though I havn't used outside of toy projects at this point.

</comment></comment></comment></comment></comment><comment><USER66> My favorite line from the article:

"I need to display data on a page, not perform Sub Zero's original MK fatality."

</comment><comment> grif-fin The picture on the top sums it up.

</comment><comment><USER67> How it feels to learn parallel parking in 2016

"I want to parallel park in that parking space."

You'll need a car first.

"When I was a kid I just walked into the parking spaces."

Yeah, but that's not really parallel parking, you were just walking into a parking space.

"Oh ok. So I'll get a car then."

Well, it's not that simple, you have to actually get inside the car in order to parallel park.

"What? Can't I just push the car?"

No way! First you have to unlock the car, start it and put it in gear.

"Oh. OK, how do I do that?"

First take out your key.

"What's that?"

It's a small attachment that should have come with your car. Then press the unlock button.

"I unlocked it and am sitting in the seat. Ready to park?

"Not quite. first, you need to put the key in the ignition"

What is an ignition?

"It's the small hole on the side of the steering wheel. Now turn it. No, the other way.

"OK, let's parallel park!"

Hold on now, you need to adjust your seat, rearview mirrors and side view mirrors to ensure that you can drive safely.

"But I don't want to drive, I just want to parallel park!"

It doesn't work like that.

"Fine. How do I get these side view mirrors to adjust?"

Well, first you have to select which mirror you want using the switch to your left, then push the directional arrows until it's at the correct angle.

"How do I know what the correct angle is?"

There are lots of opinions about this, just search Stack Overflow.

"This seems like a good angle. Let's park!"

Hold your horses, first you have to put the car in Drive...

...

Some things that we take for granted as simple really aren't and never have been. Within a generation the above will be completely outdated knowledge and you'll get a car from point A to point B using an app, with its own complexities and absurdities at which we can poke fun in blog posts.

<comment><USER68> Just because you put words in that format doesn't make this a good analogy. You can teach someone to drive, including parallel parking in a couple of hours and then they just have to practice. The javascript ecosystem is legitimately complex. You can't just hand wave that away with a rhetorical flourish.

<comment><USER67> Part of the reason why people can learn to drive in hours is because they have been riding in cars as passengers since birth. Though new at driving, they have lots of contextual knowledge and awareness. If you took someone who grew up on a desert island and taught them to parallel park, it would take considerably longer.

Likewise, experienced web developers have years of contextual knowledge of CLIs, documentation and coding. An experienced dev can reasonably be expected to bootstrap a JavaScript app within a few hours, even if they only used jQuery in the past.

<comment><USER68> Also because we have evolved with complex spatial awareness as an innate trait. Yes, I have been developing websites since 1994, and I have been on the bleeding edge most of that time. Of course I can come up to speed with whatever stack du jour the kids are fawning over these days, but that doesn't make it simple.

</comment></comment></comment></comment><comment><USER69> This article looks like some dialogue taken from Fallout 1. :)

</comment><comment><USER70> JS should have stayed where it was, in the browser ;D

</comment><comment><USER71> Still laughing but if you want to know what:

1\. people use

2\. people are happy with

Try the results of this survey:

[https://news.ycombinator.com/item?id=12627693](https://news.ycombinator.com/item?id=12627693)

</comment><comment><USER72> i miss the days of Borland where the IDE would just run darn the thing.

</comment><comment><USER73> This misses the point.

It's about the unit test.

jQuery is easy to develop with but difficult to unit test.

React is slow to develop with but easier to unit test.

For small projects, jQuery is better.

For large projects where the all the persons writing it tomorrow might not be here today, pick the testable one so they have a chance of future refactoring.

<comment><USER24> Unit tests is not the primary way to choose one frontend framework or another. It's one aspect to look at but i don't think this boils down to unit tests at all.

</comment></comment><comment><USER74> It's so interesting to me that so many people complain and no one does anything.

If Javascript is so bad just make any other JIT compiler run in browsers. Defeat the argument with action.

I'm comfortable with my build process. I have a package.json and a gulpfile.js. I run npm i, then gulp dev. For every new project this is automatic.

Don't follow trends if you don't want to, but I don't believe anything in the OP was difficult if you understand why you're doing it and learn it properly.

<comment><USER75> The proliferation of frameworks _is_ people's attempts to do something about it. But then XKCD 927 applies.

<comment><USER76> Link for the lazy: [https://xkcd.com/927/](https://xkcd.com/927/)

</comment></comment></comment><comment><USER77> > What's wrong with HTML?

Its impossible to share data between JS and HTML without reimplementing parts of JS in HTML from scratch, or rather, implementing a HTML-like template engine from scratch in JS. The model just isn't designed to do what we want it to.

Web components are working on this, except they're reimplementing every modularity feature that JS already provides (HTML imports, shadow dom) from scratch, and then they're implementing every feature that React gives you (custom elements) from scratch. But its still too early, and most tutorials don't show how it works beyond the simplest examples (I would be convinced if I see a data grid component demo with custom item rendering per column which supports passing table data from JS)

</comment><comment><USER78> I'm getting tired of these pointless non-specific rants. You could write an article about "How it feels to learn C++ in 2016" and make it all about the complexities of operating systems, linking, compilation, text editors and the QWERTY keyboard layout, and you'd still be as accurate.

All you need to "JavaScript in 2016" (as a beginner) is a config file and one or two commands. That's it. If that's too information or too hipstery for your taste, then follow the footsteps of other programming languages and use an IDE with a button that can hide that complexity for you.

<comment><USER79> > All you need to "JavaScript in 2016" (as a beginner) is a config file and > one or two commands

And 3 months from now in 2017 those 2 commands will be deprecated because no one uses those programs anymore.

<comment><USER78> As far as beginners are concerned, that shouldn't really matter.

Hide all that complexity in a `./build.sh` or `make` and hand them a config and a README. The author of the article is a web designer with a slightly technical problem to solve. He didn't even need to know about gulp, or grunt, or webpack or babel. Those tools are (should be) as relevant to his domain as the tools used to manufacture the circuits that run them.

<comment><USER79> Not everyone is a beginner web designer. Some people are trying to build things from scratch using JS.

"Just use this magic build.sh!" sounds a lot like "Just use this magic starter kit!" or "Just use yeoman!"

Who is supposed to write this 'build.sh' in this scenario of yours?

Without fail, every single magic build system or magic starter project I have ever used is now deprecated and abandoned.

      Makefiles? No one uses those anymore, use Grunt!
      Grunt?  No one uses that anymore, use Gulp!
      Gulp?  No one uses that anymore, use webpack!

I have a react app that I built on top of a starter kit that I now need to rebuild using create-react-app because the build process broke when I tried updating something.

Meanwhile, I can pick up a python project I worked on 10 years ago, or a go project I started 4 years ago and everything works exactly the same.</comment></comment></comment></comment>


Compiling Haskell to Massively Parallel Hardware [pdf] - <AUTHOR> http://conal.net/papers/compiling-to-categories/compiling-to-categories.pdf <comment><AUTHOR> I'm starting to feel the same way about Haskell that I did with open source software ten years ago. With open source software, when a new CPU architecture like ARM appeared, we could take all our software (including the Linux kernel), rebuild it for this new architecture, and everything just worked. As opposed to Windows, where you might get a working kernel, but all the software is distributed as x86 assembly, so no apps are going to work on an ARM system.

It seems this goes even further with Haskell, allowing us to compile not only to new CPU architectures, but to even more exotic targets like FPGAs, since the code is closer to a logical description of the problem domain, as opposed to a sequence of state modifications. This will become particularly relevant if end up hitting a wall with regards to CPU performance, and need to move to different hardware in order to gain a speedup.</comment>