Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

111–120 of 211 posts

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

#111

Post by mambodog »

cel1ne wrote: post #6

I would give up Immutable because of it's bad performance and often confusing api. Also I'd give up Mocha, Chai & Sinon for tape, which is way simpler and more than enough: https://medium.com/javascript-scene/why-i-use-tape-instead-o...

I don't think 'bad performance' is a fair characterisation of Immutable.js. If you're calling .toJS() all over the place it will be doing a lot of redundant work. However there should be no need to do that, if you just pass the data structures around and access their fields directly.

That's not to say that you should necessarily use Immutable.js; if you don't understand the use case where structural sharing in persistent immutable data structures is useful and require it for your application then you should probably just leave this tool on the shelf.

However, if, for example, you are maintaining maps containing many items which are updated frequently, then you may benefit from the time and space complexity of structurally shared maps (Immutable.js) rather than creating a full copy on each mutation (plain JS objects).

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

#112

Post by Klathmon »

neandrake wrote: post #109
vcarl wrote: 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?

Because that's what leads to monumentally difficult to use tools.

Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about because nobody uses them, and weird security holes and issues because of legacy support for an option that was added 3 years ago which when combined with a new flag causes everything to break...

Gulp is very simple, it's like 4 functions, and like 3 or 4 "conventions" you need to learn. There is no config, there are no settings, and there isn't any baggage. And that's the theme with JS tools. Rather than bloating current tools, you make a new one. Switching between them is easy, as they are all very trivial in nature. The power comes from combining those trivial tools.

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

#113

Post by wheelerwj »

gotofritz wrote: post #97
khc wrote: post #71

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?

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 like I will have to not only relearn how to do things I already know how to do, but I will be stuck in a cycle of continuing education and won't ever be able to expand my skillset beyond those things.

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

#114

Post by wheelerwj »

Klathmon wrote: post #112
neandrake wrote: post #109

Earlier quoted context omitted.

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

Because that's what leads to monumentally difficult to use tools. Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about beca…

"rather than bloating the current tools, you.." just bloat the whole stack.

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

#115

Post by wheelerwj »

morgante wrote: post #47
nulagrithom wrote: post #46

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

Maybe that's part of the problem. Most people don't start a new project every week, so we get to know the same tools pretty well for a year or two or longer.

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

#116

Post by Can_Not »

ern wrote: post #107
Can_Not wrote: post #87

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…

Rewriting your front-end in a new webframework every 6 weeks isn't a thing that actually happens I don't think any sane person would rewrite their apps everytime a new flavor of the month tool came out, but all this technical churn must make maintenance a nightmare.

It doesn't make any additional maintenance unless you chose to rewrite your pre-existing projects when any new random thing comes out.

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

#117

Post by Klathmon »

wheelerwj wrote: post #114
Klathmon wrote: post #112

Earlier quoted context omitted.

Because that's what leads to monumentally difficult to use tools. Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about beca…

"rather than bloating the current tools, you.." just bloat the whole stack.

How so?

I use maybe 3 main tools for my build system. Gulp, webpack, and babel. And I only use gulp because it is a bit easier to read than just putting stuff in a makefile (which is replacing one tool with another), or just using bash scripts.

If we were going with the "add options instead of adding tools" way of doing things, I might have one tool, but 100 flags and settings that I would need to manage and change, and you can't ignore the flags and settings just because you want defaults, because the defaults would work in a way that's out of date, or there might no be defaults at all.

Just because there are tools out there, doesn't mean you need to use them all. You can ignore everything you don't need in your project. And that includes ignoring the downsides, bugs, security issues, breaking changes, and baggage that comes along with them.

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

#118

Post by jomamaxx »

morgante wrote: post #47
nulagrithom wrote: post #46

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

"As a freelancer, I start a new project every other week or so."

Yeah - I'm not sure if this is representative.

Moroever, if you're staring a project every other week, you may not be working at the scale/resiliency that most entities need, not even considering legacy etc..

The toolchain churn in JS is too much, especially relative to other platforms.

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

#119

Post by neandrake »

Klathmon wrote: post #112
neandrake wrote: post #109

Earlier quoted context omitted.

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

Because that's what leads to monumentally difficult to use tools. Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about beca…

Even if that were the case I would think learning powerful tools over the span of a few weeks would be worth the effort if you had the reliability that these tools would exist for years to come.

It seems like the rapid change and throw-away-ability of the tool ecosystem reflects the final product as well -- and maybe that's the large difference which is emergent from web technology? What is the average lifespan of a web application?

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

#120

Post by jomamaxx »

nulagrithom wrote: post #46

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…

"You need almost all these tools in other environments -- they're just typically chosen for you in advanced."

+ I don't think anyone is complaining about what the tools do, or necessarily their quality.

The fundamental complain is 'churn'. The stack you see today may be replaced in a year - moreover - it's really hard to tell where the community is going. There are few resources (or rather too many) that can tell you what 'works and what doesn't' etc..

Also - many of these problems should not exist in the first place, and kind of illustrate the underlying failures of the web-browser platform in the first place.

Again - great stack. But it won't last long, and it's very expensive to churn.

Recent comment at a JS meetup form some guy: "I just left a startup where I was the key Angular guy, it was all in Angular 1 - I have no idea who's going to support that now that I'm going considering everything is Angular 2 now".

Reasonable assertion.

Also - I'm not so sure the 'do one thing and do it well' theory is always an advantage. There are many solid platforms where things are really well curated by company ABC. I'd suggest that if they do their jobs well, it's better than a community approach.

Obviously - community vs. monolith is not black and white, and there are advantages to each side, but it would be unwise I think to ignore the problems of constant churn.

Another example - just at MS HQ in Montreal for a preso on React. 100 devs in the room were not particularly excited. They seemed more resigned to it than anything. The consensus was 'yet another thing'? I think there is really a big gap between those pro-shops on the cutting edge - and 'everyone else'. And React is by no means trivial.

Post reply on HN