1. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!"
2. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast."
3. "SuperTool™ v1.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension."
...repeat for a while...
10. "Introducing SuperTool™ v2.0.0, which now has a more flexible API and configuration , allowing many former hacks to be done in a straightforward way."
11. "SuperTool™ v2.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension."
...repeat for a while...
20. "Introducing SuperTool™ v3.0.0, with a whole new, flexible, pipeline based API. Everything is a plugin! There's even a plugin to send email!"
21. "Ugh, SuperTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!"
22. "Introducing HyperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast."
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.
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.
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 ;-)
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.
> 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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.
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..
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?
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.
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".
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.
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.
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
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.
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.
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.
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.
1. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!"
2. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast."
3. "SuperTool™ v1.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension."
...repeat for a while...
10. "Introducing SuperTool™ v2.0.0, which now has a more flexible API and configuration , allowing many former hacks to be done in a straightforward way."
11. "SuperTool™ v2.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension."
...repeat for a while...
20. "Introducing SuperTool™ v3.0.0, with a whole new, flexible, pipeline based API. Everything is a plugin! There's even a plugin to send email!"
21. "Ugh, SuperTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!"
22. "Introducing HyperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast."