9 ms·

This is a solid list, but front end dev has gotten a bit absurd. I feel like I need to install 86,000 dependencies via NPM to do something that server-side fra

This is a solid list, but front end dev has gotten a bit absurd. I feel like I need to install 86,000 dependencies via NPM to do something that server-side frameworks already figured out. I was following a simple Vue/Vuex tutorial the other day and my node_modules directory was 200MB+. Use yarn or npm to install XYZ.... What's the difference? Why do I have to google this as step 0? Why do you assume I know the intricacies of Webpack? Is this tutorial for Webpack 4 or Webpack 3? I'm exaggerating a bit but honestly, I get the same feeling of rage that I used to get trying to understand the box model during the IE 6 era.

taesu 8y ago
npm hell, I assume it's still a thing?
- Zelphyr 8y ago
  Oh, yeah, it is. I used to love npm and then didn’t use it for several years. I’ve gone back to it lately and find myself screaming “what have you people done?!” on a regular basis now. And while we’re on the subject of package managers; do we really need so many? I know npm is terrible but it seems like everyone has decided to create their own now. I swear to god I had to use a package manager to install a package manager the other day.
  - acemarke 8y ago
    There's only two primary package managers for Javascript that are in common use. (For point of comparison, Java and Python are in a similar situation: Maven and Gradle, pip / pipenv / poetry / pip-tools, etc.) NPM is the package manager built by the NPM company. It's included with Node. Primary selling points: it's "official", and NPM has included the package auditing tech they purchased. Yarn was created by a team from Facebook, at a time when NPM (v2/v3) was known for being slow. Currently developed by a somewhat broader group of contributors. Primary selling points: more consistent installation behavior, "offline mirror" installations. Both tools install packages from the same servers run by the NPM company. The speeds are relatively similar these days, but that's at least partly because the competition pushed NPM to improve. And yes, Yarn is often installed via NPM, although you can install it other ways too. Both teams are working on solutions to the `node_modules` size issue. NPM is building a new package manager called "Tink" from scratch. Yarn has come up with a technique dubbed "Plug 'n Play". Both look potentially interesting. There's other package managers out there, but they're rarely used. For example, PNPM uses symlinks in each project to a global package cache, rather than installing a separate copy of a package for each project. I happen to favor Yarn myself, largely because the offline mirror feature makes it easy to have consistent, fast installs in CI builds and across platforms [0]. [0] https://blog.isquaredsoftware.com/2017/07/practical-redux-part-9-managing-dependencies/#managing-dependency-packages-for-offline-installation https://blog.isquaredsoftware.com/2017/07/practical-redux-pa...
    - fineline 8y ago
      There is a third alternative with a clear advantage over these two. PNPM is an NPM client that installs versioned packages into a central location and uses file system links within the 'node_modules' folder of individual projects. For a typical developer with many local projects this is a huge disk space saver. It also uses the original and much clearer nested structure of node_modules. I don't know why NPM didn't adopt the shared package approach, or why yarn didn't either, but PNPM gets it right.
      - acemarke 8y ago
        I did list that one in my comment :)
    - talkingtab 8y ago
      Thanks for the write up! I used yarn when NPM was very slow, but I ran into some issues when I would use yarn, then later use npm or vice versa. I eventually went back to NPM and have been happy with the results. But I don't mix the two at all. So that is a question going forward - will mixing npm and yarn in the same installation result in problems and will the result be exactly the same? If not, it would be helpful to understand how the results differ.
pojzon 8y ago
I think currently front end development becomes a bit messy. One could compare it to a wild west. And most likely its caused by misusage of javascript. Typescript is now just a "lets learn less competent ppl how to write frontend", technologies change too fast and have too many holes. Young folks want to be recognized and jump from one bandwagon to another.. This whole mess could use some refined standarization enforced by browsers (like apple store process) Ps. Sorry for bringing so many topics here but situation is that bad and i didnt even mention security..
- juddlyon 8y ago
  Ha! Good points. Glad to see Typescript on this list, it's JS for adults.
