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

The state of JavaScript modules

medium.com

Post reply on HN
Print view View original

61–70 of 106 posts

Re: The state of JavaScript modules

#61

Post by SquareWheel »

aaron-lebo wrote: post #54
omginternets wrote: post #50

Earlier quoted context omitted.

Your comment summarizes why I still haven't managed to learn JS (or indeed web dev in general). It's all just too damn confusing.

There's not much to it. 1) Pick a build tool (gulp, grunt, webpack - if you don't want an option, use webpack). You don't need a build tool but it helps with transpilation and it's a good base for the future. 2) Make or copy/adapt your build tool's config file to use Babel so you can use the latest ES version but compile down to work in browsers. You'll have to Google but these exist all over the place and they aren'…

I know you're trying to be helpful, but I'd like to make clear that if you're a noobie, you don't need any of these tools. Plain Javascript is just fine, especially with the improvements of ES6.

Tools are here to solve problems. Don't bother with them until you have that problem yourself. If you one day decide you want to set up things like auto-minification, image compression, CSS-preprocessing, then look into build script options. Otherwise, it'll just overwhelm you.

Re: The state of JavaScript modules

#62

Post by pluma »

sergiotapia wrote: post #12

Just like when Meteor was the hottest kid on the block, ES6 came along and pulled the rug out from under me. Now that I'm finally used to ES6, here comes some other frankenstein with more flesh bolted on. At what point will Javascript relax and stop reinventing itself and what works? When will stability become a core goal for the Javascript thought-leaders? I haven't worked with .NET and C# for years but I bet I coul…

Your mistake was picking Meteor because it was "the hottest kid on the block". It never was as popular as it was made out to be, it was just hyped to no end and super appealing to people who were new to JS (because realtime/webscale/buzzwords).

Today Meteor has mostly overcome its initial NIH obsession and thus mostly become irrelevant unless you're already a Meteor user.

It's never the right choice to jump on whatever bandwagon is all the rage at any given moment. Just look at what's been around and is still seeing active development if you want something with a long lifetime.

Personally to a newcomer to JS who wants something that'll work for a while I would probably recommend Ember or if they want something slightly more newsworthy I would recommend Angular.

On the other hand if you want to learn JS as a language and aren't afraid to go through a number of iterations of picking and discarding libraries, I would recommend what I prefer myself: React, followed up by Redux once you've outgrown toy applications.

Re: The state of JavaScript modules

#63

Post by aaron-lebo »

SquareWheel wrote: post #61
aaron-lebo wrote: post #54

Earlier quoted context omitted.

There's not much to it. 1) Pick a build tool (gulp, grunt, webpack - if you don't want an option, use webpack). You don't need a build tool but it helps with transpilation and it's a good base for the future. 2) Make or copy/adapt your build tool's config file to use Babel so you can use the latest ES version but compile down to work in browsers. You'll have to Google but these exist all over the place and they aren'…

I know you're trying to be helpful, but I'd like to make clear that if you're a noobie, you don't need any of these tools. Plain Javascript is just fine, especially with the improvements of ES6. Tools are here to solve problems. Don't bother with them until you have that problem yourself. If you one day decide you want to set up things like auto-minification, image compression, CSS-preprocessing, then look into build…

You don't need any of those if you are doing a node project, yeah, but if you want to do any work on the browser, you're gonna need to transpile anyway, so it's something people should be aware of.

Plus it's literally a 20 line config file to do so.

    module.exports = {
        entry: './src/app.js',
        output: {
            path: './bin',
            filename: 'app.bundle.js',
         },
         module: {
             loaders: [{
                 test: /\.js$/,
                 exclude: /node_modules/,
                 loader: 'babel-loader'
             }]
         }
    }
Include your app.bundle.js file in your webpage and you are good to go.

Re: The state of JavaScript modules

#64

Post by Vinnl »

camus2 wrote: post #49
tlrobinson wrote: post #31

Earlier quoted context omitted.

