Hacker News Reader

You can spin it this way if you like. However, a big part of this framework and Tool epidemic is ego. The trick is to take a dominant framework or tool, find a deficiency, and then rewrite it again with that deficiency fixed. Why? Because if it takes off, your career takes of.

What developers should really do is contribute and make the existing projects better. Everyone will thank you for it.

Nope they won't, because then your are just another contributor.

There are thousand working on linux (the kernel). How many of them do you know?

Which is better (for your CV), be a contributor to Angular.js (example) or create your something.js that left-pads and right-pads at the same time?

From what I can tell, something.js if the amount of code is equivalent.

Having a patch or two in angular doesn't seem to move the needle.

No. Because nobody knows about your something.js

Getting something on Angular means you were able to get your changes approved and merged (team work)

Situation is better if you can have a bigger project or more people using your something.js

Well, left pad was quite famous. And especially famous when the author removed it. You never know.

Was it famous before the author removed it?

I think a better example would be: be a contributor to Angular.js or be the creator of Aurelia.js.

It actually helps if you contribute to an existing project, because it is like, you worked with others on an existing codebase and contributed features in a big project which has high visiblity and is being used in real life by real people.

Much of what we work is all with people and on large codebase, so if you are contributing to existing project, it is actually helpful for interviews. Also it takes weeks to get a PR accepted, so if you actually were successful in getting your feature accepted, it shows your resolve to contribute the feature because you want to contribute and not because you want to do a PR stunt for your career (and not get annoyed by the constant changes which the authors ask, which are close to a million)

Are you saying that JS devs are different from Ruby devs in this regard?

Throwing out some observations/arguments here:

Many more JavaScript tools and libraries have websites that are visually appealing than for any other tool or technology that I've seen. Since the informational content is usually not of a similar or higher quality in my experience, it stands to reason that appearance is more important to developers of JS tools/libraries. Which could imply that peer recognition or career building is a more common, or stronger motivators in this particular demographic (of JS tool/library authors)

I'm also entertaining the thought that JS development might be a more solitary work (on average), which could conceivably also influence if you choose to cooperate rather than build anew yourself. Most JS tools were also not very big, as they had to be delivered to the client, and as such more amenable to being built by a lone developer or a small team.

The only thing I known for sure is that in 20 years of coding, nothing have confused me as much as the plethora of JS 'things', not even DCOM or the almost unequivocal praise of Hibernate (for a while)

> (...) it stands to reason that appearance is more important to developers of JS tools/libraries. Which could imply that peer recognition or career building is a more common, or stronger motivators in this particular demographic (of JS tool/library authors)

I think you read too much into it. The front-end of a website would be important for tools which help making front-ends of websites, don't you think?

>Many more JavaScript tools and libraries have websites that are visually appealing than for any other tool or technology that I've seen. Since the informational content is usually not of a similar or higher quality in my experience, it stands to reason that appearance is more important to developers of JS tools/libraries. Which could imply that peer recognition or career building is a more common, or stronger motivators in this particular demographic (of JS tool/library authors)

I agree with your other points, but this one is easily explained by the fact that people who specialize in Javascript tend to be in the front-end/UI development field, and thus are more likely to have an artistic background/sensibilities.

Both could be true. In my experience outside perception is quite a bit more important to people with artistic background than to the average programmer.

I somewhat agree...

However, there is also something to be said for rewriting work. There's the concept of "plan to throw it away"[0] I think a lot of these projects start because people are just trying to learn. Then they share them and get built upon. You then have an ever increasing amount of technical debt, eventually inspiring others to write a simpler version and then that becomes the defacto and so it continues...

I think my favorite example of just stupid stuff that keeps getting propagated is the Date type in javascript - the month field starts with "0", but the day field starts at "1"[1]. Like what is with that?

Even with everyone contributing to Javascript that stupid thing still exists because you can't break the internet to fix it (ask the Python community how changing a lot of syntax works out - although Python wasn't even that bad). That's why people write new stuff, because they want to make things simpler. Not really something to complain about IMO.

The unique stuff I learned is probably just these four languages: BASIC, C, C++, Python - I learned it in that order and now I can pretty much do w.e. language I need to use. Because all frameworks are based off the same stuff. Go is easy, Javascript - no problem!, I do full-stack work and data science in my day job it's really not hard at all. All the frameworks make it even easier.

[0] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

[1] http://www.w3schools.com/js/js_dates.asp

I second the part about ego. I once wanted to write a BaaS because I was not happy with parse-server. After considering the time efforts and comparing it with the efforts to improve parse-server I decided to just improve that software and don't care about my own project, because I try to value my time higher than my ego. It isn't easy to be rational if your ego is involved.

But it's also difficult to decide if it's worth it, especially if you've found a real deficiency. The creator of http://propelorm.org said to me that his framework gets him €120k+ offers and that he recommends building open source projects that are in demand.

So I don't think it's possible to give a definite answer what developers should really do. Maybe bit of both?