ng12 8y ago
What's a language/domain/framework that's _not_ like this? After spending a few weeks struggling with Bazel and Spring you'll not convince me Java is any better.
- hactually 8y ago
  Had a colleague try and show me, a non Java guy, modern Java + maven + archetypes... It did a lot of downloading, a lot of building and then built something which, when we ran it, hung. I still have no idea what the demo was supposed to show me. Going to continue working with Go
- zmmmmm 8y ago
  Actually, Java / JEE / Spring is the analogy I use when talking to people about the massive of complexity that is being created in the JavaScript ecosystem at the moment. As you create it, new complexity looks "free" because the creator understands it perfectly (they are creating it!) and their nearest peers understand it too (they have the same immediate problem as the creator!). But it's a one way path - like navigating through a complex maze - going forward is easy and you come out the other size eventually, but nobody will ever be able to retrace those steps. In the longer term the complexity has an enormously high price, and eventually it collapses in on itself - new developers just won't use it. Other ecosystems are complex but not at the same scale as those two IMHO, because different ecosystems seem to put a different price on complexity.
- JamesBarney 8y ago
  .NET has some warts but it's pretty plug and play. Exception are xamarin, which I give them a pass for because most cross platform technologies are a little rough getting started, and office 365 add-ons. I don't have any direct experience but I also assuming sharepoint is awful.
  - GordonS 8y ago
    I use ASP.NET Core MVC, and it's wonderful. ASP.NET has really matured well, and it's honestly a joy to use.
burnt_toast 8y ago
It's frustrating how the go to solution for a problem tends to be to install another module. I agree it's not smart to keep reinventing the wheel, but when the solution takes less than 15 minutes to implement the recommended answer shouldn't be another module.
- winstonewert 8y ago
  why? I mean it takes far less than 15 minutes to install a module, so why should I implement it myself?
  - jenscow 8y ago
    Like left-pad? By adding more 3rd party dependencies (and theirs) you're increasing risk.
    - djtriptych 8y ago
      You’re increasing risk by writing it yourself too.
      - aldoushuxley001 8y ago
        Not if it's written in a language like e.g. Python with Django framework, where theres generally one or only a few accepted best implementations. It means there's less leaks through the cracks because everything is better integrated instead of loosely tied together.
      - jenscow 8y ago
        Not if it's something that takes 15 minutes to implement :)
  - Chris_Newton 8y ago
    Importing anything into a project, no matter how small, creates a new dependency. Any additional dependency introduces, among other costs: * a potential point of failure * a potential source of security vulnerabilities * a potential legal liability and maybe some licensing constraints, and * an additional aspect that needs to be maintained indefinitely and understood by any future developers. Accepting all of this just to save a few minutes writing a simple function and maybe a test or two doesn’t scale very well. At best, it is replacing a superficial problem with a deep set of extra and ongoing responsibilities. This is before we consider the time required to find and evaluate a suitable package, and even then, there is no guarantee that some random small NPM package from a source you’ve never heard of will be any better than what you’d have written yourself if you’re a halfway decent programmer.
nishmastime 8y ago
I think it's weird to compare server application development to client development which is an entirely different beast. Client development on any platform is more complicated than the server stack. Back-end API devs have a much simpler job for most apps too. We as back-end devs like to pretend otherwise even though our app runs on just one machine.
- deleted 8y ago
  [deleted]
- freedomben 8y ago
  > Back-end API devs have a much simpler job for most apps too. We as back-end devs like to pretend otherwise even though our app runs on just one machine. I don't see how you could possibly say this in such general terms. Every app is so different. Even simple crud apps of any size are not running on "just one machine." Even most small backends have at least an API server and a job server, plus database(s) and queue(s) for communicating, plus DNS, TLS certs, etc. Sometimes the front end is much more complicated, sometimes it's not. There's really no way to generally compare without being wrong 50% of the time.
  - AznHisoka 8y ago
    Yep, sometimes the front end is more complicated - it depends on the application. Generally speaking though, the hardest problems in the backend are much harder than the hardest problems in the front-end. Like, I'm sure the PhD's Google are hiring are not working on front-end stuff.
- erik_seaberg 8y ago
  We can't even integration test all our team's portion of the system on one machine with kafka and datastores mocked out. Production is up in the thousands; I added about a dozen for the weekend just for a backfill.
