Live data from Hacker News

Step-by-step tutorial to build a modern JavaScript stack from scratch

github.com

161–170 of 211 posts

Re: Step-by-step tutorial to build a modern JavaScript stack from scratch

#163

Earlier 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.

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

#164

Earlier 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.

"the entire Javascript community seems to suffer from ADHD"

^^^ THIS ^^^

Re: Step-by-step tutorial to build a modern JavaScript stack from scratch

#165

Earlier 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…

I honestly don't know that part of the Unix philosophy. And it starkly contrasts with my experience related to Unix, where most of the time we throw nothing away.

Re: Step-by-step tutorial to build a modern JavaScript stack from scratch

#166
post #96
post #8

Earlier 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…

[deleted]

Re: Step-by-step tutorial to build a modern JavaScript stack from scratch

#167
post #8
post #3

I 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.

A more realistic list would be:

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

#168

Ridicule 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…

Exactly. It seems the less people know about web tech, the more third party stuff the add to a website. And then they wonder why the visitors drop off and hate the sites. Some website got so bad, that they crash mobile browsers due excessive CPU/memory usage. As you mentioned server side generated code with eg PHP and HTML5, CSS3 and JS5+ is in many cases all you need to know.

Re: Step-by-step tutorial to build a modern JavaScript stack from scratch

#169
post #163

Earlier 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.

[deleted]

Re: Step-by-step tutorial to build a modern JavaScript stack from scratch

#170

Earlier 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…

Javascript is a scripting language for the browsers. Its original purpose was to make dynamic webpages by allowing browsers to modify their content according to some basic scripts.

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.
Post reply on HN