Before ~2015: "JavaScript is a terrible language!" After ~2016: "Stop improving JavaScript, I can't keep up!" (Not a personal attack, just general sentiment I've observed)

> After ~2016: "Stop improving JavaScript, I can't keep up!" The bad parts are still here that's the problem. The language didn't improve so much that it got new features. But var, ==, type coercion and co still exist.

> But var, ==, type coercion and co still exist.

They all have alternatives, and linters can help restrict you to those alternatives. As a developer, that makes it pretty doable.

I presume you too can appreciate why they can't simply be removed.

Re: The state of JavaScript modules

#65

Post by Illniyar »

git-pull wrote: post #9

I support innovation and people who like to code and build great things. And am happy to see JS is getting these features. I even see a downvoted comment to "just use amdefine". Well that solution worked fine for me, then 5 years of amazing hop scotch between build tools and libraries happened. And while some report benefits and advancement, I have to tell you, the amount of tools you have to pull in these days just…

I think that the feeling of "too much churn" that surrounds JS development is really people not fully realizing two things:

1 - the magnitude of the language's popularity.

2 - just how young modern javascript really is.

Javascript is either the most popular language in the world, or the second most popular after C. Even in in Java's height somewhere in the early 2000s it was never as popular as JS is right now, and it was much more homogeneous in terms of developers - js is written by designers, people with no formal education, even children.

Modern javascript is only a few years old, even jQuery came out just 10 years ago, but javascript that was used not as a scripting language really only came with the popularity of chrome and SPAs, somewhere around 6-7 years ago.

Taking these things into perspective, I don't think it's reasonable to expect (or request) for JS development to stabilize - Java is still not stable 20 years in, and it was in a similar state of upheaval as JS as recent as 8 years ago.

C is so decentralized that we don't even think about it's stability the same way we do other languages - there were (and maybe still are) multiple competing standards for the language itself, and compilers regularly won't compile code that works in other compilers.

Re: The state of JavaScript modules

#66

Post by bcherny »

hdhzy wrote: post #16
git-pull wrote: post #9

I support innovation and people who like to code and build great things. And am happy to see JS is getting these features. I even see a downvoted comment to "just use amdefine". Well that solution worked fine for me, then 5 years of amazing hop scotch between build tools and libraries happened. And while some report benefits and advancement, I have to tell you, the amount of tools you have to pull in these days just…

Well, in ancient ES3 times all we had was functions and so we used functions for everything and that was good as they are extremely versatile. But now a different problem appeared: it's hard to statically analyze function-based constructs for various purposes (tree shaking, refactoring, etc.) so new syntax was invented to capture what was convention inside the language itself. If you look at classes they are "just" s…

Can you give some examples (or better, a writeup) about how static analysis is hard without classes? It seems like Haskell gets along fine without it.

Re: The state of JavaScript modules

#67

Post by tlrobinson »

camus2 wrote: post #49
tlrobinson wrote: post #31

Earlier quoted context omitted.

Before ~2015: "JavaScript is a terrible language!" After ~2016: "Stop improving JavaScript, I can't keep up!" (Not a personal attack, just general sentiment I've observed)

> After ~2016: "Stop improving JavaScript, I can't keep up!" The bad parts are still here that's the problem. The language didn't improve so much that it got new features. But var, ==, type coercion and co still exist.

The first two are totally solvable with a couple ESLint rules (`===` and `no-var`), and the latter somewhat solveable with TypeScript or Flow.

Re: The state of JavaScript modules

#68

Post by Vinnl »

_pmf_ wrote: post #46
bfred_it wrote: post #39

Earlier quoted context omitted.

require() is dynamic and import() will be too. What are you talking about? JavaScript is not a typed language (yet?) so it's like expecting pigs to fly.

With "dynamic", I mean "pulled in at runtime" vs. "pulled in at compile time". See http://2ality.com/2017/01/import-operator.html

Isn't that exactly what `import()` is?

Re: The state of JavaScript modules

#70

Post by hdhzy »

bcherny wrote: post #66
hdhzy wrote: post #16

Earlier quoted context omitted.

Well, in ancient ES3 times all we had was functions and so we used functions for everything and that was good as they are extremely versatile. But now a different problem appeared: it's hard to statically analyze function-based constructs for various purposes (tree shaking, refactoring, etc.) so new syntax was invented to capture what was convention inside the language itself. If you look at classes they are "just" s…

Can you give some examples (or better, a writeup) about how static analysis is hard without classes? It seems like Haskell gets along fine without it.

I meant higher level constructs. Classes are just an example. Even in Haskell you have typeclasses and modules. The point is that even though in JavaScript (and other Turing complete languages) you can emulate anything with what is available (for JS that is functions) you cannot easily build tooling around your ad hoc constructs.
Post reply on HN