kevinflo 8y ago
This (or something like it) is always the top thread. I wish this was something the frontend community cheered about, not lamented. Those 200MB of node modules are developers ad-hoc cobbling together an alternative to xcode and android studio, except entirely modular and where we have complete control. Serious application development for the open web is hamstrung by limitations and definitely in an awkward growth phase, but it's marching towards a possible future of competing with native mobile apps and the two companies to which they're entirely beholden. To me, 200MB of tooling is not a sign of cruft, but of steady and imperfect progress. Edit: and for the record, xcode is a 13.8GB install
- evanriley 8y ago
  > Edit: and for the record, xcode is a 13.8GB install Not to take anything away from your post, but you're comparing a complete IDE & Simulator with dependencies for building a website.
  - hnmonkey 8y ago
    Yeah, it is completely missing me how web application dependency libraries relate in any way to an IDE for building applications. I don't get this argument and it doesn't seem to me like it makes sense. Perhaps I'm wrong and there's a connection I'm not seeing. Can anyone clarify this?
    - acemarke 8y ago
      The point is that build tools take up disk space, and need to be installed. IDEs like XCode and Visual Studio bring along large quantities of libraries, headers, and other aspects of a C++ / C# / Swift / $LANG build toolchain. Front-end web dev now consists in large part of building highly interactive applications, not just static sites. That requires tooling. Therefore, it's not unreasonable to expect that the necessary tools will take up space, and there's plenty of prior precedent from other languages.
    - ng12 8y ago
      The lion's share of my node_modules are related to my development environment -- Webpack, Typescript, Babel, SASS, Jest, etc. A very small portion actually gets bundled into the dist.
kokokokoko 8y ago
I understand your frustration. One thing I'd like to mention is that a comment similar to your comment is frequently mentioned in any HN post about typical frontend/JavaScript topics. So frequently, that I'm not sure what it adds to the discussion at this point. It's possible you are not aware of that and just wanted to let you know.
- smokeyj 8y ago
  Honestly I think it's just a meme at this point. Don't fight it. Just mention something about Electron being bloated and rake in that sweet sweet karma. Hey, has anyone else noticed how bloated Electron is? I bet it's all those rootin tootin NPM packages!
- juddlyon 8y ago
  I appreciate the way you relayed this. My intention wasn't to troll or beat a dead horse. I think a lot of us are spending too much time troubleshooting dependency nightmares versus actually solving problems for our clients/employers. The popularity of projects like Laravel Mix indicate that there may be a problem grokking all this stuff.
ui-explorer12 8y ago
Why would someone need to preemptively learn both React and Vue? I can get saying you want to understand how they accomplish their respective roles, but is there an actual (non-crazy) scenario where your core, day-to-day job depends on really knowing both? Or is that the whole point? Am I erroneously assuming "learn" means really deep knowledge(which for me really digging into any single one of these would be enough) when it means "known enough to pass a job interview when I ladder-up to the next company"?
- karmakaze 8y ago
  I'm primarily a back-end dev but do some front end work which is mostly React. I didn't like it much and thought there should be something better. Learned Vue on my own time, which was only a few hours. Did a super simple side project to work around some common gotchas. So glad I did, now use Vue for all new work and encourage people at work on greenfield projects. Now, I'm playing around with alternate state management, vue-stash looks good so far, haven't run into any issues with it but it's early on. > Vue 3 is being written in TypeScript This is such great news. Just did my first Vue2/ts app and it's so much nicer. Wasn't easy to find all the info, there should a good Vue2/ts tutorial somewhere.
  - uhoh-itsmaciek 8y ago
    What did you dislike about React? What does Vue do better?
    - karmakaze 8y ago
      The 'type'ing with PropTypes which required much typing. Also having to edit 4 or more places to add one thing. Let's see there's where the UI calls the action, the action, the api request, the reducer and finally the render of the data along with any new proptypes you introduced copied to each consumer. I imagine it could be better with a different state management library or maybe ReactReason or TypeScript. The other thing I really like about Vue is how the layout and logic stay separated. With React and JSX there's always code all over the place: class methods, regular methods, lambdas, inline '&&' throughout the JSX. The way Vue handles events is far simpler. I do however see the value in all of this with React when working on a large team. It all adds up to safety. I haven't yet worked on a Vue app that has grown complex enough to feel any of that necessary as where even a simple React app's structure is already complex.
