4 ms·

To my mind, part of the point was that there's no standard way of importing additional libraries. Many modern languages have some sort of symbolic import statem

To my mind, part of the point was that there's no standard way of importing additional libraries. Many modern languages have some sort of symbolic import statement that instructs the interpreter or compiler to add additional libraries to the execution context, but there's no single way of doing that from within JavaScript. Of course, that somewhat makes sense, as you don't want every random site making cross-domain imports and bypassing same-domain policies. At the same time, as the author demonstrates, you can have an agreed-upon API that provides much of the same functionality using XHR, which would make working with multiple libraries from different vendors a lot nicer.

tolmasky 17y ago
Cross-domain is not really an issue here, its quite silly that I can't in JavaScript require one file on my domain from another file in my domain. Instead, people have spent countless hours trying to figure out "the right way" to have interdependent code that doesn't block through a synchronous XHR. Sometimes this has resulted in requiring build tools which turn imports into script tags, etc (which is frustrating for a language that shouldn't require building). This is why Objective-J has @import: @import <Foundation/CPSet.j> @import <AppKit/CPView.j> alert(CPView); What's really upsetting is that we're getting the first update to JavaScript in like 10 years, and these fundamental concerns are still not being addressed. Instead of saying "what can give us the next generation of web apps", we've dropped the with keyword. Objective-J was really designed as "man, these features should have been in here ages ago". @import allows you to require code without a build step, without downloading or running twice, and still having it all take place asynchronously so that we don't block on some slow file.

tolmasky 17y ago

Cross-domain is not really an issue here, its quite silly that I can't in JavaScript require one file on my domain from another file in my domain. Instead, people have spent countless hours trying to figure out "the right way" to have interdependent code that doesn't block through a synchronous XHR. Sometimes this has resulted in requiring build tools which turn imports into script tags, etc (which is frustrating for a language that shouldn't require building). This is why Objective-J has @import: @import <Foundation/CPSet.j> @import <AppKit/CPView.j> alert(CPView); What's really upsetting is that we're getting the first update to JavaScript in like 10 years, and these fundamental concerns are still not being addressed. Instead of saying "what can give us the next generation of web apps", we've dropped the with keyword. Objective-J was really designed as "man, these features should have been in here ages ago". @import allows you to require code without a build step, without downloading or running twice, and still having it all take place asynchronously so that we don't block on some slow file.