Live data from Hacker News

The state of JavaScript modules

medium.com

41–50 of 106 posts

Re: The state of JavaScript modules

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

> the amount of tools you have to pull in these days just get some single page interaction going...

I just started contributing to an open source project with a lot of JavaScript without any modules or even IIFE wrappers, everything is global. Just 1 year ago I would solve the problem with a new build system but now I'll just gradually introduce ES6 features, and I will not do any module refactorings because in 6 months I can probably just introduce standard modules without any build step.

When modules ship, 90% of what you need for a SPA will be available natively in browsers. If you are building a complex product, complexity will naturally increase, with build steps for various reasons.

Re: The state of JavaScript modules

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

JS is backward compatible. So it got that too from Java other than the funky name. So it's stable. jQuery? Works. Good old document.getElementById? Works. And thanks to the standardization efforts of vendors (and countless volunteers, who created feature matrices and feature tests and polyfills, and so on), now using those is easy, because you can look up what's supported, what will be supported, and what is deprecated. (So for a single page interaction you don't need tools. Case in point, last week I coded up a HTML form with a simple tag. I got so nostalgic I almost wanted to watch a video of FrontPage 97.)

But if you want to minify your code, and bundle it, and use SCSS/LESS/SASS and compile that to CSS, and if you don't want to execute the various tools manually every time, then you need tools. And yes, since these are pretty simple tools, it's easy to reinvent them, to try out a new mix of them. Gulp vs grunt? Yeah, grunt's config was horrible. But people still like magical config files, so we are back with them with webpack. And people want to use better state management, and shadow DOM, and so on, but they still like to view their sites in browsers, not just through TC39 glasses, so they use babel, but that itself evolved over the years. And so on.

And WebAssembly. And TypeScript. Because static typing is really helpful. And isomorphic whatever. And tools for that. And tools for development. (Nodemon, hot code replacement, unit testing, code coverage, e2e testing, and so on.)

And even though everything is a moving target, the good bits are still doing pretty well. (Yarn is pretty good thanks to the lockfile, but obviously npm is doing well. Webpack lives on but AngularCLI actually works so no need to handcraft webpack config; and gulp works too, if you want to get simple.)

And you don't need to wait for others to tell you what's best. Look at your visitors/users, think about their needs, and look at what tools can help you serve them best. Are you making sites for blind people? Use/support tools that are thinking about WAI-ARIA/semantic markup. If you deal with mobile users? Optimize for speed, service workers, write non-chatty [REST] APIs, push content to CDNs, and think about PRPL ( https://developers.google.com/web/fundamentals/performance/p... ). If you serve big enterprises, use tools that provide IE4.01 compatibility, and so on.

Re: The state of JavaScript modules

#43
post #35
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…

Also, there is a trend to shame old technology, or better said, to shame devs that use jQuery, Backbone, or similar. > "Oh, why are you using Backbone? That's an old and obsolete technology. You should learn React/Vue/Elm." (Vue is easy to learn for new devs, though) The dev is not familiar with functional programming or other paradigms that React suggests or requires you to know. He may be in a early learning proces…

Anyone suggesting something over the older tech should be able to explain why. And alas, as you write a lot of times, this explanation phase is simply skipped and only the impulsive shaming remains.

However, that doesn't mean the new libraries/tools/technologies are just created because "oh it's been a year and we're still using knockoutjs/react/angular/webpack/yarn!", but because a slight paradigm shift happened - at least for some people - and they feel that backbone is not the ideal tool for their job. (Maybe they felt backbone is too barebones, and went for angular, then felt that too heavy, and tried React and settled for Inferno.js.)

Re: The state of JavaScript modules

#44

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…

> I haven't worked with .NET and C# for years but I bet I could feel right at home today

You'd be surprised. It is shockingly different now - they are in the early stages of exactly what happened to JS.

I'm sure the outcome will be really beneficial for everyone, but at the moment it's very confusing if you aren't constantly monitoring it and keeping up-to-date.

Re: The state of JavaScript modules

#46
post #30

Earlier quoted context omitted.

> The one thing that I really miss is that most (all?) JS module implementations really seem to be focused on static compile workflows. That's what baffles me coming from Java and C#; I can have dynamically loaded modules with strongly typed interfaces in these ecosystems, but not in any JS module system.

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

Re: The state of JavaScript modules

#47
post #42
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…

JS is backward compatible. So it got that too from Java other than the funky name. So it's stable. jQuery? Works. Good old document.getElementById? Works. And thanks to the standardization efforts of vendors (and countless volunteers, who created feature matrices and feature tests and polyfills, and so on), now using those is easy, because you can look up what's supported, what will be supported, and what is deprecat…

>JS is backward compatible. So it got that too from Java other than the funky name.

You mean forward compatible. Which is unlike in Java.

New code (e.g. with ES6 features) doesn't work in older JS engines / browsers -- that's why we have transpilers.

Re: The state of JavaScript modules

#48
post #35
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…

Also, there is a trend to shame old technology, or better said, to shame devs that use jQuery, Backbone, or similar. > "Oh, why are you using Backbone? That's an old and obsolete technology. You should learn React/Vue/Elm." (Vue is easy to learn for new devs, though) The dev is not familiar with functional programming or other paradigms that React suggests or requires you to know. He may be in a early learning proces…

> "Oh, why are you using Backbone? That's an old and obsolete technology. You should learn React/Vue/Elm."

I have no problem with jQuery (I still use it on animation heavy websites), but Backbone wasn't a good framework IMHO. it was not very useful and it lacked the component model that is well understood by web frameworks today (backbone didn't support composite views).There is no reason to use Backbone nowadays.

I think Vue.js is a good replacement for the people who seek simplicity and a clear data model. And it doesn't require any asset pipeline or whatever, it's just a little JS file.

Angular 2,4,whatever and Embers are frameworks that oozes with complexity, for very little benefits in my opinion.

Re: The state of JavaScript modules

#49

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…

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.

Re: The state of JavaScript modules

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

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.

Post reply on HN