The cycle described here is perfectly acceptable in principle, not to mention unavoidable in practice. Our developer tools will stop changing when humans stop changing.

Not really. Fragmentation is only inevitable when there exist feature tradeoffs. If Parcel's advantage is parallelism and caching, it's possible those features could have been added to Webpack.

Having one tool that is configurable for all problems often becomes a mess and even harder to use.

But the solution to this is to make more tools with different tradeoffs. Not to add features to the tool that was supposed to be simple at the beginning.

You're correct, of course. I consider "simplicity" to be a feature, which is almost always at odds with other features.

You have never used Tex....

God forbid we improve existing tools. What exactly is your problem here? Do you think we should all be using the Borland C++ compiler too?

I think the problem is less that there are new tools, but that the new tool comes promising to make the very much what the old tool did, just with much less configuration and smart defaults. But as soon as you start using that new tools for a while the once smart defaults are not so smart anymore (as requirements have slightly changed) and you start configuring it more and more and after a while you have the same mess of customization as with the old tool until someone comes up with a newer tool that has newer smart default and so on...

Its not necessarily bad as most new tools are slightly better than their predecessors, it just takes some getting use to and you have to learn how to structure your code base in a way that you do not have to completely refactor it every time a new build tool is adapted ;-)

Change != Improvement.

Does the release of parcel mean you can no longer use webpack, or gulp, or grunt or whatever you’re using now?

If you don’t like a new tool, don’t use it. I can’t stand this kind of meritless complaints. If you’ve got a problem with the implementation of a new tool, that’s understandable. But to take issue with its existence? That’s just petty and a waste of everyone’s time.

>Does the release of parcel mean you can no longer use webpack, or gulp, or grunt or whatever you’re using now?

If it takes away from their community and momentum, then yes.

Attention in FOSS is close to a zero-sum game.

Not to mention when the devs themselves get bored with tool X they've created and jump to creating some newer tool Y, dropping the whole community...

> Not to mention when the devs themselves get bored with tool X they've created and jump to creating some newer tool Y, dropping the whole community...

Given that you don’t pay for the product I don’t see anything wrong here. People work on what they want then change if they’re bored; you can’t do anything about that but pay them to continue supporting the tool you decided to use.

>Given that you don’t pay for the product I don’t see anything wrong here

Things might not be wrong and still be a problem. E.g. your neighbor practicing tuba (badly) during the whole day, in perfectly legal hours...

In fact someone can gift stuff with the best intentions, and still cause a problem.

> you can’t do anything about that

You can. You can encourage developers to contribute to a single project, rather than create fragmentation, which is exactly what's happening in this forum.

Webpack doesn't seem to have a shortage of contributions. What is your real concern?

1) A fragmentation of targets for complementary products. Any tool that must integrate with bundlers now has one more target.

2) A fragmentation of development efforts across competing projects. Webpack has many contributors, but they'd have 1 more if the author of Parcel built parallelism into Webpack instead of a new bundler.

Yes, you can. But you can’t force them if they don’t want it.

K. Who's forcing anyone?

Nobody’s forcing anyone but a lot of people including the parent comment complain when someone doesn’t want to work for free on the tool they use. Encourage people if you want, but don’t complain if they don’t listen.

By all means, do. People complain about things that make their lives worse, especially when it's avoidable, as it is in this case. There's nothing wrong with that.

You can encourage them to instead work on improvements to existing tools.

Oh, so if you don't pay for a tool you can't control the development of it? How unexpected!

First, nobody said it's "unexpected". We said that such a change is inconvenient for the user of the tool, which is trivially true -- whether they can/desire to control the development or not.

Second, even τηε premise of it being "unexpected" is not 100% true. None dev communities influence the development of projects all the times -- projects even have special voting boards for people to vote what features they want next etc.

Besides, it's very possible to not pay for a tool and still have a voice in the development of it. It just takes the development team to be willing to hear their userbase.

Last, but not least, direct payment is not the only/ultimate influence a user can exert on a project. Some FOSS projects are made by companies that want them to see wide adoption, so user complaints (of non coding users) matter very much -- things like Mongo for example.

> If it takes away from their community and momentum

In my experience, what is more common is that people who would otherwise not contribute to an existing project for whatever reasons (e.g. complexity, bad experience w/ maintainer, etc) start contributing to a new project because these younger projects are generally more approachable.

People don't really jump ship from something they've invested time into unless it's very clear that something else is taking over.

Agreed. It's more like Competition == Improvement

No, fragmentation can be destructive.

Can you give an example? In my experience that isn't really the case. For example, there are bazillions vdom implementations and they are only where they are now in terms of perf because of the intense competition.

