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

81–90 of 106 posts

Re: The state of JavaScript modules

#81

Post by rusk »

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'm fairly new to this whole Javascript development game. I got involved in brown field development in a hobby project and I am blown away by how far Javascript development has come.

Like I say, I'm new to this area so don't have much of a frame of reference but `npm` is nothing short of brilliantly neat, and hassle free.

With regards to the different language varieties `babel` sorts all that out - you can use your flavour of JS as you see fit and it all gets compiled to orthodox cross-browser JS.

Seriously pleased with what these features provide to the development environment.

Re: The state of JavaScript modules

#82

Post by pdimitar »

Illniyar wrote: post #65
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 i…

It's not about (1) other languages having trouble as well, and (2) it sure as hell is not about JS being very popular.

It's about this: I wrote a module for my project, I want to import it in my project and everywhere else where it might be useful, in one, SINGULAR way, which doesn't change for at least 18 months, please. I'd like to be able to write ES 2016/2017 and not caring how it gets compiled to ES5; can't you people just finally agree on one way of doing things?

You people who mostly (or exclusively) code JS simply don't understand that many of us code in 5+ languages every week and we want to be productive.

If I have to read on a new standard and a new and shiny way of managing dependencies every 8-10 weeks and if you think that's okay, then you seem to fail to grasp how unproductive this is. For you it might be a full-time job. For me, and many others, it's a distraction because we have to do a lot of stuff in several languages and we'd much appreciate it if the JS folk would just calm the hell down for a bit.

Re: The state of JavaScript modules

#83

Post by _pmf_ »

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…

> Plain Javascript is just fine, especially with the improvements of ES6.

With React pushing hard to use JSX and discontinuing the in-browser JSX-to-JS transformation step, this is no longer completely true. You have to introduce the tooling from the start. (Yes, technologically you are not forced to use JSX and can use JS, but this is clearly declared as unwanted in the React ecosystem.)

Re: The state of JavaScript modules

#84

Post by bryanlarsen »

pdimitar wrote: post #82
Illniyar wrote: post #65

Earlier quoted context omitted.

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

It's not about (1) other languages having trouble as well, and (2) it sure as hell is not about JS being very popular. It's about this: I wrote a module for my project, I want to import it in my project and everywhere else where it might be useful, in one, SINGULAR way, which doesn't change for at least 18 months, please . I'd like to be able to write ES 2016/2017 and not caring how it gets compiled to ES5; can't you…

The article explains the approach that the node.js ecosystem is taking to bend over backwards and maintain full backwards compatibility. Javascript from 1997 still works; write your code 2015 style and it'll still work 20 years from now. You don't have to live on the bleeding edge -- you'll lose tree shaking but you'll gain some sanity.

Re: The state of JavaScript modules

#85

Post by pdimitar »

bryanlarsen wrote: post #84
pdimitar wrote: post #82

Earlier quoted context omitted.

It's not about (1) other languages having trouble as well, and (2) it sure as hell is not about JS being very popular. It's about this: I wrote a module for my project, I want to import it in my project and everywhere else where it might be useful, in one, SINGULAR way, which doesn't change for at least 18 months, please . I'd like to be able to write ES 2016/2017 and not caring how it gets compiled to ES5; can't you…

The article explains the approach that the node.js ecosystem is taking to bend over backwards and maintain full backwards compatibility. Javascript from 1997 still works; write your code 2015 style and it'll still work 20 years from now. You don't have to live on the bleeding edge -- you'll lose tree shaking but you'll gain some sanity.

No disagreement on that point. I am talking about new and maintenance projects. My pet peeve is "just install this, just use that, oh and by the way also definitely install this" for things that should either be built-in, or well-standardized (minifiers, tree-shaking, transpiling). And they are not.

If I get into a new team and there are 3 devs already writing JS, it's highly unproductive because it feels like you have to very regularly catch up with the JS ecosystem. Not to mention the strong peer-pressure factor of "cool kids use X, Y or Z". And this is a very underestimated phenomena by so many devs -- and it exists in almost every team.

Re: The state of JavaScript modules

#86

Post by bryanlarsen »

pdimitar wrote: post #85
bryanlarsen wrote: post #84

Earlier quoted context omitted.