olingern 8y ago
I can't really understand the sentiment that front-end dev is absurd. I started with .NET years ago and find _anything_ that becomes 'standard' in the front-end more approachable than the constant reinventing of the wheel / new framework releases MS did circa 2004 - 2014. It was something like: - Learn ASP, opps we meant ASP.NET web forms. Actually, we meant .NET MVC. - Oh no, the world wants APIs ... please learn WCF. Actually, we meant .NET Web API. It seems things have finally calmed down with .NET core. But, along with the MS frameworks you also need to have good command over C# and data access / manipulation utilities such as LINQ, Entity Framework, etc. If you happen to be working with MSSQL Server as I was -- you had to learn it and all of its quirks. I will say the tooling, once learned, was pretty good everywhere (except WCF in terms of configuration). I can't say that for a lot of front-end utilities, which I think results in a lot of configuration pain and StackOverflow searches. I do find the answers / guidance on configuring front-end much higher quality than most things in the MS ecosystem, though. ____ My intent here isn't to bash MS so much as it is to point out that the breadth of things you actually have to learn for front-end development is less than some other ecosystems. We're a part of a privileged profession where income and demand is high, so I do expect re-skilling to be an ongoing process.
- calibas 8y ago
  A while ago you could get away with doing front-end dev with nothing but a text editor and an FTP client, compared to those days I can see how things seem absurd now.
  - mcintyre1994 8y ago
    I know what you’re saying, but you still can. React/Vue can be included as a script tag. You won’t get a transpiler or a bundler or a linter or types, but you didn’t before with just a text editor either. And honestly if you just want to sprinkle some JavaScript onto a website it is easier now, you probably don’t need jquery to do your Dom stuff and you probably don’t need to worry about browser support for what you’re doing either.
    - commandlinefan 8y ago
mncharity 8y ago
2010: The food is poor, the seats are uncomfortable, the wifi is slow, and we're running half and hour late. 1910: We dream of human flight. 2018: So many dependencies; so much disk; who can understand why it all exists; how can anyone stay current; how can you trust it all. 1981: We dream of reusable software, of assemblable software components, of sharing.
- digitaltrees 8y ago
  Absolutely awesome. Is it ok if I use this myself in the future?
  - mncharity 8y ago
    Disney/Berne-wise? CC0. Inspired by Louis CK's Everything Is Amazing And Nobody Is Happy. s/reusable software/code reuse/ was the phrase in use.
- ryanbrunner 8y ago
  I don't totally buy this comparison. People aren't bemoaning that shared libraries exist in the first place, they're arguing that Javascript's particular approach to them isn't great. Javascript didn't invent shared modules, but their particular approach has led to an explosion of libraries with marginal utility, an anemic at best standard library, dependency management that has historically been a big source of problems and still isn't as mature as other languages approaches, disk size explosion due to each individual application storing their own dependencies (and dependencies often storing different version of libraries in their dependencies). You don't see nearly as many arguments with say, Bundler and the gem ecosystem in ruby.
  - mncharity 8y ago
    > their particular approach has led to [...] So, paraphrasing part of that: it's too easy for too many people to share too small pieces of their code; and too easy to use them; which reduces the incentives for centralized monoliths? Ok. :P :) I'll agree that javascript's ease and culture of fine-grain sharing raises still regrettably-unaddressed needs for social and technical infrastructure beyond the "1990's CPAN, but now as a github ecosystem" currently in widespread use. > I don't totally buy this comparison. Hmm, so upon reflection, maybe that's right. Consider an "npm code quality can be abysmal" complaint. Which in part unpacks as "I wish it was harder for mediocre programmers to share their code". An analogy for "this airplane, is this slow wifi really the best they could do?" might be "Sorting on aggregate project-level stars is the best we can do? Really? Not even Consumer-Reports-like multi-attribute ratings?" In contrast, an "isn't npm horrible - there's so much bad code" seems more like "abysmal wifi... we should be driving instead". Pointing at the community-wide fine-grain sharing as the problem, rather than at associated technosocial debt, or at renormalized-by-success expectations. Yes, the npm ecosystem has various and serious flaws. But it still seems the closest we've yet managed to come to a large diverse community easily sharing code.
