Step-by-step tutorial to build a modern JavaScript stack from scratch
161–170 of 211 posts
Re: Step-by-step tutorial to build a modern JavaScript stack from scratch
#162Re: Step-by-step tutorial to build a modern JavaScript stack from scratch
#163Earlier quoted context omitted.
How big is the nodemodules dir after installing these 12 "small tools" ?
Who cares? This is 2016, memory footprint hasn't been relevant in years.
Re: Step-by-step tutorial to build a modern JavaScript stack from scratch
#164Earlier quoted context omitted.
I like it too. People vastly over-estimate the complexity of these tools. As a freelancer, I start a new project every other week or so. It's really not hard to get up and running with these tools. They're also incrementally adoptable: since most of them are loosely coupled, you can get started with a new one without rewriting your whole stack (for example, I first used React with Gulp+Browserify, not I've switched t…
The complexity of the tools isn't the problem. 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. So for those us who don't do front end development we come back and suddenly have to learn 20 new tools.
^^^ THIS ^^^
Re: Step-by-step tutorial to build a modern JavaScript stack from scratch
#165Earlier quoted context omitted.
Yarn solve some problems that the npm folks were unwilling / unable to solve, and is backed by Facebook + Google (+ others) so it's likely to be here to stay. Unless npm wake up and smell the coffee and implement some of it themselves, but experience shows they are quite opinionated and not in a good way.
IIRC the yarn developers worked with NPM to get it out. It's not a lack of will or ability on the part of NPM that it can't be "fixed", it's that NPM has just so much baggage. They can't change how things are installed, because that would mean getting rid of features that many people rely on. For a while they didn't even have any documentation on how NPM worked, it was a bit tautological (npm worked in the way that n…
Re: Step-by-step tutorial to build a modern JavaScript stack from scratch
#166Earlier quoted context omitted.
Are you sure it doesn't seem that way to you because you're less familiar with the ecosystem? Compare it to a Java backend. You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that to be radically less complex than the front-end stack proposed here -- but it just seems that way because a lot of those are "de facto" tools.
> Compare it to a Java backend. You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that to be radically less complex than the front-end stack proposed here -- but it just seems that way because a lot of those are "de facto" tools. For the benefit of folks unfamiliar with Java, Docker is not necessary nor tied in any way to Java. The majority of Java is not deplo…
Re: Step-by-step tutorial to build a modern JavaScript stack from scratch
#167I appreciate the effort, certainly do. But, and this a big but: the amount of tooling, libraries, complexity and systems needed for a "modern" web app is almost comical at this point.
Are you sure it doesn't seem that way to you because you're less familiar with the ecosystem? Compare it to a Java backend. You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that to be radically less complex than the front-end stack proposed here -- but it just seems that way because a lot of those are "de facto" tools.
Maven, Dropwizard, Guava, Guice, JUnit, Mockito.
(Jersey and Jackson too, but those are included in Dropwizard so ideally you don't need to care about them) Also, ideally, installing dropwizard, guava, guice, junit and mockito consist of just adding 5 lines of XML to the pom.xml file for each - no configuration needed.
Of course if you fall out of the ideal world, things can get ugly. The horrors if two dependencies insist of using incompatible versions of Jackson but Maven insists that you can only use one version of it in your project at a time...
Re: Step-by-step tutorial to build a modern JavaScript stack from scratch
#168Ridicule me all you guys want but I still write using just html/css/js and sublime text (no jquery either). And I have written a 30k line project using just that and php. Being a filthy casual has it's upsides. I can do whatever I want insanely quick. Moving projects from machine to machine is quick as well. Only time I use command line is for git. I do have the advantage of having all my customers on a modern browse…
Re: Step-by-step tutorial to build a modern JavaScript stack from scratch
#169Earlier quoted context omitted.
Who cares? This is 2016, memory footprint hasn't been relevant in years.
Memory is still the number 1 limit I have to deal with, every day. Both on my laptop, and on the server side. It remains highyl relevant exactly because of that kind of attitude.
Re: Step-by-step tutorial to build a modern JavaScript stack from scratch
#170Earlier quoted context omitted.
It depends on what you're building. I think Java really shines better in the backend long-lived services realm. If you're just writing something that doesn't need any fancy "web" layers plain Java in a plain Eclipse project is all you need to get going. Nothing more. You just need to know how to type and what you're trying to do and most things you want to do are very easy to accomplish.
You can replace java with javascript and your sentence is still 100% true. And I think that's the point many are trying to make. It's not overly complicated, it's just that people are trying to use every tool they read about without understanding it or why it was created. If you are making a website for your restaurant, you don't need react, webpack, babel, sass, etc... You need a few hundred lines of html and like 2…
If I replace "Java" with "javascript" I get:
> Javascript really shines better in the backend long-lived services realm.
You realize how ironic that sounds, right? No matter how many language improvements, transpilers, builders, etc. you throw at it, javascript will always remain, at its core, a dumb scripting language for browsers.