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

151–160 of 211 posts

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

#151

Post by cel1ne »

mambodog wrote: post #111
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 persis…

> if you don't understand the use case where structural sharing in persistent immutable data structures is useful

No need to insinuate that I don't understand. I've used it extensively in production and I think most code-bases are better off without Immutable.

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

It was exactly this situation, maintaining maps with thousands of GeoJSON features and working on these items, where I found Immutable to fall short. The parsing/building of the data-structure alone took, If I recall correctly, about 50 times longer than with normal JS-objects.

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

#152

Post by captainbenises »

You don't need all those tools. I'm a big fan of browserify and the budo development server.

  npm init
  npm install -g budo
  npm install --save-dev babelify babel-preset-es2015
  echo "console.log('hello world')" > index.js
  budo index.js --live -- -t [ babelify --presets [ es2015 ] ]
Add tape for some tests and you're done.

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

#153

Post by steveax »

dglass wrote: post #20

This is exactly why I don't do frontend development anymore. The number of tools needed to get an app up and running is ridiculous. Add in cross browser compatibility and it's all just one big headache.

Cross-browser compatibility? That is mostly moot with modern browsers. You really do not know how bad it was in the IE5/IE6 days. Browser compatibility is positively dreamy these days. It is getting better.

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

#154

Post by Achshar »

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 browser. But if that were not the case, only thing extra that I would need is babel. None of what OP mentions is "needed" to create a "modern" web app. Far from it.

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

#155

Post by [deleted] »

onewaystreet wrote: post #145
rsj_hn wrote: post #140

Earlier quoted context omitted.

The thing is, in other languages, frameworks and libraries can evolve without being replaced. It's called version 2. I can't help but think that in the JS world, you are more likely to ditch the old project because JS code is more difficult to read and maintain than languages that have more static typing, a somewhat higher entry bar, and a culture that values stability. In other words, this is the consequence of opti…

> 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. The client side becoming more complex is the reason why new tools keep being developed. > If you don't have that, you are going to be subject to increasing exponential costs that are going to w…

[deleted]

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

#156

Post by shakna »

onewaystreet wrote: post #145
rsj_hn wrote: post #140

Earlier quoted context omitted.

The thing is, in other languages, frameworks and libraries can evolve without being replaced. It's called version 2. I can't help but think that in the JS world, you are more likely to ditch the old project because JS code is more difficult to read and maintain than languages that have more static typing, a somewhat higher entry bar, and a culture that values stability. In other words, this is the consequence of opti…

> 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. The client side becoming more complex is the reason why new tools keep being developed. > If you don't have that, you are going to be subject to increasing exponential costs that are going to w…

> the reason new tools keep getting developed

That's a bad reason.

There's a solidly developed C library for dealing with HTTP, which is mature.

libcurl.

HTTP is developing, with WebSockets and the rest of the 2 spec.

C developers didn't immediately ditch what they use and fragment the ecosystem.

Curl got updated.

Python has a mature library, which is much younger than curl, called requests.

Python didn't fragment, they updated requests.

Here's where I have the biggest issue:

* Advice for C on which library to use, is probably still up to date 10 years later.

* Advice for Python on which library to use, is probably still up to date 5 years later.

* Advice for JavaScript on which library to use, is probably out of date 1 year later.

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

#157

Post by cx1000 »

copperx wrote: post #138
wheelerwj wrote: post #113

Earlier quoted context omitted.

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…

That's the state of the computing industry. 80% of the continuing education is about learning to do what you already knew how to do in a newer, hotter stack (but not necessarily better). 20% is about learning new paradigms. And I'm being too generous. It's probably about 5%. Suddenly being a medical doctor sounds much less stressful. I really feel some of us chose the wrong career path. Imagine having high social sta…

How can you possibly claim that failure modes of humans are well understood? Stop being such a baby. You work in a climate controlled office with catered lunches and get paid six figures. You don't have to deal with bodily fluids of other humans, or breaking the news to a "meat machine" that he or she has a terminal illness.

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

#158

Post by eropple »

rsj_hn wrote: post #140
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…

The thing is, in other languages, frameworks and libraries can evolve without being replaced. It's called version 2. I can't help but think that in the JS world, you are more likely to ditch the old project because JS code is more difficult to read and maintain than languages that have more static typing, a somewhat higher entry bar, and a culture that values stability. In other words, this is the consequence of opti…

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

There is a post, somewhere around here, that characterizes the JS culture as being one where shipping is the win condition. And I think this reflects what you describe better than the idea that other cultures merely value stability; JavaScript seems to value Github stars. And, as you say, that leads to a desire to rip out, rewrite, and own things, even if it doesn't necessarily make sense.

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

#159

Post by Roritharr »

lloyd-christmas wrote: post #133
snorrah wrote: post #131

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.

Do you happen to work on the Slack Client? (scnr)
Post reply on HN