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

111–120 of 125 posts

Re: Too Many Tools and Frameworks (2015)

#111

Post by amirouche »

dkarl wrote: post #106
morgante wrote: post #103

Earlier quoted context omitted.

I'm pretty sure you're just playing with words here. One of the most common complaints is that the biggest web tools are libraries, not frameworks. React, for example, is very emphatically not a framework. To develop any reasonably sized application, you need to bring in a number of other libraries as well (such as Redux and/or Apollo).

It isn't just words — the words reflect people's expectation that a framework determines quite a lot about your design and approach. It's a system and a way of programming you assimilate into. A library tries to help you do something while dictating as little as possible about your overall application design. I think it's very interesting that even though the expert and experienced programmers who create things like…

First you can use reactjs alone without a flux architecture.

> Why are frameworks considered such a good thing

The only thing nice about framework is that they make the main workflow obvious. But things becomes scary when you walk on the wild side (backed by experience with Django and Django RESTframework)

The problem with reactjs is that facebook was using reactjs and its "architecture" for big apps and now they try to make it work in a more general context.

> in web UI programming that widely used and admired libraries end up being called "frameworks" as a term of respect?

Backbone is framework, saying it's a library because you can use only the collection model and use whatever method you want to fetch your data or whatever template language or bind events yourself is like saying you can replace the URL routing or template language of Django on your own. Doable but not recommended.

Re: Too Many Tools and Frameworks (2015)

#112

Post by KaiserPro »

keyle wrote: post #6
swyman wrote: post #2

Ultimately the responsibility to pick reliable tools lies with the carpenter

True but most often the carpenter is misinformed by crowds or large corporation pushing their tools as "the best in the business".

only if they are an arse, and can't figure out changes in quality of work.

Re: Too Many Tools and Frameworks (2015)

#113

Post by amirouche »

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…

Angular (prolly the same of Angular2) is that it's magical hiding the underlying browser mechanic, DOM manipulation. It's is hidden below layers of fancy syntax. Whereas with reactjs you have a kind of steap learning curve in the sens that you have to grok an ecosystem of diverse communities (ex: gulp, flux, webpack) but for Javascripters that's almost part of the regular shore when you are used to build you own framework. AND ReactJS reuse most concepts from vanilla Javascript and DOM.

Re: Too Many Tools and Frameworks (2015)

#114

Post by bungle »

raverbashing wrote: post #96
ebiester wrote: post #95

Earlier quoted context omitted.

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.

Re: Too Many Tools and Frameworks (2015)

#115

Post by nitely »

raverbashing wrote: post #73
ffggvv wrote: post #39

Earlier quoted context omitted.

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?

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

Re: Too Many Tools and Frameworks (2015)

#116

Post by haney »

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

Re: Too Many Tools and Frameworks (2015)

#117

Post by ravenstine »

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.

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.

Re: Too Many Tools and Frameworks (2015)

#118

Post by mamcx »

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.

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.

Re: Too Many Tools and Frameworks (2015)

#120

Post by crasm »

JustSomeNobody wrote: post #105
DanielBMarkham wrote: post #58

I've been a coder and have watched coders for a long time. I consistently see two trends. As an agile guy, back in the day I wrote an Agile story tracker. Fun times. Then I saw some other Agile project management tools. Then for a while it seemed like every week or two I was getting emails asking me to evaluate yet another agile/to-do list tool. It seemed that programmers were unable to grok the agile story concept w…

Interesting, but you're pretty spot on. Personally this has caused me great angst[0] as I tend to write the absolute minimum amount of code necessary to solve the exact problem I'm trying to solve. I tend to wait until I've solved a problem in similar ways three[1] or so times before I generalize it. [0] Because other developers want to solve for a more general problem. [1] Three is such a comfortable number, isn't i…

I've noticed I tend to work in three passes, although not necessarily three tries.

First is an over-abstracted mess that may or not work before it eventually collapses. Brainstorming.

Second is a rewrite aiming for compactness, that could end up impossible for anyone else to understand.

Third pulls just the right amount of abstraction out of the terseness of the second pass.

I treat it like a feedback driven control-system. Too much abstraction? Dial it down. Not enough abstraction? Dial it up. Repeat until good enough.

If I stop at 1 or 2, the code is poor. If I don't oscillate, it takes more passes.

Post reply on HN