You took the words right out of my mouth. It has more to do with ego than everything else, and you can tell because most competing tools, in JS anyway, don't have a significant edge over the others and are largely the same tool reimplemented without much of a concrete goal besides "performance" and "scalability ". Like you said, taking an existing tool with a deficiency and rewriting it from scratch without that deficiency. Advances have occurred for sure, but not without some massive failures from not having a good roadmap. Brute force, in other words. The projects that do have more concrete goals and vastly different methodologies in the JS world happen to be low in popularity, relatively speaking. I wonder if the inflated egos in the JS community comes from all the talk of "Node.JS is the future" in recent years. There aren't nearly as many competing projects in the Ruby world, or Python or even PHP.

This not work at all, is super-unrealistic.

And it grow more un-fixable as longer and bigger is the project.

For example: Fix C. Or javaScript. or Angular.

Is impossible to do it without change what them are. And when the trouble is intrinsic the only sane option left is restart.

In fact, stick to old is as worse (and maybe more) then rewrite. The trouble is when rewrite not change enough to be worth it.

> I suspect the best/healthiest ecosystem is probably somewhere in between that of Ruby and JavaScript. Rails may have ultimately hurt Ruby by its dominance, just as the current volatility in JavaScript tools seems to drive some people away (or at least add frustration).

I think this description matches the Python web ecosystem quite well. Historically there were the Z(ope)-ish projects, which still exist and are being used (and they work quite nice); Django obviously dominated for a long time, but in more recent years some healthy competition ensued (Flask and it's highly modular approach for example, but also Pyramid), which resulted in a lot of reworking and improvement for all frameworks. Django now vs. Django 2010 is a vast difference in developer and user friendliness. Some specialized frameworks popped up (Tornado comes to mind), but overall there isn't a heavy fragmentation of the ecosystem (bad) but no one dominator either (bad).

Its nice that there is one (fairly) obvious choice to go for unless you have specific needs.

The Java ecosystem is another good example IMO.

Web frameworks: Spring, Java EE, a lot of solid smaller ones.

Build tools: Ant (mostly legacy), Maven or Gradle.

Then for almost any niche there's usually 2-3 clear contenders, production-grade stuff.

For such a huge ecosystem Java is remarkably not-fragmented.

I'm curious, has anyone performed a comparative study that breaks this down e.g. correlating aspects of language design to systemic structures in the resulting ecosystem?

I have often wondered whether the level of complaint relating to Javascript framework proliferation is explainable as due to language structures (whether notably present or notably absent) or unusual initial conditions of the JS community/ecosystem.

Is there even a field of techno-psycho-sociological studies, and is there an equivalent of the Sapir-Whorf hypothesis for programming language ecosystems?

> the current JavaScript landscape seems to have a fairly low index; there are a huge number of tools with very few clear winners at this point in time

This isn't a problem by itself, the problem is the ever-changing "clear winners" and hordes of people using them with no understanding of their trade-offs.

I hear complaints like this a lot: "It was so easy to-do this with jQuery, why is this JS-framework-de-jour so complicated?" - well, why didn't you start with what-you-know and explore their limits litte bit, so you would know what you really needed?

With Ruby and Rails, you have a single answer to many use-cases, with JS and the npm, you have many answers to each use-case imaginable and choosing by popularity is very damaging.

Here's another hypothesis:

Language communities are in an arms race to create the best platform for the Cambrian Explosion of tools necessary to support a dramatically growing and diversifying developer population. Languages with a proliferation of tools, where developers are experiencing choice fatigue, have the incentive and the usage data necessary to design the meta-tools that will make development in such an environment easy. Languages which rely on small selection to solve the problem will remain niche languages.

We're just waiting for some innovations in package/community/docuentation/source control management to crystalize and make the whole problem moot.

In practice, there is usually only a single dominant technology at a time even in the JavaScript ecosystem. See this recent survey: https://news.ycombinator.com/item?id=12627693

Right now it seems very clear that React, Redux, and Webpack are winners.

The difference, I think, is that many of these tools are simple enough that if you have a new idea you will simply write a replacement instead of trying to work with the maintainers to push out a dramatically different new release.

I agree that there is a high risk of project abandonment and it is frustrating that we haven't yet found a consensus around javascript frameworks. But, I would argue that Rails became dominant because it was so much better than the alternatives, we're in the messy part of the cycle where we're not sure what the next great/common/standard library or framework is going to be, but on a long enough timeline I'm confident that the best abstractions/communities/frameworks/libraries will be the most popular, because they allow developers to produce the best things quickly. We're a part of the immune system that helps us to converge to that reality.

I think it's a JS problem with trends around other languages tending moreso to a single eco-system.

Regarding JS frameworks, I think the barrier to entry is still low, and given the suffering involved for any given tool-chain, I'd imagine the temptation to roll ones own is high.

Finally, JS framework fates are tethered to that of the browser. The latter changes frequently, so the former ends up in a refactoring perma-loop.

> Finally, JS framework fates are tethered to that of the browser. The latter changes frequently, so the former ends up in a refactoring perma-loop.

Could you elaborate on that? What kind of browser changes are happening so often and are so deep that frameworks need to be refactored every time? (My experience is quite the opposite.)

Sure. E.g ECMAScript supported versions, HTML5 features, HTTP2 support, mobile/tablet specific browser features, CSS1,2,3 support.