131–140 of 211 posts
I feel like the people complaining about how many libraries there are in this stack don't know what these tools do. Most are small tools that do one thing very well. Yarn installs packages, much like Gem, NuGet, whatever. Pretty standard. React is a frontend framework. Not surprising that you'd use one. I suppose you could opt to write a giant pile of vanilla JavaScript instead (I'm assuming you're not using this kit…
Earlier quoted context omitted.
I think the reason most of us dislike the ecosystem isn't because therre are many libraries and tools in the stack. In the C-world, every time you type 'make' I am probably executing two dozen different programs, so we are very comfortable with "Make each program do one thing well". The problem that most of us dislike the javascript/web ecosystem is that those set of libraries and tools keep changing every couple yea…
Just google "yarn vs npm" and you'll know the answer... the tools change because the technology is evolving, despite node the front end is still the driver, and mobile phones / browsers / etc are constantly being improved and evolved, and the ecosystem keeps up with it. Would you rather it all stayed static like in the C world and then you program a 2016 smartphone with a 2006 stack?
How log did it take for a sane build system to show up? Or a sane package manager (with dependency resolution, upgrades, checksums, signature verification, etc.)? Why is Grunt/Gulp a thing when we have thinks like make/CMake?
The technology is not changing, in the sense that the state of the art is not really changing. In the past 15 years the biggest paradigm shift has really been towards single page apps, ES6-7, and TDD. The rest has existed as state of the art in many other ecosystems, but the JS community is notorious for having a bad case of NIH syndrome, so it's taking forever to get to the state of the art.
The good news is that it will slow down at some point. The bad news is that it probably won't be for a few years.
I feel like the people complaining about how many libraries there are in this stack don't know what these tools do. Most are small tools that do one thing very well. Yarn installs packages, much like Gem, NuGet, whatever. Pretty standard. React is a frontend framework. Not surprising that you'd use one. I suppose you could opt to write a giant pile of vanilla JavaScript instead (I'm assuming you're not using this kit…
How big is the nodemodules dir after installing these 12 "small tools" ?
Earlier quoted context omitted.
You don't need all of these tools to get an app up and running even though reading the tech blogs may make it seem like you do. Frontend dev isn't really that difficult if you focus only on what is really needed for your app at hand.
It's just tiring though. I want to make a simple website. But in order to do it "right" or "optimally" or whatever, I need to flush all the old stuff I know down the toilet (jQuery, etc.) and learn a mountain of new stuff.
Unless your end user is the developer community, I doubt they give a crud if you are using jQuery or all of this stuff. As long as your app is doing what they want it to do and doing it well, that is what matters most.
If you want to make a simple website, all of this is way over-kill. That is one of the downsides with these discussions. People are lead to believe that all of this is needed to "make a simple website".
I am not at all opposed to learning new stuff especially if it is going to make your job easier, but don't feel you have to abandon your current toolbox and buy into a new one every few months just to keep up. That imo is madness and will only hold you back from getting stuff done.
From section 1 of the tutorial: > Since it came out in October 2016, [Yarn] received a very quick adoption and is becoming the new package manager of choice of the JavaScript community. We are going to use Yarn in this tutorial. It's October 2016 as I write. Tell me this tutorial is satire. Please.
The thing is, Yarn is likely to supersede npm at the command line so this is really future-proof.
Earlier quoted context omitted.
> It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last. If you assume that the entire Javascript community was one person or one coherent group, then yes. But it is not like that at all. You state this as if a single organization made grunt, then made gulp, then made webpack. This is nearly as absurd as saying "The…
Probably a better term than inventing is "standardizing". The community as a single general entity, is constantly changing what they accept is the "standard stack". I don't get to have my safe goto stack of LAMP for twenty years, and then swap out alternatives after research and my needs; the goto stack is radically different every year. And ofc there's a big push for frameworks and languages over libraries, and libr…
I don't see any evidence of this. If anything, the source of most people's complaints is that the JavaScript community heavily prefers libraries over frameworks, which means you need to pick several libraries to build a project instead of
Are you sure you have any clue what you're talking about? I regularly "upgrade" parts of my stack without changing "everything." It's a huge part of why libraries like React are awesome.
As a back-ender looking to dabble with modern front-end development best practices, I'm encouraged to find guides like this one. Even if the array of available packages and tools appears dizzying, and often times faddish, it's nice to see the many options laid out rather concisely. I have a decent handle on React and some of its immediately related tools, which has greatly improved my fluency with contemporary front…
The node-sass package (on NPM) comes with a command line tool, so you don't even need to add a separate build tool.
I have an NPM script that executes:
node-sass -w styles/app.scss -o dist/
Earlier quoted context omitted.
Just google "yarn vs npm" and you'll know the answer... the tools change because the technology is evolving, despite node the front end is still the driver, and mobile phones / browsers / etc are constantly being improved and evolved, and the ecosystem keeps up with it. Would you rather it all stayed static like in the C world and then you program a 2016 smartphone with a 2006 stack?
The problem with continuously changing technologies is that it doesn't allow you to become a master of that stack, so your constantly relearning how to accomplish the same thing. It's inefficient. If I build my applications with well established technologies, then I can do it quickly and accurately. Sure, I might miss out on some cutting edge benefits, but my shit works, always. However, if i switch to JS, I feel lik…
Suddenly being a medical doctor sounds much less stressful. I really feel some of us chose the wrong career path. Imagine having high social status, having almost always some meaningful work, all for debugging meat machines that have lots of failure modes, but most of them well understood?
From section 1 of the tutorial: > Since it came out in October 2016, [Yarn] received a very quick adoption and is becoming the new package manager of choice of the JavaScript community. We are going to use Yarn in this tutorial. It's October 2016 as I write. Tell me this tutorial is satire. Please.
A lot of people on HN seem to confuse the introduction of new tools with a necessity for you to constantly rewrite your app. There's nothing saying you need to adopt the new tools as soon as they come out.
Personally, I like to give things a good while to work out the kinks and see if they're actually any good (Bower failed this test, for example, so I've never used it). In the meantime, my "old" tools still work fine. Despite all the talk of churn, the last time I actually added a new major tool to my stack was GraphQL this spring.
Earlier quoted context omitted.
I don't buy that either. The youngest thing on that list is yarn, but aside from that everything is a few years old at least. And nobody is saying you need to use anything. Npm works fine, bower still works fine, hell pulling down tarballs still works fine. You don't need to use the newest thing if you don't have the problems it's trying to solve.
Yeah, from the outside I can understand the "everything keeps changing!!" complaint, but having been involved in JS for a few years, every single tool that got replaced was replaced for completely valid reasons, that couldn't have been solved incrementally by improving what was already there. Grunt > Gulp > Webpack manual polyfills > 6to5 > Babel script tags > bower > NPM > Yarn nothing > Flow/Typescript All of these…
In other words, this is the consequence of optimizing for new entrants and writability versus readability and maintainability. It also becomes much harder to funnel talented people into being contributors to existing projects rather than starting their own.
In other languages there are very large projects that are heavily refactored and improved to support new patterns and use cases with regularity. Just yesterday I was using Antlr 4, which has been around for 25 years. But it's been updated many times. Maven was started in 2002, and maven 3 in 2008. It's stable and production quality. The openssl library goes back to 1998. Vim goes back to 1988 -- also rock solid and reliable. We're using a networking stack that is pretty damn old. But in the JS world, I can't help but think they would never be able produce anything that reliable because 6 years later they would be on their 6th re-write of Vim. And no, it's not (IMO) because other languages have corporate sponsors.
Javascript came out of the webspace which (was) primarily throwaway code. It was a bad thing to have an old website. They prioritized rapid prototyping, which was appropriate for that business case. However as Javascript is maturing and branching out to server-side programming and at the same time the client side becomes more complex, you can't keep re-writing all your tools every couple of years, or even every 5 years. You need tools that last decades, even as they are incrementally improved. If you don't have that, you are going to be subject to increasing exponential costs that are going to weigh very heavily on the language. Soon, you'll need to spend almost all your resources just re-writing stuff. It's no different than the developer that builds non-sustainable housing that has to be torn down every 10 years but is really cheap to build. Long term, a city built that way will necessarily be smaller in size and more expensive to maintain than a city built with housing that is more expensive to build up front but lasts a lot longer. Exponential decay is going to catch up to languages that like to keep re-writing all their libraries.
More importantly, I don't see an awareness on the part of the JS community that this is a serious problem that they need to tackle. They look at all the new libraries and the fact that they have the most code on github as a good thing, instead of as a warning side that they are already spending way too much time re-writing stuff.
So when there is announcement -- here is your standard webstack and it contains a tool less than a year old, a lot of people are gonna say "WTF", and explaining to them that Yarn has some new feature that NPM doesn't kinda misses the point. Of course it has some new features -- but still -- "WTF"?