3 ms·

Based on your definition of "giant global variable" the $ in JQuery is also precisely that. lmfao. Seriously bro, you know i'm right. Yes the m64 namespace is d

Based on your definition of "giant global variable" the $ in JQuery is also precisely that. lmfao. Seriously bro, you know i'm right. Yes the m64 namespace is designed to encompass the entire app, to keep meta64 from having ANY global scope variables except for that one. Precisely like the JQuery $. I'm doing namespaces precisely by-the-book. So the mere fact that you said "giant global variable" is proof beyond any doubt that you don't know jack about namespaces, and all you were barely able to do was notice the lack of module loaders at the top of my files. You may not even know this, but packaging an app into a single downloadable JS file (modules not even necessary) is actually the modern approach. It lends itself to better compression+minification. Once installed in a browser cache it's usable just like an 'installed' piece of software. But I thank you for the phrase "giant global variable". I'll be laughing at that for years to come.

WorldMaker 10y ago
«Based on your definition of "giant global variable" the $ in JQuery is also precisely that.» Which is part of why I haven't used JQuery in ages. The last time I saw someone mention JQuery as a best practice example was arguably a decade ago, if not longer than that. If you are doing things by a book, it's not a book that was written any time recently. At this point, any library I see that uses a global variable and doesn't support proper module loading is a code smell and a sign that the library is probably not well maintained. «You may not even know this, but packaging an app into a single downloadable JS file (modules not even necessary) is actually the modern approach. It lends itself to better compression+minification.» Actually, this has changed a lot in recent years, and your ignorance of how module systems work also shows up here. First of all, you can have compression+minification and modules. Even in the bad old RequireJS days when AMD loaders were state of the art there were good AMD bundlers. With modern EcmaScript 2015 modules (ES2015) there are a lot of great bundler options, Webpack being a particular darling right now, but there's also others. This sort of bundling, compression, and minification is now seen as the last step in the chain, the job of the application/website developer and no longer something that every JS library under the sun needs to do bespoke. A big reason for this is developer experience (it's easier to debug when everything is a large collection of modules), but it also makes for a better user experience (the final application knows more precisely what modules it needs to operate [tree shaking], and in what order [optimizing bundles for specific use cases/first impressions]). Overall, frontend web development is shifting to share modules with more backend operations and the node ecosystem's npm (and relatives that piggyback on it like jspm and yarn) has become the package/module management ecosystem of choice. This is great for developer experience, whether or not you are doing your backend development in Node, because you have an easier access to a larger ecosystem of libraries, an increasing number of which are "universal"/"isomorphic" running just as well in the browser as on a server running Node (or app running in Electron or an app running in Cordova). Furthermore, for some of these platforms bundling+compression+minification isn't even necessary, such as an app or server loaded directly from the filesystem instead of shipped to a browser via HTTP. Even that is changing best practices because HTTP/2 mitigates a lot of the reasons that you even need to bundle in the first place (HTTP/1.x often can only handle a single file per connection while HTTP/2 was designed from the start to bulk download a collection of files in a single connection; the connection overhead being the biggest reason to bundle in HTTP/1.x). There's a lot of great stuff to learn about the current state of the art with respect to modules and ES2015 and modern frontend development ecosystem if you thought to give it a try instead of sticking to old practices now long considered harmful (not just in JS, even, but in about any language: giant global stateful singletons like JQuery are a miserable antipattern any time they show up in any language in the history of programming).
- tabeth 10y ago
  I use Ember, which abstracts most of the things you're mentioning, but if you have resources (other than the websites for the tools you mention) you'd like to recommend they'd be much appreciated!
  - ClayFerguson 10y ago
    As a TypeScript app the obvious thing for me was to let typescript bundle it also. I'm using Google's minification: https://developers.google.com/closure/compiler/ https://developers.google.com/closure/compiler/
  - WorldMaker 10y ago
    What I've skimmed of recent PluralSight courses on the subjects seem to be good resources, especially if you are the sort of learner that prefers video tutorials as benefits some of my colleagues. There's a lot of scattered Medium articles and "Awesome Lists" I've seen from time to time, but I don't seem to have any organized bookmarks on the matter.
- ClayFerguson 10y ago
  It's hilarious that you say bundling+compression+minification is "obsolete" and your suggested better way is "stop using HTTP, load from a filesystem." You had to bend over backwards THAT ridiculously far to try and find a fault with it. The technique 99.999% of the world is moving to. so funny. And saying that JQuery's namespace ($) is a "big global variable", and therefore you hate it, will be something i'll be telling buddies about for years to come.
  - WorldMaker 10y ago
    All I can suggest is you try rereading my comments with an open mind. I did not say bundling+compression+minification is "obsolete", I said things had shifted in how front-end development uses those things as tools in their toolbelt. It's a very different world these days in JS and lot of "must" best practices became "when needed" best practices. All I was trying to point out was that you don't start with bundling+minification+compression, you pull in those tools as and if you need them. As for JQuery, I'm not the only engineer that sees it as a problem. It's the second sentence of the Wikipedia article summary on the Singleton pattern, for instance: « There are some who are critical of the singleton pattern and consider it to be an anti-pattern in that it is frequently used in scenarios where it is not beneficial, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application. » -- https://en.wikipedia.org/wiki/Singleton_pattern https://en.wikipedia.org/wiki/Singleton_pattern Google for "Singleton anti pattern" for many pages of articles on the subject, if you care.
minitech 10y ago
Combining a response to a few comments here. > Based on your definition of "giant global variable" the $ in JQuery is also precisely that. jQuery’s `$` and `jQuery` are giant global variables when you include jQuery as a <script> or by concatenation. When you load it as a module, it adds no globals, which is rather nice. Look at https://www.npmjs.com/package/jquery’s https://www.npmjs.com/package/jquery’s “Babel” section, which is also how you use it with TypeScript. You also seem to be under the impression that polluting the global namespace is the only bad thing about globals. It’s one factor, but it’s also just generally an indicator of bad design. Organizing global mutable state into singletons and namespaces doesn’t help with this. You’re also crowing about TypeScript but throwing away many of its benefits by not using modules or typings for the libraries you depend on. > You may not even know this, but packaging an app into a single downloadable JS file (modules not even necessary) is actually the modern approach. It lends itself to better compression+minification. (ES6) modules actually quite necessary if you want your minifier/bundler to be able to remove unused code reliably. Closure Compiler can only do so much.

WorldMaker 10y ago

«Based on your definition of "giant global variable" the $ in JQuery is also precisely that.» Which is part of why I haven't used JQuery in ages. The last time I saw someone mention JQuery as a best practice example was arguably a decade ago, if not longer than that. If you are doing things by a book, it's not a book that was written any time recently. At this point, any library I see that uses a global variable and doesn't support proper module loading is a code smell and a sign that the library is probably not well maintained. «You may not even know this, but packaging an app into a single downloadable JS file (modules not even necessary) is actually the modern approach. It lends itself to better compression+minification.» Actually, this has changed a lot in recent years, and your ignorance of how module systems work also shows up here. First of all, you can have compression+minification and modules. Even in the bad old RequireJS days when AMD loaders were state of the art there were good AMD bundlers. With modern EcmaScript 2015 modules (ES2015) there are a lot of great bundler options, Webpack being a particular darling right now, but there's also others. This sort of bundling, compression, and minification is now seen as the last step in the chain, the job of the application/website developer and no longer something that every JS library under the sun needs to do bespoke. A big reason for this is developer experience (it's easier to debug when everything is a large collection of modules), but it also makes for a better user experience (the final application knows more precisely what modules it needs to operate [tree shaking], and in what order [optimizing bundles for specific use cases/first impressions]). Overall, frontend web development is shifting to share modules with more backend operations and the node ecosystem's npm (and relatives that piggyback on it like jspm and yarn) has become the package/module management ecosystem of choice. This is great for developer experience, whether or not you are doing your backend development in Node, because you have an easier access to a larger ecosystem of libraries, an increasing number of which are "universal"/"isomorphic" running just as well in the browser as on a server running Node (or app running in Electron or an app running in Cordova). Furthermore, for some of these platforms bundling+compression+minification isn't even necessary, such as an app or server loaded directly from the filesystem instead of shipped to a browser via HTTP. Even that is changing best practices because HTTP/2 mitigates a lot of the reasons that you even need to bundle in the first place (HTTP/1.x often can only handle a single file per connection while HTTP/2 was designed from the start to bulk download a collection of files in a single connection; the connection overhead being the biggest reason to bundle in HTTP/1.x). There's a lot of great stuff to learn about the current state of the art with respect to modules and ES2015 and modern frontend development ecosystem if you thought to give it a try instead of sticking to old practices now long considered harmful (not just in JS, even, but in about any language: giant global stateful singletons like JQuery are a miserable antipattern any time they show up in any language in the history of programming).

tabeth 10y ago
I use Ember, which abstracts most of the things you're mentioning, but if you have resources (other than the websites for the tools you mention) you'd like to recommend they'd be much appreciated!
- ClayFerguson 10y ago
  As a TypeScript app the obvious thing for me was to let typescript bundle it also. I'm using Google's minification: https://developers.google.com/closure/compiler/ https://developers.google.com/closure/compiler/
- WorldMaker 10y ago
  What I've skimmed of recent PluralSight courses on the subjects seem to be good resources, especially if you are the sort of learner that prefers video tutorials as benefits some of my colleagues. There's a lot of scattered Medium articles and "Awesome Lists" I've seen from time to time, but I don't seem to have any organized bookmarks on the matter.
ClayFerguson 10y ago
It's hilarious that you say bundling+compression+minification is "obsolete" and your suggested better way is "stop using HTTP, load from a filesystem." You had to bend over backwards THAT ridiculously far to try and find a fault with it. The technique 99.999% of the world is moving to. so funny. And saying that JQuery's namespace ($) is a "big global variable", and therefore you hate it, will be something i'll be telling buddies about for years to come.
- WorldMaker 10y ago
  All I can suggest is you try rereading my comments with an open mind. I did not say bundling+compression+minification is "obsolete", I said things had shifted in how front-end development uses those things as tools in their toolbelt. It's a very different world these days in JS and lot of "must" best practices became "when needed" best practices. All I was trying to point out was that you don't start with bundling+minification+compression, you pull in those tools as and if you need them. As for JQuery, I'm not the only engineer that sees it as a problem. It's the second sentence of the Wikipedia article summary on the Singleton pattern, for instance: « There are some who are critical of the singleton pattern and consider it to be an anti-pattern in that it is frequently used in scenarios where it is not beneficial, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application. » -- https://en.wikipedia.org/wiki/Singleton_pattern https://en.wikipedia.org/wiki/Singleton_pattern Google for "Singleton anti pattern" for many pages of articles on the subject, if you care.

minitech 10y ago

Combining a response to a few comments here. > Based on your definition of "giant global variable" the $ in JQuery is also precisely that. jQuery’s `$` and `jQuery` are giant global variables when you include jQuery as a <script> or by concatenation. When you load it as a module, it adds no globals, which is rather nice. Look at https://www.npmjs.com/package/jquery’s https://www.npmjs.com/package/jquery’s “Babel” section, which is also how you use it with TypeScript. You also seem to be under the impression that polluting the global namespace is the only bad thing about globals. It’s one factor, but it’s also just generally an indicator of bad design. Organizing global mutable state into singletons and namespaces doesn’t help with this. You’re also crowing about TypeScript but throwing away many of its benefits by not using modules or typings for the libraries you depend on. > You may not even know this, but packaging an app into a single downloadable JS file (modules not even necessary) is actually the modern approach. It lends itself to better compression+minification. (ES6) modules actually quite necessary if you want your minifier/bundler to be able to remove unused code reliably. Closure Compiler can only do so much.