btbuildem 8y ago
I've made the decision to not use NPM, or any front-end build chain tools. Downsides: everyone else is using those things, it's not even an assumption, it's ground under their feet. Upsides: SO SIMPLE. make handles any build / deployment scripting. Localized dependencies. Nothing changes without me taking an explicit action.

taesu 8y ago

npm hell, I assume it's still a thing?

Zelphyr 8y ago
Oh, yeah, it is. I used to love npm and then didn’t use it for several years. I’ve gone back to it lately and find myself screaming “what have you people done?!” on a regular basis now. And while we’re on the subject of package managers; do we really need so many? I know npm is terrible but it seems like everyone has decided to create their own now. I swear to god I had to use a package manager to install a package manager the other day.
- acemarke 8y ago
  There's only two primary package managers for Javascript that are in common use. (For point of comparison, Java and Python are in a similar situation: Maven and Gradle, pip / pipenv / poetry / pip-tools, etc.) NPM is the package manager built by the NPM company. It's included with Node. Primary selling points: it's "official", and NPM has included the package auditing tech they purchased. Yarn was created by a team from Facebook, at a time when NPM (v2/v3) was known for being slow. Currently developed by a somewhat broader group of contributors. Primary selling points: more consistent installation behavior, "offline mirror" installations. Both tools install packages from the same servers run by the NPM company. The speeds are relatively similar these days, but that's at least partly because the competition pushed NPM to improve. And yes, Yarn is often installed via NPM, although you can install it other ways too. Both teams are working on solutions to the `node_modules` size issue. NPM is building a new package manager called "Tink" from scratch. Yarn has come up with a technique dubbed "Plug 'n Play". Both look potentially interesting. There's other package managers out there, but they're rarely used. For example, PNPM uses symlinks in each project to a global package cache, rather than installing a separate copy of a package for each project. I happen to favor Yarn myself, largely because the offline mirror feature makes it easy to have consistent, fast installs in CI builds and across platforms [0]. [0] https://blog.isquaredsoftware.com/2017/07/practical-redux-part-9-managing-dependencies/#managing-dependency-packages-for-offline-installation https://blog.isquaredsoftware.com/2017/07/practical-redux-pa...
  - fineline 8y ago
    There is a third alternative with a clear advantage over these two. PNPM is an NPM client that installs versioned packages into a central location and uses file system links within the 'node_modules' folder of individual projects. For a typical developer with many local projects this is a huge disk space saver. It also uses the original and much clearer nested structure of node_modules. I don't know why NPM didn't adopt the shared package approach, or why yarn didn't either, but PNPM gets it right.
    - acemarke 8y ago
      I did list that one in my comment :)
  - talkingtab 8y ago
    Thanks for the write up! I used yarn when NPM was very slow, but I ran into some issues when I would use yarn, then later use npm or vice versa. I eventually went back to NPM and have been happy with the results. But I don't mix the two at all. So that is a question going forward - will mixing npm and yarn in the same installation result in problems and will the result be exactly the same? If not, it would be helpful to understand how the results differ.

pojzon 8y ago

I think currently front end development becomes a bit messy. One could compare it to a wild west. And most likely its caused by misusage of javascript. Typescript is now just a "lets learn less competent ppl how to write frontend", technologies change too fast and have too many holes. Young folks want to be recognized and jump from one bandwagon to another.. This whole mess could use some refined standarization enforced by browsers (like apple store process) Ps. Sorry for bringing so many topics here but situation is that bad and i didnt even mention security..

juddlyon 8y ago
Ha! Good points. Glad to see Typescript on this list, it's JS for adults.

ng12 8y ago

What's a language/domain/framework that's _not_ like this? After spending a few weeks struggling with Bazel and Spring you'll not convince me Java is any better.

hactually 8y ago
Had a colleague try and show me, a non Java guy, modern Java + maven + archetypes... It did a lot of downloading, a lot of building and then built something which, when we ran it, hung. I still have no idea what the demo was supposed to show me. Going to continue working with Go
zmmmmm 8y ago
Actually, Java / JEE / Spring is the analogy I use when talking to people about the massive of complexity that is being created in the JavaScript ecosystem at the moment. As you create it, new complexity looks "free" because the creator understands it perfectly (they are creating it!) and their nearest peers understand it too (they have the same immediate problem as the creator!). But it's a one way path - like navigating through a complex maze - going forward is easy and you come out the other size eventually, but nobody will ever be able to retrace those steps. In the longer term the complexity has an enormously high price, and eventually it collapses in on itself - new developers just won't use it. Other ecosystems are complex but not at the same scale as those two IMHO, because different ecosystems seem to put a different price on complexity.
JamesBarney 8y ago
.NET has some warts but it's pretty plug and play. Exception are xamarin, which I give them a pass for because most cross platform technologies are a little rough getting started, and office 365 add-ons. I don't have any direct experience but I also assuming sharepoint is awful.
- GordonS 8y ago
  I use ASP.NET Core MVC, and it's wonderful. ASP.NET has really matured well, and it's honestly a joy to use.

burnt_toast 8y ago

It's frustrating how the go to solution for a problem tends to be to install another module. I agree it's not smart to keep reinventing the wheel, but when the solution takes less than 15 minutes to implement the recommended answer shouldn't be another module.

winstonewert 8y ago
why? I mean it takes far less than 15 minutes to install a module, so why should I implement it myself?
- jenscow 8y ago
  Like left-pad? By adding more 3rd party dependencies (and theirs) you're increasing risk.
  - djtriptych 8y ago
    You’re increasing risk by writing it yourself too.
    - aldoushuxley001 8y ago
      Not if it's written in a language like e.g. Python with Django framework, where theres generally one or only a few accepted best implementations. It means there's less leaks through the cracks because everything is better integrated instead of loosely tied together.
    - jenscow 8y ago
      Not if it's something that takes 15 minutes to implement :)
- Chris_Newton 8y ago
  Importing anything into a project, no matter how small, creates a new dependency. Any additional dependency introduces, among other costs: * a potential point of failure * a potential source of security vulnerabilities * a potential legal liability and maybe some licensing constraints, and * an additional aspect that needs to be maintained indefinitely and understood by any future developers. Accepting all of this just to save a few minutes writing a simple function and maybe a test or two doesn’t scale very well. At best, it is replacing a superficial problem with a deep set of extra and ongoing responsibilities. This is before we consider the time required to find and evaluate a suitable package, and even then, there is no guarantee that some random small NPM package from a source you’ve never heard of will be any better than what you’d have written yourself if you’re a halfway decent programmer.

nishmastime 8y ago

I think it's weird to compare server application development to client development which is an entirely different beast. Client development on any platform is more complicated than the server stack. Back-end API devs have a much simpler job for most apps too. We as back-end devs like to pretend otherwise even though our app runs on just one machine.

deleted 8y ago
[deleted]
freedomben 8y ago
> Back-end API devs have a much simpler job for most apps too. We as back-end devs like to pretend otherwise even though our app runs on just one machine. I don't see how you could possibly say this in such general terms. Every app is so different. Even simple crud apps of any size are not running on "just one machine." Even most small backends have at least an API server and a job server, plus database(s) and queue(s) for communicating, plus DNS, TLS certs, etc. Sometimes the front end is much more complicated, sometimes it's not. There's really no way to generally compare without being wrong 50% of the time.
- AznHisoka 8y ago
  Yep, sometimes the front end is more complicated - it depends on the application. Generally speaking though, the hardest problems in the backend are much harder than the hardest problems in the front-end. Like, I'm sure the PhD's Google are hiring are not working on front-end stuff.
erik_seaberg 8y ago
We can't even integration test all our team's portion of the system on one machine with kafka and datastores mocked out. Production is up in the thousands; I added about a dozen for the weekend just for a backfill.

kevinflo 8y ago

This (or something like it) is always the top thread. I wish this was something the frontend community cheered about, not lamented. Those 200MB of node modules are developers ad-hoc cobbling together an alternative to xcode and android studio, except entirely modular and where we have complete control. Serious application development for the open web is hamstrung by limitations and definitely in an awkward growth phase, but it's marching towards a possible future of competing with native mobile apps and the two companies to which they're entirely beholden. To me, 200MB of tooling is not a sign of cruft, but of steady and imperfect progress. Edit: and for the record, xcode is a 13.8GB install

evanriley 8y ago
> Edit: and for the record, xcode is a 13.8GB install Not to take anything away from your post, but you're comparing a complete IDE & Simulator with dependencies for building a website.
- hnmonkey 8y ago
  Yeah, it is completely missing me how web application dependency libraries relate in any way to an IDE for building applications. I don't get this argument and it doesn't seem to me like it makes sense. Perhaps I'm wrong and there's a connection I'm not seeing. Can anyone clarify this?
  - acemarke 8y ago
    The point is that build tools take up disk space, and need to be installed. IDEs like XCode and Visual Studio bring along large quantities of libraries, headers, and other aspects of a C++ / C# / Swift / $LANG build toolchain. Front-end web dev now consists in large part of building highly interactive applications, not just static sites. That requires tooling. Therefore, it's not unreasonable to expect that the necessary tools will take up space, and there's plenty of prior precedent from other languages.
  - ng12 8y ago
    The lion's share of my node_modules are related to my development environment -- Webpack, Typescript, Babel, SASS, Jest, etc. A very small portion actually gets bundled into the dist.

kokokokoko 8y ago

I understand your frustration. One thing I'd like to mention is that a comment similar to your comment is frequently mentioned in any HN post about typical frontend/JavaScript topics. So frequently, that I'm not sure what it adds to the discussion at this point. It's possible you are not aware of that and just wanted to let you know.

smokeyj 8y ago
Honestly I think it's just a meme at this point. Don't fight it. Just mention something about Electron being bloated and rake in that sweet sweet karma. Hey, has anyone else noticed how bloated Electron is? I bet it's all those rootin tootin NPM packages!
juddlyon 8y ago
I appreciate the way you relayed this. My intention wasn't to troll or beat a dead horse. I think a lot of us are spending too much time troubleshooting dependency nightmares versus actually solving problems for our clients/employers. The popularity of projects like Laravel Mix indicate that there may be a problem grokking all this stuff.

ui-explorer12 8y ago

Why would someone need to preemptively learn both React and Vue? I can get saying you want to understand how they accomplish their respective roles, but is there an actual (non-crazy) scenario where your core, day-to-day job depends on really knowing both? Or is that the whole point? Am I erroneously assuming "learn" means really deep knowledge(which for me really digging into any single one of these would be enough) when it means "known enough to pass a job interview when I ladder-up to the next company"?

karmakaze 8y ago
I'm primarily a back-end dev but do some front end work which is mostly React. I didn't like it much and thought there should be something better. Learned Vue on my own time, which was only a few hours. Did a super simple side project to work around some common gotchas. So glad I did, now use Vue for all new work and encourage people at work on greenfield projects. Now, I'm playing around with alternate state management, vue-stash looks good so far, haven't run into any issues with it but it's early on. > Vue 3 is being written in TypeScript This is such great news. Just did my first Vue2/ts app and it's so much nicer. Wasn't easy to find all the info, there should a good Vue2/ts tutorial somewhere.
- uhoh-itsmaciek 8y ago
  What did you dislike about React? What does Vue do better?
  - karmakaze 8y ago
    The 'type'ing with PropTypes which required much typing. Also having to edit 4 or more places to add one thing. Let's see there's where the UI calls the action, the action, the api request, the reducer and finally the render of the data along with any new proptypes you introduced copied to each consumer. I imagine it could be better with a different state management library or maybe ReactReason or TypeScript. The other thing I really like about Vue is how the layout and logic stay separated. With React and JSX there's always code all over the place: class methods, regular methods, lambdas, inline '&&' throughout the JSX. The way Vue handles events is far simpler. I do however see the value in all of this with React when working on a large team. It all adds up to safety. I haven't yet worked on a Vue app that has grown complex enough to feel any of that necessary as where even a simple React app's structure is already complex.

olingern 8y ago

I can't really understand the sentiment that front-end dev is absurd. I started with .NET years ago and find _anything_ that becomes 'standard' in the front-end more approachable than the constant reinventing of the wheel / new framework releases MS did circa 2004 - 2014. It was something like: - Learn ASP, opps we meant ASP.NET web forms. Actually, we meant .NET MVC. - Oh no, the world wants APIs ... please learn WCF. Actually, we meant .NET Web API. It seems things have finally calmed down with .NET core. But, along with the MS frameworks you also need to have good command over C# and data access / manipulation utilities such as LINQ, Entity Framework, etc. If you happen to be working with MSSQL Server as I was -- you had to learn it and all of its quirks. I will say the tooling, once learned, was pretty good everywhere (except WCF in terms of configuration). I can't say that for a lot of front-end utilities, which I think results in a lot of configuration pain and StackOverflow searches. I do find the answers / guidance on configuring front-end much higher quality than most things in the MS ecosystem, though. ____ My intent here isn't to bash MS so much as it is to point out that the breadth of things you actually have to learn for front-end development is less than some other ecosystems. We're a part of a privileged profession where income and demand is high, so I do expect re-skilling to be an ongoing process.

calibas 8y ago
A while ago you could get away with doing front-end dev with nothing but a text editor and an FTP client, compared to those days I can see how things seem absurd now.
- mcintyre1994 8y ago
  I know what you’re saying, but you still can. React/Vue can be included as a script tag. You won’t get a transpiler or a bundler or a linter or types, but you didn’t before with just a text editor either. And honestly if you just want to sprinkle some JavaScript onto a website it is easier now, you probably don’t need jquery to do your Dom stuff and you probably don’t need to worry about browser support for what you’re doing either.
  - commandlinefan 8y ago

mncharity 8y ago

2010: The food is poor, the seats are uncomfortable, the wifi is slow, and we're running half and hour late. 1910: We dream of human flight. 2018: So many dependencies; so much disk; who can understand why it all exists; how can anyone stay current; how can you trust it all. 1981: We dream of reusable software, of assemblable software components, of sharing.

digitaltrees 8y ago
Absolutely awesome. Is it ok if I use this myself in the future?
- mncharity 8y ago
  Disney/Berne-wise? CC0. Inspired by Louis CK's Everything Is Amazing And Nobody Is Happy. s/reusable software/code reuse/ was the phrase in use.
ryanbrunner 8y ago
I don't totally buy this comparison. People aren't bemoaning that shared libraries exist in the first place, they're arguing that Javascript's particular approach to them isn't great. Javascript didn't invent shared modules, but their particular approach has led to an explosion of libraries with marginal utility, an anemic at best standard library, dependency management that has historically been a big source of problems and still isn't as mature as other languages approaches, disk size explosion due to each individual application storing their own dependencies (and dependencies often storing different version of libraries in their dependencies). You don't see nearly as many arguments with say, Bundler and the gem ecosystem in ruby.
- mncharity 8y ago
  > their particular approach has led to [...] So, paraphrasing part of that: it's too easy for too many people to share too small pieces of their code; and too easy to use them; which reduces the incentives for centralized monoliths? Ok. :P :) I'll agree that javascript's ease and culture of fine-grain sharing raises still regrettably-unaddressed needs for social and technical infrastructure beyond the "1990's CPAN, but now as a github ecosystem" currently in widespread use. > I don't totally buy this comparison. Hmm, so upon reflection, maybe that's right. Consider an "npm code quality can be abysmal" complaint. Which in part unpacks as "I wish it was harder for mediocre programmers to share their code". An analogy for "this airplane, is this slow wifi really the best they could do?" might be "Sorting on aggregate project-level stars is the best we can do? Really? Not even Consumer-Reports-like multi-attribute ratings?" In contrast, an "isn't npm horrible - there's so much bad code" seems more like "abysmal wifi... we should be driving instead". Pointing at the community-wide fine-grain sharing as the problem, rather than at associated technosocial debt, or at renormalized-by-success expectations. Yes, the npm ecosystem has various and serious flaws. But it still seems the closest we've yet managed to come to a large diverse community easily sharing code.

btbuildem 8y ago

I've made the decision to not use NPM, or any front-end build chain tools. Downsides: everyone else is using those things, it's not even an assumption, it's ground under their feet. Upsides: SO SIMPLE. make handles any build / deployment scripting. Localized dependencies. Nothing changes without me taking an explicit action.