Live data from Hacker News

Too Many Tools and Frameworks (2015)

mrmrs.io

61–70 of 125 posts

Re: Too Many Tools and Frameworks (2015)

#61
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…

Angular2 is a special case, in that a lot of the frustrations you're feeling are probably not far off from the frustrations that Angular1 developers are feeling.

The decisions they made going from Angular1 to Angular2 are a big reason I've never really bothered with Angular.

Just on a base level, if a system isn't properly documented, that does make a case for finding someone with indepth knowledge.

But a company using a system that is very poorly documented as their core technology is a big red flag for me.

Re: Too Many Tools and Frameworks (2015)

#62
I think the complaint about too many tools is really just a euphemism for complaining about peer and employer pressure to always be up-to-date with the latest tools and styles. Developers live in constant fear of falling behind.

But is this pressure justified? I see two possibilities:

a) The latest crop of the top 10% tools really makes us much more productive than last year's crop of the top 10% tools. So the best developers will always filter through a lot of new tools to find the best 10% and benefit from them.

b) After accounting for productivity losses incurred by constantly relearning and rewriting everything, the lastest best tools have no productivity benefits. They are just a distraction from the product we're supposed to be working on.

I don't think there is ever a time in history when this question can be answered unequivocally, and therefore it is never possible for good developers to stop looking for better tools completely.

However, I feel that at no time in the past quarter century has the pendulum swung so far in the direction of (b) where front end development is concerned. I realize this is very subjective.

Re: Too Many Tools and Frameworks (2015)

#63

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 expert and give them a few weeks angular training they'll rock a todomvc but full apps often end up with controller-as-a-god-object.

Genuine experts would be really nice to find, but it's really difficult because frameworks aren't given time to mature before the smartest people have moved on to other frameworks.

You're right that employers should hire on general understanding and give time, but the required time is typically 6 months and a failed project or two. Many employers don't make and don't want to make that kind of human-capital investment anymore.

The "rockstar" who knocked something up pads their resume with another project with a hot new framework, got experience with another new set of tooling and can leverage that to move somewhere else to produce more working but hard to maintain code in another hot new framework because their CV is padded with experience showing they're a quick learner, but the company left behind pays the cost in maintenance.

A genuine angular expert will likely be well employed for a while come helping troubleshoot and clean up the mess left by the cool crowd.

p.s. I am not an angular dev, this complaint can be leveled at a lot of hot new tech, particularly but not just the javascript front-end world, it equally applies to people who knocked up go microservices at a .Net shop, or hastily introduced mongo to replace oracle, etc., etc.

Re: Too Many Tools and Frameworks (2015)

#64

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

A possible approach is to let developers new to a framework on a prototype or toy project first, and, very important, throw away that prototype.

Yes, that means you might have to wait two or three weeks longer until you get started with the real project, but the result will be so much better.

But that's one of the prices you pay for using an immature technology. For a more mature one, you could read a book on successful usage pattern of the technology.

Re: Too Many Tools and Frameworks (2015)

#65
It's a feedback problem. People seek to solve problems and by doing so create new ones. Which also need solutions. That create more problems. Packaging, transpiling etc are already second order problems and there are third and fourth ones as well. This won't stop until js becomes completely unusable.

Re: Too Many Tools and Frameworks (2015)

#66
This is all fine and good - but it would be nice to know which one's work well, which are robust, and which one's are 'pro level' - without have to experiment with each one.

It's really hard to tell these days.

After some experience with node.js - I'm weary to pluck anything that's not in the 'top 10' most established frameworks.

Re: Too Many Tools and Frameworks (2015)

#69
post #42

I've been building UIs for 20 years, and the tools we have now are the best I've ever had the pleasure to work with. It's more fun now than ever. More please.

Can you provide a shortlist of the tools you use?

The list won't solve any of your specific problems.

I had a much better list, then the previous Poster, because it solve my problems the best way.

Did you need my list now too?

I am absolutely sure, that somebody else had a better list.

Re: Too Many Tools and Frameworks (2015)

#70

I'm building a better JS framework https://github.com/crocodilejs/crocodile-node-mvc-framework - release v1.0.0 comes out soon, join in Slack at http://slack.crocodilejs.com/

I am honestly not sure if this is some satirical masterpiece or not. The README says yes but the amount of work that has gone in to it...

I upvoted it on the basis that it was!
Post reply on HN