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

91–100 of 106 posts

Re: The state of JavaScript modules

#91

Post by ilugaslifk »

ng12 wrote: post #89
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…

> due to efforts of people who love the language

Extremely tangential, but does anybody actually love javascript? We've been in a captive situation with this deeply flawed hack for 20 years.

Once WebAssembly is mature enough to fulfill its promise, and after that once we've burned through the generation born into this JS captivity, is anyone going to want use it anymore?

Like, if it were magically possible to use anything else natively in the browser today, would the next big thing be another 10 million person-hours put into yet another angle on working around JS's flaws... or something in another less clunky language entirely, never to return?

Re: The state of JavaScript modules

#92

Post by pitaj »

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…

When people complain about these things, I just don't get it. If you liked what you were doing, just keep doing it. Sure, Bower is deprecated and you might want to consider switching to an npm-based module fetcher, but every library I've seen still works with AMD.

You can include React in an HTML script tag just like you could jQuery 5+ years ago and use it like that just fine.

The issue with JS is that it's a language used for lots of different things, and one of those things is front-end web development which is, like you said, very unstable and currently in a state of enormous flux.

You say we need to draw a line between the language and the libraries, but then you go on to say the language seems to reinvent itself every year.

Re: The state of JavaScript modules

#93

Post by LeoNatan25 »

bfred_it wrote: post #36
LeoNatan25 wrote: post #8

“Most frontend developers still remember the dark days of JavaScript dependency management.” As opposed to now, where even the smallest “app” has hundreds if not thousands of dependencies for the most basic of functionality (‘need to iterate an array, better bring lodash’), often there being multiple copies of the same dependency due to conflicting versions?

Do you prefer handling these conflicts by hand by shuffling global variables?

I would prefer there be a comprehensive base library, thus cutting dependencies to a minimum. Beyond that, I would prefer to handle those manually, yes, rather than have multiple versions of these libraries just load into memory. Conflicting dependencies is not a coherent development state.

Re: The state of JavaScript modules

#94

Post by ausjke »

Don't know what to say really, I just dislike JS no matter how hard I tried, it's a chaos to say the least, other languages, such as C, C++, Java, PHP are way more cleaner and reliable to me. Also it's so easy to be burnt out by those JS new advancements...enough is enough

Re: The state of JavaScript modules

#95

Post by dwaltrip »

All of the top level comments are complaining...

How many of those people have written at least 10k+ lines of JavaScript?

These changes are hard, but they are undeniably improving the language.

And as many others have stated repeatedly, it is not necessary to chase the bleeding edge. For example, I just learned React for the first time a few weeks ago, and I'm glad I waited (I haven't started using Redux yet either). I'm also still using browserify instead of webpack. And so on.

Re: The state of JavaScript modules

#96

Post by ravenstine »

jmkni wrote: post #87
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…

You pretty much come to the right conclusion in the end. In reality, nobody is forcing us to use WebPack, Yarn, React, etc. If an employer thinks I can't learn most of these tools on the job, then that's not the right employer for me. Although I don't think you're entirely right about Gulp, I tend to start most of my projects with Gulp, Express, and Handlebars because those are the tools I like to use. Nobody is stopping me from using those, nor will I ever be chastised for doing so. If any tool becomes useful to me, I will learn it regardless of its popularity. Well, unless support needs to be a serious consideration.

The "churn" we feel is really just a confusion from having so many new options while only wanting or needing a handful of simple/stable ones. This is troublesome because there aren't market forces(per se) or companies with researchers to limit our choices for us, like a spaghetti sauce company figuring out which 3 flavors of sauce to sell. If you can distance yourself from needing to be relevant, you'll be fine. Learn JavaScript and keep up with browser and Node.js advances; that's really the majority of what we need to do to stay relevant.

Re: The state of JavaScript modules

#97

Post by ravenstine »

ilugaslifk wrote: post #91
ng12 wrote: post #89

Earlier quoted context omitted.

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

> due to efforts of people who love the language Extremely tangential, but does anybody actually love javascript? We've been in a captive situation with this deeply flawed hack for 20 years. Once WebAssembly is mature enough to fulfill its promise, and after that once we've burned through the generation born into this JS captivity, is anyone going to want use it anymore? Like, if it were magically possible to use any…

> Extremely tangential, but does anybody actually love javascript?

I know that I do, and it's my language of choice. That's not to say that it wasn't deeply flawed for a long time, but now both the technology and standard practices have evolved to where I really enjoy writing it and using it.

Re: The state of JavaScript modules

#99

Post by jessaustin »

omginternets wrote: post #90
jessaustin wrote: post #88

Earlier quoted context omitted.

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.

Thanks, I read that last year. This seems telling:

There should be tools that help you write and update a setup.py.

In my experience, this was always the hardest part. I started using python in 1999, and I never really had any problems setting up dev environments or doing any of the other things that Glyph discusses at length at that link. As I said above, distribution is the difficulty. The javascript "complications" about which some complain at every opportunity are only possible because distribution is so easy.

If comparing the pros and cons of two languages in response to another such comparison is "whataboutism", then I have no fucking idea what that term means.

Re: The state of JavaScript modules

#100

Post by zmmmmm »

tlrobinson wrote: post #32
kuschku wrote: post #26

Earlier quoted context omitted.

Nice idea, but false. Your code depends on libraries and frameworks, which constantly change and adapt to the the mood of the time.

So transpile the library. Webpack and others can do it.

If it was just about transpiling, that would be fine. The problem is that some frameworks (eg: React) add on a whole lot more assumptions about how how your app works. Just look at the plethora of blog posts, tutorials and even whole mini-frameworks just to get d3 to work with React.
Post reply on HN