The article explains the approach that the node.js ecosystem is taking to bend over backwards and maintain full backwards compatibility. Javascript from 1997 still works; write your code 2015 style and it'll still work 20 years from now. You don't have to live on the bleeding edge -- you'll lose tree shaking but you'll gain some sanity.

No disagreement on that point. I am talking about new and maintenance projects. My pet peeve is "just install this, just use that, oh and by the way also definitely install this" for things that should either be built-in, or well-standardized (minifiers, tree-shaking, transpiling). And they are not. If I get into a new team and there are 3 devs already writing JS, it's highly unproductive because it feels like you ha…

"minifiers, tree-shaking, transpiling" should not have been part of 1997 Javascript so they have to be added at some point. And this post is part of that standardization that you're asking for.

Re: The state of JavaScript modules

#87

Post by jmkni »

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 feel as though I got burned a bit with AngularJS.

I went all out with it, learned it inside out, learned how to use Gulp, Bower, etc.

Then along comes Angular2 and it's completely different. Bower is deprecated, Gulp isn't widely used any more. It's all WebPack and Yarn.

I have spent some time with Angular2 and it is good. There's a lot to like, but it is exhausting having to learn everything I already know how to do in AngularJS again in a different framework, especially when I know I could just fire up AngularJS, get the old gang back together with Gulp/Bower etc and be done in a fraction of the time, because there's nothing new to learn.

So I've been learning Android development (in the context of Xamarin.Android) over the past year, and I am now at the point where I can do pretty much whatever I want to do in Android comfortably, and have shipped a couple of apps.

In the past month I've been learning Xamarin.iOS and it is starting to (slowly) click with me. I'm getting close to that know enough to be dangerous phase.

I feel as though these are better investments of my time. I am confident that Android and iOS will still be around in five years. Even if Xamarin isn't, Xamarin maps so closely to native development that if Microsoft gets bored of it, I could use Android Studio and XCode instead and still know what's going on.

I can't say the same for Angular, React, Vue, Webpack, Yarn, Aurelia, Ionic, etc etc. I have zero confidence that they will still be around in five years, and I don't want to learn any more client-side JS frameworks until the industry settles down and matures a bit.

If I need to build a single page app, AngularJS it is for the next year or two, because even if it isn't cool anymore, it's still fine.

Re: The state of JavaScript modules

#88

Post by jessaustin »

omginternets wrote: post #59
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 appreciate your help, but it's somewhat comical to note how much your comment resembles this satire: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2... > It's not more difficult than setting up a Python, C, or any other environment, you simply have options It's decidedly more complicated than Python. Being on par with C is hardly appropriate for a dynamic language. To be clear, I really do appreciate t…

Yeah it's easy to start coding in python. Eventually one wants to distribute that code, and then the tears begin.

Re: The state of JavaScript modules

#89

Post by ng12 »

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…

> Give me some sort of promise when you'll leave the standard alone, then I'll wait for the community to form best practices / libraries to catch up

I don't understand what's stopping you from doing that. There are many perfectly fine jQuery/Backbone/Angular/etc apps that are chugging along perfectly fine. There's no reason for you to adopt new technology unless it makes your life easier.

And therein lies the problem -- for a long time developing an SPA in JS was absolutely terrible. And it's getting better, and getting better due to efforts of people who love the language. Webpack didn't beat Gulp because Corporate Sponsor X adopted it, Webpack beat Gulp because some guy wrote it and it turned out to be awesome. To me that's worth more than upsetting the curmudgeons who complain about perceived fatigue.

Re: The state of JavaScript modules

#90

Post by omginternets »

jessaustin wrote: post #88
omginternets wrote: post #59

Earlier quoted context omitted.

I appreciate your help, but it's somewhat comical to note how much your comment resembles this satire: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2... > It's not more difficult than setting up a Python, C, or any other environment, you simply have options It's decidedly more complicated than Python. Being on par with C is hardly appropriate for a dynamic language. To be clear, I really do appreciate t…

Yeah it's easy to start coding in python. Eventually one wants to distribute that code, and then the tears begin.

That was true years ago. It's really not the case anymore. Related reading: https://glyph.twistedmatrix.com/2016/08/python-packaging.htm...

More to the point, even if what you said were true, the tooling is still absurdly complicated in the JS world. Your comment is a mix of of a red herring and whataboutism.

Post reply on HN