11 ms·
The eternal cycle of developer tool bullshit: 1. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!" 2. "Introducing Supe
by stupidcar 9y ago
The eternal cycle of developer tool bullshit:
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."
- SadWebDeveloper 9y agoWelcome to developing in 2016-201X, were you spend 60% of your time configuring tooling, 35% developing test and 5% developing your app.
- awalton 9y agoCute that you think this started in 2016...
- SadWebDeveloper 9y agoTo be fair, i originally wanted to put 2010 but there are so many butthurt nodejs fans that will get easily offended.
- dotandimet 9y agoTake 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
- doublerebel 9y agoHey 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.
- nip 9y agoOr 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.
- SadWebDeveloper 9y ago> 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".
- weego 9y agoI 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.
- deoxxa 9y agoIt 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.
- doublerebel 9y agoMy 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.
- nathan_long 9y ago> 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>.
- djstein 9y ago35% developing tests? What great institution do you work for?
- IanCal 9y agoDepends if they're talking about adding tests or battling tests/test frameworks to just get something out.
- iamcasen 9y agoOh 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
- je42 9y ago90% developer tests here
- SadWebDeveloper 9y agoSlack /s
- JepZ 9y agoThey probably code using Barliman[1] ;-) </joke> [1] https://github.com/webyrd/Barliman https://github.com/webyrd/Barliman
- borellvi 9y agoHave you ever tried a tool like https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app ? It makes your comment totally irrelevant.
- Boxxed 9y agoUnfortunately the whole world isn't developing a react app. And the fact that create-react-app even exists is definitely proving the point!
- borellvi 9y agoIs 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.
- lhorie 9y agoIMHO, unless your company is also working on a tool like Bazel or Buck, you don't really have a team scalability problem.
- notheguyouthink 9y agoYea, 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.
- tropshop 9y agoStrong technical leadership and defining clear code boundaries is the secret sauce to scaling successfully. The shiniest tooling will not save your team.
- at-fates-hands 9y agoTHIS. 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.
- cortesoft 9y agoHow about you don't do that, then? What is stopping you from developing things like you used to? Those older tools still work.
- SadWebDeveloper 9y agoGo 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.
- mlsarecmg 9y agoI 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.
- SadWebDeveloper 9y ago> 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.
- hannofcart 9y agoSounds 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.
- nimchimpsky 9y agoThat sounds awful
- Udik 9y agoIt 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.
- r00fus 9y agoFeatures that break other features (or introduce vulnerabilities) because they haven't been through a basic testing are anti-features.
- Udik 9y agoSure. 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.
- SadWebDeveloper 9y agoDon'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.
- meebs 9y agoPart of it is you already have SuperTool™ and teaching your team other tools or creating new ones initially seems more complicated than SuperTool™. Eventually paradigms to avoid the problems you face or better solutions are discovered, iterated on, and now someone can start a "better" one without fear of breaking backwards compatibility -- because there is no backwards. :)
- chatmasta 9y agoGod forbid we improve existing tools. What exactly is your problem here? Do you think we should all be using the Borland C++ compiler too?
- icholy 9y agoChange != Improvement.
- chatmasta 9y agoDoes 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.
- lhorie 9y agoAgreed. It's more like Competition == Improvement
- brucephillips 9y agoNo, fragmentation can be destructive.
- lhorie 9y agoCan 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.
- wppick 9y agoThis 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.
- johnwheeler 9y agoI 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.
- desireco42 9y agoI 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.
- pacoverdi 9y agoI 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!
- amazingman 9y agoThe cycle described here is perfectly acceptable in principle, not to mention unavoidable in practice. Our developer tools will stop changing when humans stop changing.
- deleted 9y ago[deleted]
- brucephillips 9y agoNot 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.
- iinnii 9y agoHaving one tool that is configurable for all problems often becomes a mess and even harder to use.
- brucephillips 9y agoYou're correct, of course. I consider "simplicity" to be a feature, which is almost always at odds with other features.
- yoz-y 9y agoBut 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.
- mempko 9y agoYou have never used Tex....
- redler 9y agoTrue, 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.
- igloofoo 9y agoAKA Evolution