Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Too Many Tools and Frameworks (2015)

mrmrs.io

Post reply on HN
Print view View original

81–90 of 125 posts

Re: Too Many Tools and Frameworks (2015)

#81

Post by michaelchisari »

throwawayReply wrote: post #63
michaelchisari wrote: post #8

For side projects, it can be a little daunting, but ultimately represents a healthy eco-system. But the issue for me is how employers handles it. No, I don't know Angular. But I have used Backbone, Ember & React. So do you really need an Angular expert, especially when Angular is only a few years old and is completely changing in Angular 2? Should employers insist on extensive trade knowledge in a specific framework,…

(This isn't a personal attack on you or your ability, I don't know you) I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible. Part of that is because angular is different, it's not very nice and it has obscure knowledge needed to make it play nicely with unit testing. If you take an ember / backbone / whatever ex…

> full apps often end up with controller-as-a-god-object.

Wouldn't a depth of knowledge of dev patterns (and anti-patterns) be enough?

I don't have to know anything about Angular to know that's a bad idea.

Re: Too Many Tools and Frameworks (2015)

#82

Post by userbinator »

I think the problem isn't "too many" --- it's the fact that they're all reinventing the same things and adding significant complexity in doing so. It's an enormous waste of resources both on the part of the developers and the end-users who ultimately have to "bear the bloat".

Web development seems unusually prone to this trend, but I've seen it happen with software in general. I hypothesise that the reason for this happening to web development in particular is largely because the basic problems have already been solved long ago, so all this churn is created by people who are "oversolving the problem", having nothing else to do than to think of new --- but not necessarily better --- ways of doing it.

Introducing complexity must feel productive to a lot of people, and I suppose some derive pleasure from being able to learn about, build, comprehend, and modify such complex systems. But I don't. Making websites that require several MB of JS and the latest browser features to display a few KB of static text? I just don't see the point.

Related: http://countercomplex.blogspot.com/2014/08/the-resource-leak... and discussion https://news.ycombinator.com/item?id=8679471

Re: Too Many Tools and Frameworks (2015)

#83

Post by 59nadir »

lucaspiller wrote: post #47
59nadir wrote: post #21

Earlier quoted context omitted.

I think the real markers should be that a person is not afraid of broadening their views. Usually, the advice for hiring for Erlang, as an example, is not to hire people that know Erlang, but focus on hiring good people (who are capable of learning beyond your average C-like) and then teach them Erlang. It's a small and very easily learned language, for sure, but learning it is certainly a bigger undertaking than lea…

I've been trying to learn Angular2 recently, maybe I'm not a good developer (but I faired ok with Erlang :D), but it really is such a struggle. Documentation is lacking, and what is available is often wrong or outdated. It doesn't help that half the tools and libraries are still in 'beta' and breaking changes are seen as a way of life. This post really sums up my experience, and I've done plenty of Javascript before…

> I'd actually say for someone completely new (e.g. locked in a basement doing C or Java for the last 20 years), learning Erlang would be far easier than learning modern JavaScript and Angular2.

I suppose that might be the case. It feels incredibly counter-intuitive, but it's not inconceivable that the JS frameworks stray that far from "normal JS".

Were I in this situation as a employer (and co-worker, necessarily, not only in a managerial position), I would probably make the decision to use other technologies and compile to JS, in that case. There's very little to gain from using a framework that by necessity is tied to a crummy language if I can skip using that as a source language anyway, and then I'd just go with something sane like Elm instead.

(Bear in mind, this is coming from someone who doesn't actually work with front-end development, so take it with a grain of salt.)

Re: Too Many Tools and Frameworks (2015)

#84

Post by oblio »

leppr wrote: post #60
mickronome wrote: post #52

Earlier quoted context omitted.

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…

>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 motiva…

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.

Re: Too Many Tools and Frameworks (2015)

#85

Post by oblio »

dom0 wrote: post #71
dperfect wrote: post #13

The problem really isn't a function of the number of tools and frameworks in existence, but rather in the distribution of popularity among them. Each ecosystem around a set of technologies essentially has its own "Herfindahl index"[1] of sorts. For example, the Ruby ecosystem's index might be fairly high, simply because Rails is so dominant (to the point where Ruby and Rails are often conflated by outsiders). On the…

> 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 bei…

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.

Re: Too Many Tools and Frameworks (2015)

#86

Post by lettergram »

electic wrote: post #27
dperfect wrote: post #13

The problem really isn't a function of the number of tools and frameworks in existence, but rather in the distribution of popularity among them. Each ecosystem around a set of technologies essentially has its own "Herfindahl index"[1] of sorts. For example, the Ruby ecosystem's index might be fairly high, simply because Rails is so dominant (to the point where Ruby and Rails are often conflated by outsiders). On the…

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.

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

Re: Too Many Tools and Frameworks (2015)

#88

Post by sotojuan »

lucaspiller wrote: post #47
59nadir wrote: post #21

Earlier quoted context omitted.

I think the real markers should be that a person is not afraid of broadening their views. Usually, the advice for hiring for Erlang, as an example, is not to hire people that know Erlang, but focus on hiring good people (who are capable of learning beyond your average C-like) and then teach them Erlang. It's a small and very easily learned language, for sure, but learning it is certainly a bigger undertaking than lea…

I've been trying to learn Angular2 recently, maybe I'm not a good developer (but I faired ok with Erlang :D), but it really is such a struggle. Documentation is lacking, and what is available is often wrong or outdated. It doesn't help that half the tools and libraries are still in 'beta' and breaking changes are seen as a way of life. This post really sums up my experience, and I've done plenty of Javascript before…

Well yes, Erlang is pretty well-thought out, has a decent standard library, decades of serious production use, and couple of community-blessed books you can learn from.

Re: Too Many Tools and Frameworks (2015)

#89

Post by acdha »

throwawayReply wrote: post #63
michaelchisari wrote: post #8

For side projects, it can be a little daunting, but ultimately represents a healthy eco-system. But the issue for me is how employers handles it. No, I don't know Angular. But I have used Backbone, Ember & React. So do you really need an Angular expert, especially when Angular is only a few years old and is completely changing in Angular 2? Should employers insist on extensive trade knowledge in a specific framework,…

(This isn't a personal attack on you or your ability, I don't know you) I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible. Part of that is because angular is different, it's not very nice and it has obscure knowledge needed to make it play nicely with unit testing. If you take an ember / backbone / whatever ex…

> I think yours is a dangerous attitude, I've seen a lot of mess produced by people who come in to angular knowing other frameworks and their output is terrible.

Outside of a hire-an-expert consulting gig, I really would say the problem here lies almost exclusively on the engineering management, or lack thereof, and broader staffing decisions. I don't think it's necessary to have a project fail for someone to understand a tool[1] but the ability for someone to get up to speed is a function of the time invested in things like mentoring and code-review.

Yes, many companies make the short-sighted decision to skimp on that investment but that needs to be recognized and fought as a management problem – any project is going to suffer in those conditions even if your entire team is staffed with experts because understanding the actual business problems is as hard as the tech stack and if you can't carve out time to think about a few controllers, there's no way that the rest of the problem doesn't have problems which are at least as bad.

1. If true, that would be a huge sign that the tool has major design failures and is not suitable for production use rather than an argument against hiring people who aren't already experts.

Re: Too Many Tools and Frameworks (2015)

#90

Post by throwmenow_0139 »

electic wrote: post #27
dperfect wrote: post #13

The problem really isn't a function of the number of tools and frameworks in existence, but rather in the distribution of popularity among them. Each ecosystem around a set of technologies essentially has its own "Herfindahl index"[1] of sorts. For example, the Ruby ecosystem's index might be fairly high, simply because Rails is so dominant (to the point where Ruby and Rails are often conflated by outsiders). On the…

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.

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?

Post reply on HN