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

101–110 of 125 posts

Re: Too Many Tools and Frameworks (2015)

#101

Post by weberc2 »

dkarl wrote: post #93

As a back-end developer, I find it interesting that the default answer is a framework — the state of affairs that prevailed ten to twenty years ago in server development. Enterprise Javabeans, Spring, everybody assumed that big, overarching frameworks were awesome and you couldn't afford to do without them. Our experience with that mindset has pushed us to the opposite default assumption: everything is better if it c…

I agree. I program in quite a few languages, but Go is my favorite when it comes to a low-bullshit ecosystem. There are probably too many web frameworks, but the standard HTTP library seems to have the bulk of the marketshare.

Re: Too Many Tools and Frameworks (2015)

#102

Post by morgante »

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…

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.

Re: Too Many Tools and Frameworks (2015)

#103

Post by morgante »

dkarl wrote: post #93

As a back-end developer, I find it interesting that the default answer is a framework — the state of affairs that prevailed ten to twenty years ago in server development. Enterprise Javabeans, Spring, everybody assumed that big, overarching frameworks were awesome and you couldn't afford to do without them. Our experience with that mindset has pushed us to the opposite default assumption: everything is better if it c…

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

Re: Too Many Tools and Frameworks (2015)

#105

Post by JustSomeNobody »

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 it?

Re: Too Many Tools and Frameworks (2015)

#106

Post by dkarl »

morgante wrote: post #103
dkarl wrote: post #93

As a back-end developer, I find it interesting that the default answer is a framework — the state of affairs that prevailed ten to twenty years ago in server development. Enterprise Javabeans, Spring, everybody assumed that big, overarching frameworks were awesome and you couldn't afford to do without them. Our experience with that mindset has pushed us to the opposite default assumption: everything is better if it c…

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 backbone.js and React have openly and explicitly designed them not to be frameworks, people continue to call them frameworks, and not disparagingly. There seems to be a huge appetite for frameworks. From the outside (and definitely projecting my own inexperience) I would guess that a lot of people feel lost architecting a web UI from scratch. They don't want building blocks. They want a way, a path to follow. A lot of server programmers felt the same way twenty years ago. Adopting a framework meant giving up freedom that they didn't want in the first place because they didn't know what to do with it.

But I'm coming at it from a very outside/inexperienced perspective, so I feel like I should leave it as a question rather than a comment. What do you think? Why are frameworks considered such a good thing in web UI programming that widely used and admired libraries end up being called "frameworks" as a term of respect?

Re: Too Many Tools and Frameworks (2015)

#107

Post by amirouche »

dkarl wrote: post #93

As a back-end developer, I find it interesting that the default answer is a framework — the state of affairs that prevailed ten to twenty years ago in server development. Enterprise Javabeans, Spring, everybody assumed that big, overarching frameworks were awesome and you couldn't afford to do without them. Our experience with that mindset has pushed us to the opposite default assumption: everything is better if it c…

There is a clear distinction between a framework and library. AFAIK a library is focused to solve a particular problem for instance routing, data validation, i18n, state management, view rendering (like templates systems), data models etc... On the other hand framework try to tackle a set of related problems into a coherent/logical workflow. For instance there is not a single library that can handle by itself the issue of isomorphic apps. Angular is a framework, reactjs is a library but http://reactboilerplate.com/ is framework using reactjs.

I think backbone is framework not a library it tackles several issues (class system, views, and middle end) and it does it badly but that's a topic of ~another post~ the past.

Historically Javascript community has favoured the do-it-yourself framework hence or because there is a lot of libraries you can choose from or because the needs of everyone are so different that's it's difficult to create a miningful framework. Mind the fact that Google previous "framework" named Google closure was a stdlib kind of framework compared to the competition of MV* framework like emberjs or angular it did not force a given workflow.

Re: Too Many Tools and Frameworks (2015)

#108

Post by vonmoltke »

austinpray wrote: post #36
douche wrote: post #22

Earlier quoted context omitted.

The tools need to be better than what came before, rather than just different . So far I've dealt with grunt, then gulp, then webpack. None of these are appreciably better than make, they are just different and newer...

You don't understand what webpack is. It's a module bundler. You use webpack in conjunction with make, grunt, gulp, or any other task runner or build system.

What do you use make, grunt, or gulp for in that case? My frontend build command is just "webpack". Everything necessary is handled in webpack.config.js.

Re: Too Many Tools and Frameworks (2015)

#109

Post by vonmoltke »

progx wrote: post #69
rekshaw wrote: post #42

Earlier quoted context omitted.

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.

That's part of the frustration for people coming from other specialties. Why are your problems so different from mine as to have a different "best" list of tools? We're both building web-based UIs. We should be using basically the same tools.

Re: Too Many Tools and Frameworks (2015)

#110

Post by morgante »

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…

I think your entire comment is built on a false pretense that popular libraries are called "frameworks." I have never once heard an experienced JavaScript programmer call React a framework.

It's objectively not. To build any reasonable application you'll also have to choose, at the very least, a state management utility as well.

That being said, I'm sure there are beginners who call React a "framework" but that can easily be explained by the simple fact that they are beginners: they don't really understand what React is or even what the differences between libraries and frameworks are. They assume any stack has to be built in some sort of framework, so React is that "framework."

Post reply on HN