Live data from Hacker News

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

github.com

171–180 of 211 posts

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

#171

Earlier quoted context omitted.

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

Well I can't say I agree in the slightest.

If you treat JS like a toy, it's gonna act like a toy.

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

#172
post #94

Earlier quoted context omitted.

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…

As an outsider my question would be why can't the existing tools update and adopt instead of being replaced?

In half the cases parent presented, there were no "existing tools" to update(manual polyfills -> modernizr/6to5, script tags -> package managers like bower/npm, nothing -> eslint/type checkers, writing ad-hoc scripts for your own os -> grunt/gulp).

The rest of the examples are cases of merging two large ecosystems(web development and nodejs) together - that spawned browserify/webpack for bundling, npm for package management.

Many of these tools did try to update and adopt the new schemes. The grunt developers spent a lot of time optimizing their architecture in order to achieve the same speeds that gulp had. NPM has not stopped evolving - major version 3 tries to address a lot of the problems that yarn tackles. Babel evolves to adopt new javascript features.

I see the churn in development tools as a very natural progression, but that might be because I've been following it for a while and have seen and felt the pain points that each of these tools try to solve. I see a lot of effort within the javascript community to remain "compatible" wherever possible - for example, there are tons of guides how to migrate from grunt to gulp, there are matching tasks to ease your migration, etc. Library developers often release both on npm and bower, and craft elaborate "UMD loaders" for their libraries to allow for commonjs/AMD to exist side by side.

All in all, I find living with "javascript fatigue" to not be very exhausting. In our company, we have a wide variety of projects - some use literally no tooling, some use just bower, some use grunt, some use gulp, and our latest ones use the "modern stack" with webpack, etc. All of these projects are still actively maintained and their respective tooling stacks work and provide the benefit they were added for.

The problems the "newer" tools try to solve may not even be problems your development process has. If you've never really suffered performance problems working with grunt, then perhaps you've never felt an urge to migrate to gulp. Maybe you've never been bitten by npm's non-deterministic installations and poor download performance(I really haven't, so I haven't migrated to yarn, for example).

The magnitude of web development projects has ballooned in the last couple of years, and the tools are racing to handle it. It's not surprising that tools that are fit for a large web application with tons of code and a large team aren't really fit for a few javascript files to decorate a mostly static site built by a single developer. The churn is there, if you need it, but you don't have to use any of the newer libraries or tools.

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

#173
post #71

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…

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…

I'd say tools change every couple of days and often introduce breaking changes.

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

#174
post #160

"This is a minimalistic JavaScript stack" "ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow" brutal.

Minimalist python backend stack:

Django, gunicorn, Django Rest, Postgres (psycopg2), celery, redis, requests, nose, factory_boy, freezegun, raven

Building good applications for lots of people requires lots of stuff. Using vanilla JS to build web apps is as much fun as using vanilla python to build a backend.

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

#175

Earlier quoted context omitted.

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

Well I can't say I agree in the slightest. If you treat JS like a toy, it's gonna act like a toy.

Treating it as something else won't make it something else. It will just require a "minimal" stack of 10 other technologies.

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

#177
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.

> You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I would pick maven, and add the rest as dependencies inside the pom.xml file (the only configuration file I need to worry about). It would take me about 5 minutes and then I could import the project into IntelliJ IDEA and hack away. I can write a tutorial about it in a single blog post, together with the necessary commands to…

[deleted]

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

#178
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.

The thing is - other platforms have a 'happy path' that covers a lot of use cases and is straightforward to setup and use. JS, similar to C++, does not have this.

[deleted]

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

#179
post #160

"This is a minimalistic JavaScript stack" "ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow" brutal.

I believe you quoted me wrong :)

The "guide" is minimalistic, not the stack. The point of making the guide minimalistic is to help folks feel less overwhelmed by the complexity of said stack.

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

#180
post #160

"This is a minimalistic JavaScript stack" "ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow" brutal.

I believe you quoted me wrong :) The "guide" is minimalistic, not the stack. The point of making the guide minimalistic is to help folks feel less overwhelmed by the complexity of said stack.

I'm between entry-level and intermediate as a full-stack JavaScript dev, and I'm seeing these tools (or equivalents) as the basics used at the last couple jobs and the ones I'm applying to now. Really appreciate you putting this together. Thanks so much.
Post reply on HN