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

State of the Art JavaScript in 2016

medium.com

Post reply on HN
Print view View original

1–10 of 306 posts

Re: State of the Art JavaScript in 2016

#2

Post by hoodoof »

I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.

Re: State of the Art JavaScript in 2016

#3

Post by bryanrasmussen »

hoodoof wrote: post #2

I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.

can you give some examples, this article made me consider if I should rewrite my pretty developed gulp setup as webpack

Re: State of the Art JavaScript in 2016

#4

Post by hoodoof »

bryanrasmussen wrote: post #3
hoodoof wrote: post #2

I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.

can you give some examples, this article made me consider if I should rewrite my pretty developed gulp setup as webpack

Before you do that, just try to build all the modules you use with webpack into a simple barebones app and see if your app works.

Re: State of the Art JavaScript in 2016

#6

Post by williamstein »

hoodoof wrote: post #2

I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.

In contrast, I have had extremely good experience using Webpack, and my app uses dozens and dozens of modules.

Re: State of the Art JavaScript in 2016

#8

Post by fleshweasel »

I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number".

Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your code is valid on some basic levels. I consider avoiding it to be a big waste of time. I've had a good experience getting the definitions files going for the libraries I use.

I also disagree with the statement that TypeScript is making JavaScript "like C# or Java". TypeScript lets you opt out of type checking all you want with minimal difficulty. It also will by default always emit JavaScript even if it detects type errors.

Re: State of the Art JavaScript in 2016

#9

Post by Lazare »

hoodoof wrote: post #2

I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.

I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.

Re: State of the Art JavaScript in 2016

#10

Post by hoodoof »

Lazare wrote: post #9
hoodoof wrote: post #2

I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.

I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.

One of many examples

http://andrewhfarmer.com/aws-sdk-with-webpack/

Search google for webpack incompatible

Post reply on HN