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

51–60 of 106 posts

Re: The state of JavaScript modules

#51

Post by positivecomment »

pas wrote: post #42
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…

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…

I generally agree, just a small nitpick:

> Are you making sites for blind people? Use/support tools that are thinking about WAI-ARIA/semantic markup.

I think developers should always have accessibility in their mind. People (or organizations they work for) may choose to use IE8 and yes, it makes sense to draw a line somewhere regards to supporting browsers. They can decide if an upgrade effort is worth to use your application. However people do not choose to have less abilities and it's possible that they can't do anything to change that. I'm not a dictator who says everyone must use all the accessibility best-practices but usually there's a small effort which can be made with huge gains.

Re: The state of JavaScript modules

#53

Post by aaron-lebo »

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.

So use a linter which disallows var and some of the worst usages and and use libraries which make up where it's lacking.

It's the price of improving the language + backwards compatibility.

Re: The state of JavaScript modules

#54

Post by aaron-lebo »

omginternets wrote: post #50
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…

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't confusing.

3) Pick a front end framework. Do you like Vue? It doesn't really matter because they're all doing basically the same thing in slightly different ways (like Rails, Django, Sinatra, Flask, etc).

You're good to go. It's not more difficult than setting up a Python, C, or any other environment, you simply have options. Hell, if you're doing terminal apps, you gotta decide between ncurses, blessed, termbox, raw escape sequences and so on. The JS world really isn't different than anything else.

Re: The state of JavaScript modules

#55

Post by camus2 »

aaron-lebo wrote: post #53
camus2 wrote: post #49

Earlier quoted context omitted.

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

So use a linter which disallows var and some of the worst usages and and use libraries which make up where it's lacking. It's the price of improving the language + backwards compatibility.

A linter never fixed the runtime behavior of a language, this is beside the point. The point is the assumption that Javascript is a better language today.

Re: The state of JavaScript modules

#56

Post by bshimmin »

camus2 wrote: post #48
thinkxl wrote: post #35

Earlier quoted context omitted.

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…

Backbone provided some useful stuff for working with collections, a router, and, perhaps most importantly, structure to your projects. You have to look at it in the context of the time it was written - it predated React, for example, by a number of years. It was lightweight and the code was easy to follow, the documentation was good, and the API was certainly very stable.

Nested views were problematic, undeniably, and did lead in the real world to a big old mess that wasn't much better than the jQuery spaghetti it was intended to replace, with events bubbling all over the place and unnecessary re-rendering and so on. I led a team that built a big Backbone app, back when it was very much in vogue, and it was certainly hard to get this stuff right in practice - perhaps not impossible, but harder than one would have preferred.

Re: The state of JavaScript modules

#57

Post by aaron-lebo »

camus2 wrote: post #55
aaron-lebo wrote: post #53

Earlier quoted context omitted.

So use a linter which disallows var and some of the worst usages and and use libraries which make up where it's lacking. It's the price of improving the language + backwards compatibility.

A linter never fixed the runtime behavior of a language, this is beside the point. The point is the assumption that Javascript is a better language today.

You mentioned var, let exists to fix those issues, hence the language just in that one area is better.

Re: The state of JavaScript modules

#58

Post by boubiyeah »

bshimmin wrote: post #56
camus2 wrote: post #48

Earlier quoted context omitted.

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

Backbone provided some useful stuff for working with collections, a router, and, perhaps most importantly, structure to your projects. You have to look at it in the context of the time it was written - it predated React, for example, by a number of years. It was lightweight and the code was easy to follow, the documentation was good, and the API was certainly very stable. Nested views were problematic, undeniably, an…

Yep, backbone was just like 200-300 lines of code. It was incrementally better than JQuery alone but suffered from the same limitations when trying to build apps with lots of views. If you wanted performances, you had a separated creation and update path, and you were back to Jquery spaghetti and tight coupling between DOM and JS via CSS selectors.

Shaming shouldn't be a thing, but It's fair to say no one should start a backbone project in 2017, unless it was dead simple, in which case you can use pretty much any tech anyway.

Re: The state of JavaScript modules

#59

Post by omginternets »

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 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 the help, and I absolutely will tackle this someday (soon). Still, JavaScript has a serious problem here.

Re: The state of JavaScript modules

#60

Post by aaron-lebo »

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…

I understand it's frustrating and the onboarding process is annoying.

However, once you've done it yourself, you understand that it's overstated. I can setup a template for a JS project quicker than I can a Python one these days. You have to learn how to do that, yeah (which is the annoying part), but it's not hard, just scary cause without having worked with it, all you see is options.

Post reply on HN