This was also the case with jQuery/Sizzle and friends back in the day. There's js-joda/moment/date-fns, underscore/lodash/ramda/just, css modules/styled-component/styletron, etc etc etc.

Lack of competition tends to lead to stagnation, and since js has such a large (and growing) community, you're never really going to be at a situation where major libraries will run out of community support due to competition of equal caliber.

Yes.

Read Coverity's account of building static analysis tools for C: https://cacm.acm.org/magazines/2010/2/69354-a-few-billion-li...

"The C language does not exist; neither does Java, C++, and C#. While a language may exist as an abstract idea, and even have a pile of paper (a standard) purporting to define it, a standard is not a compiler."

The immense fragmentation of C compilers makes it difficult to build static analyzers.

You're correct that the cost of fragmentation is seldom that there's a lack of resources around any single project. It's more that complementary products are much harder to build, because there's no standard for the product category.

Surely you can understand the downside of diffusing attention?

But also:

Change != !Improvement

So I'm not seeing the point here.

Change + Time == Improvement

I do miss Borland Turbo C++ v3.0...

In my imperfect memory, it was perfect.. (I couldn't go back though...)

turbo c 2.0 forever!

Welcome to developing in 2016-201X, were you spend 60% of your time configuring tooling, 35% developing test and 5% developing your app.

Sounds good to me. If I could spend 60 hours on developing the initial tooling, and if I could spend just 5 hours writing minimal code to get things working as I want, and spend the rest of the 35 hours on testing and making everything watertight, I'd call it a job well done.

It sounds awful, both for you and for the employer/ customer who pays you for only 5% of your time being actually spent in implementing features.

Features that break other features (or introduce vulnerabilities) because they haven't been through a basic testing are anti-features.

Sure. I don't write any tests (luckily I don't work on a business-critical system), and 10% of my time is dedicated to fixing features that were broken accidentally. And now? 90% of my time is still dedicated to developing new features.

Don't bother feeding the trolls, r00fus it's a lego developer, if their framework doesn't support they will rebuilt everything from the scratch or mark it was wont-fix, for devs like him is that we can have nice things.

Or stick to something that works for you and keep using the same tool over and over again.

No one is forcing you to use the latest bundler / tool / programming language. Let others experiment. You’ll be happy to reap the benefits of their work when something mature comes out of it.

> No one is forcing you to use the latest bundler / tool / programming language.

Tell me that when you get turned down in a job interview because you don't know <JS framework of the year>.

Try working on your positioning so that you are not hitched to the <JS framework of the year>. You will forever be competing with the low end of the market if you cannot market yourself.

Your advice basically tells them to get out of JS development because businesses continually hitch themselves to <JS framework of the year>.

This stuff comes up in interviews. Trying to avoid answering direct questions about a framework and answering with "Well I can learn it really quickly because I'm a good vanilla JS Dev" doesn't fly all the time. If you can't answer direct questions about a framework, they will pass on you if they get someone who can answer those questions.

It has nothing to do with marketing yourself.

What you described is a hiring problem. Marketing is knowing who your buyer is and finding creative ways to get their attention.

Found the MBA/project-lead guy. The moment you start working on management, that's the moment you stopped being a "developer".

I don't think that's the only interpretation. You can also work on moving into different parts of development. This problem exists everywhere, but is currently the most extreme in front-end web-app dev. Move the back end, ops, etc..

Isn't that to your benefit though?

There are tons of companies that are going to do certain things you aren't going to be a fan of. Isn't it better to find out they're not that into mature platforms and prefer the latest trend during the interview and not on the job?

> Or stick to something that works for you and keep using the same tool over and over again.

(in JS ecosystem)

1. It's really hard to find something that works

2. It's really hard to figure out all the dependencies, and configs, and plugins, and conventions, and ..., and ... for something that works

3. Once you have it figured out, each and every moving part, including the tool itself, will get updated with deprecations and breaking changes.

I agree in a lot of environments, but web/js build tools seem to have a high frequency of fragmenting and becoming abandoned before any real long-term maturity is established.

It sure looks that way if you follow the news, but my webpack config has barely changed for two years now and I'm still getting work done.

My gulp configs have barely changed in 4 years. But we have to convince people to work together and stop jumping ship rather than ignoring the process. I don't think Node has this figured out yet unfortunately. Too much hubris.

> No one is forcing you to use the latest bundler / tool / programming language

Except everyone is using them and you get quickly outdated, specially if you are looking for a job with heavy experience on python, php and asp.net web development. The market already shifted to "3 Years worth of experience on Parcel".

THIS.

I used to love writing code and building stuff from scratch. Nowadays it's exactly what you said. I spend more time configuring stuff and finding tools that work well together than actually writing the underlying code that makes the app or the website work.

I don't agree at all. Building things from scratch has never been easier. The difference is, today you can build highly complex stuff "from scratch" as easy as simple things. Components are ready to use, javascript and node can steer robots, machines, drive mobile and desktop applications, etc. All of this is set up like nothing.

In the same time it costs you to boot up notepad.exe and create a HTML wireframe, create-react-app/electron/etc has already set up an application that is modular, knows dependencies and resources, is debuggable, can hot reload, etc. The time you would spend to get this manually ... it wouldn't even be fair to compare.

> In the same time it costs you to boot up notepad.exe and create a HTML wireframe, create-react-app/electron/etc has already set up an application that is modular, knows dependencies and resources, is debuggable, can hot reload, etc. The time you would spend to get this manually ... it wouldn't even be fair to compare.

Most of the times you don't need any of those things, you don't need modularization, you don't need a dependency manager, you don't need a debuggable version (because you are working on plain versions without minifies or module bundlers that compress your code), you don't need hot-reload (because you aren't using a transpiler/compiler-to-js), you don't need the hot-and-untested framework, sometimes you don't even need a source control.

The big difference between that and going from scratch is that you choose what you want based on your needs not because everyone or a framework tells you "this is the right path", current state of web development increases "lego developers" to rise and shine like if they were expert.

If you don't need it, what forces you to use any of it. Has the browser stopped accepting .js and .html files? It hasn't. Will we ever go back to where that was all that was needed? I sure hope that will never happen, because there was nothing glorious or great about that time. It's a Freudian slip when someone thinks back and goes "oh how easy it was." It just wasn't. It used to be the most limited, restricted, crippled, tough and volatile environment possible. Nothing meant manual labour as much as the old web. From chasing dependencies by hand, fixing issues across browsers, nothing could be re-used, it was plain horrible.

How about you don't do that, then? What is stopping you from developing things like you used to? Those older tools still work.

Go try to find a job that doesn't require any of the new tooling experience or look at the other extreme... looks for those asking 15-years proven experience of Cobol.

35% developing tests? What great institution do you work for?

They probably code using Barliman[1] ;-) </joke>

[1] https://github.com/webyrd/Barliman

90% developer tests here

Depends if they're talking about adding tests or battling tests/test frameworks to just get something out.

Oh man, this is my life. Spurious integration tests that are critical, but very complex and often times have timeouts in our test runner depending on how many builds are going in there.

I might take 1 day on the feature, and then 3 more days just getting it past the testing gauntlet

Slack /s

Cute that you think this started in 2016...

To be fair, i originally wanted to put 2010 but there are so many butthurt nodejs fans that will get easily offended.

Take it down another decade. Or two. There are versions of Old/Super/Hyper in libraries and frameworks for Java, Perl, Python... Once you get the Internet, the hype cycle keeps speeding up

Hey dude, it looks like you've been shadowbanned for years and I don't immediately see why. Just vouched for this one. Thanks for your comments hopefully it all works out this holiday.

Have you ever tried a tool like https://github.com/facebookincubator/create-react-app ? It makes your comment totally irrelevant.

Unfortunately the whole world isn't developing a react app. And the fact that create-react-app even exists is definitely proving the point!

Is not about React, it is about tools that makes our life easier. If you want you can stick to ES5, no frameworks, no tools but good luck scaling your app to work with a big teams.

Yea, as a user of CRNA (create react native app) with a moderately simple app, dependency hell is something we're already in. We don't see a choice, for reasons, but CNRA is definitely not somehow above these problems.

Node/JS in general has a pretty terrible track record for me with version hell.

Strong technical leadership and defining clear code boundaries is the secret sauce to scaling successfully. The shiniest tooling will not save your team.

IMHO, unless your company is also working on a tool like Bazel or Buck, you don't really have a team scalability problem.

True, but Old, Super, and Hyper together represent a deep and productively adversarial exploration of the problem space -- each trying to best its predecessor. The overall problem space benefits, even as each package individually ages into senescent complexity.

I use create-react-app and make sure I don't need to eject so (I guess) I use webpack under the hood, which I never had to learn. If CRA switches to parceljs and makes the build twice as fast, I'm all for it!

I normally share the same sentiment unless the tooling truly is much better than its predecessors. This looks pretty easy to use and fast. If it delivers on those two promises, it's worthy of further consideration by the community.

I share your frustration.

However, this tool actually do useful work, based on quick glance I made. So maybe don't discount it just yet.

But again, I share your frustration.

This sounds good to me. Encapsulate and simplify existing tooling based on the communities experience with it, then extend and add complexity as needed. As the development environment changes, we will constantly have to update our tools to make it simple for the basic 80% of cases.

AKA Evolution