9 ms·
JavaScript in 2015
- fredsted 12y agoGreat screencast – lots of detail in a short period. No messing around, it also shows how an optimized workflow should look like. The audio/video quality of the screencast was extremely good as well.
- collyw 12y agoStill has more WTF moments than any other language I have used so far.
- oneeyedpigeon 12y agoYour comment might be useful or interesting if you explained which WTF moments affected you in particular, or even just which other languages you've used. As it is, it's not adding much to the conversation which is why you've been downvoted.
- collyw 12y agoIts well documented: https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_because https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_b...
- andyhmltn 12y agoYou didn't link to it and it's still pretty irrelevant to the original discussion.
- virmundi 12y agoI'm actually trying to write a book about that myself. It's called "JavaScript es basura caliente: Learning JavaScript in Anger". The goal of the book is not to rag on JS. That's not new or really interesting in its own right. The goal is to walk people through the oddities of the language such as identity loss when passing a function from an object to something else (the good old this == window rather than self). There are interesting, and annoying, things about JS that are non-obvious to people from a different language like Java or C#. There are other issues like testing and package management that are either assumed or glossed over. The JS community knows about them. Unfortunately for most of us, the responses to the language's weakness and ecosystem strengths are dispersed through the interblogs. In fact from personal use of JS and some research on the book, I'm moving to a functional approach with JS. OO in Ecma5 is a pain. Pure (or Clojure like) functional can work with a bit of help from Underscore. That pardigm seems to fit the mentality of JS better too. https://leanpub.com/javascriptesbasuracaliente https://leanpub.com/javascriptesbasuracaliente
- deleted 12y ago[deleted]
- sarciszewski 12y agoSome WTF moments in Javascript, courtesy of Gary Bernhardt: var foo = ["10", "10", "10"]; foo.map(parseInt); // Returns [ 10, NaN, 2 ] [] + [] // "" [] + {} // {} {} + [] // 0 {} + {} // NaN var a = {}; a[[]] = 2; alert(a[""]); // alerts 2 alert(Array(16).join("wat" - 1) + " Batman!"); Press F12 and use the Console to verify these if you're skeptical.
- emehrkay 12y agoThe first one is easy to understand though. parseInt takes two arguments: $thing_to_change and $radix; map iterates over an array and feeds it $value and $index. You're getting parseInt("10", 0); parseInt("10", 1) and parseInt("10", 2); The fix would be to partially apply parseInt with your defined radix; var foo = ["10", "10", "10"]; var base10 = function(val){ return parseInt(val, 10); }; x = foo.map(base10) [10, 10, 10]
- sarciszewski 12y agoA lot of the ones he presented are easy to understand. It's still a WTF when you run into it though.
- emehrkay 12y agoI guess my question is: what would have to change, in the last example, to make it not WTF to you? To me it seems pretty straight-forward what is happening.
- beejiu 12y agoAll you have done is used a function without understanding what it was doing, or reading the documentation. Most JS developers know how parseInt works, and even if they run into this problem, would quickly discover the cause. I don't see how this is a flaw of Javascript; it could happen to a developer of any language, if their strategy is 'well, it looks like it'll work'.
- 12y ago
- _broody 12y agoMost of these WTF examples basically boil down to JS doing type coercion willy-nilly. This 'feature' makes writing conditionals slightly shorter, in exchange for introducing the possibility of massive bugs everywhere in your code at any moment. Seriously, f* JS type coercion. The other misfeature I hate is that accessing undefined properties doesn't raise an error (then, but you can be sure it will make your program blow up a bit later). Typescript helps to solve both.
- dccoolgai 12y agohttp://leftoversalad.tumblr.com/post/103503118002?utm_source=javascriptweekly&utm_medium=email http://leftoversalad.tumblr.com/post/103503118002?utm_source...
- _random_ 12y agoHere you go: http://wtfjs.com http://wtfjs.com
- akanet 12y agoGod, he makes it look good. The demo does give me a few of the ol' "too much magic" heebie jeebies, but frontend JS development is so badly lacking in compelling packaage management stories that I'm going to give jspm a shot. Here's to 2015, I suppose. P.S. Glen, if you're reading this, I really would love to see a youtube of a DJ hooked up to automatically synced GIFs. Don't be a tease.
- LunaSea 12y agoFor package management why not use Bower ?
- joshkpeterson 12y agohttp://jspm.io http://jspm.io
- mattdesl 12y agoBower is great if you need to install jQuery or one of its plugins, or another very popular JS framework. When you get into smaller modules, persistence, recursive or deep dependency trees, versioning, automated bundling (i.e. no manual "config" files), etc. then bower is not a strong choice. A good writeup here: https://github.com/bionode/bionode/issues/9#issuecomment-49566087 https://github.com/bionode/bionode/issues/9#issuecomment-495...
- hij1nx 12y agonpm is not just a server side package manager. It handles package management for the front-end very well and has for a long time, learn more here -- http://browserify.org/ http://browserify.org/.
- Bahamut 12y agoI'm a bit torn over using npm this way. On one hand, being able to use tools already built in Node land such as the EventEmitter is nice. On the other hand, having to use Browserify and navigating the mess of node modules is a pita. If the dependency structure with Node modules for npm dependencies were handled better, I would likely be all for it, but it is a major negative for me, especially if a quick project starts off as a mix of a Node server and contains a moderate amount of frontend heavy logic.
- deleted 12y ago[deleted]
- akanet 12y agoThe article and cast was specifically about making the development flow for frontend javascript more robust. What are you complaining about? This article has nothing to do with advocating JS for "critical systems, frameworks and back end".
- zakelfassi 12y agoI hope you're not serious.
- tmaly 12y agoI would love to hear more about djgif
- obituary_latte 12y agoThere is a link to the repo in the article which might be helpful. https://github.com/geelen/djgif https://github.com/geelen/djgif
- sbuccini 12y agoYes, please. A video, and explanation of how to get beat data from Abelton to the server, anything helps.
- basicallydan 12y agoWow, this looks great. Nice one Glen. I'm looking forward to trying this out. I'm going to, ASAP.
- vayan 12y agoNothing to do with this, but I remember a conf about javascript in 2040++ or something can't find the video..
- hyperpape 12y agoGary Bernhardt is the speaker, though my sense is that the talk is more of a thought-experiment/parable than anything else. He hasn't quite said that, it's just my impression.
- oblio 12y agohttps://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- eskimobloood 12y agoI wonder if there is a way to split the build in more then just one big file but in several smaller files then can be loaded on runtime.
- illicium 12y agoUse WebPack and set up code splitting
- wldlyinaccurate 12y agoReally great screencast. If you have the good fortune to be a JS developer in 2015 (and beyond), there are some exciting times ahead!
- lordbusiness 12y agoI'm really late to the JS party, having just picked it up a month or so ago. node.js and Meteor are my current tools of choice; it's a rather super environment to get stuff done in. It's nice to see JS get some positive press.
- pestaa 12y agoIn fact, JavaScript is the one late to the party, having developed some rudimentary tools only recently. There's nothing exciting about redoing old mistakes in a new ecosystem.
- danabramov 12y agoWhat will SystemJS+JSPM give me over Webpack? Just curious. Webpack also supports ES6 modules (as well as CJS and AMD) when used with 6to5 transpiler, and has a lot of great features like splitting code into bundles, figuring out the best way to split dependencies based on module size, and asynchronously loading missing chunks.
- Touche 12y agoIt runs in the browser so less boilerplate to start a project, don't have to run a build daemon for every project or wait for rebuilds to finish, etc.
- deleted 12y ago[deleted]
- linhmtran168 12y agoHaizz, I've just learned to use Webpack. Now comes SystemJS+JSPM. There are just too many new tools, workflows and different ways of doing things in Javascript world.
- colinramsay 12y agoNo, because SystemJS+JSPM does nothing to invalidate your Webpack knowledge. It's still an active project that works just fine for the needs of many developers.
- dasil003 12y agoThis is a trite response. If it does something significantly better than it does do something to invalidate knowledge in a defacto sense, at least for the caring craftsman. Not that there's any point complaining about it either though...
- moron4hire 12y agoYou don't have to try to learn everything. I know HR throws the kitchen sink into job listings, but it's okay to specialize in only one copy of a particular tool.
- williamcotton 12y agoWhat advantages does this offer over the more mature ecosystem that surrounds browserify?
- lhorie 12y agoFrom what I can tell, it means you no longer need to write/maintain gulp scripts and you don't have a build step during development
- mattdesl 12y agoYou still need to maintain build scripts for production, though. p.s. For prototyping like in the vid, you can use tools like beefy or wzrd to avoid setting up any browserify build step. :)
- khalilravanna 12y agoThat's assuming you want all your scripts to be loaded on the front end asynchronously which seems to be only for development. For production I think you'd still want to compile this all down for a faster load time. From the jspm page: "For production, use the jspm CLI tool to download packages locally, lock down versions and build into a bundle." So I think you're correct that there'd be no build step for development but you'd still have some sort of script being run, whether it be gulp or otherwise, that builds it for production use.
- agmcleod 12y agoI think that's an okay compromise, especially if you typically have a CI process anyways.
- lhorie 12y agoyep, the point though is that having a build step during dev adds some overhead (which can easily go into the several seconds range in my experience) into the type-save-reload cycle, which is exacerbated by hit-reload-before-build-finished-so-need-to-reload-again pattern. My understanding is that this tool removes that entire class of annoyances, and gives a no-hassle live-reload ES6-enabled environment on top.
- AndyFang98 12y agoNode.js is the only real dev language.
- Bahamut 12y agoI found this link that was linked by the article to be very interesting: http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging http://blog.npmjs.org/post/101775448305/npm-and-front-end-pa...
- mattdesl 12y agoI'd be curious to see how a medium to large project (500+ files) works with this approach? I'm guessing it would take a while to load the page since the browser has to request each script? The tool looks pretty good. I think the most important feature is working with existing modules on npm. :) This means that most browserifiable modules can be jspm'd and vice versa.
- agilebyte 12y agoIn production you would bundle all into one file, while in development most/all of your files will be cached by the browser. But to be honest I've never worked with 500+ in the browser.
- lbotos 12y agoAside: "A DJ using Ableton Live, a huge bundle of MaxMSP emitting a UDP stream of beat information (courtesy of the immensely pro Cade), a UDP ➝ WebSockets server, and DJGif pulling hundreds of GIFs off various Tumblrs to beatmatch <x-gif> on two projectors makes for a hell of a good show." Does anyone know why he wouldn't have used the midi clock from Ableton (or other DJ software) to a "midi->websocket" server?
- arthurdenture 12y agoThe beat information might have been more elaborately derived from the audio, as opposed to just sending the basic tempo.
- radiowave 12y agoOne reason might be that MIDI clock is just a repeating, identical message. It does not contain any position information (like where the next bar starts). To get positional information relating to beats and bars, you need to use MIDI Song Position Pointers, however these use a 14 bit counter which will typically overflow after about 10 minutes. In short, long-running musical clock sync over MIDI is problematic. For syncing sound recorders, MIDI Time Code (MTC) is usually used, which works fine for up to 24 hours, but doesn't contain information about bars and beats, so unless the system receiving the MTC has a-priori knowledge of what time locations will correspond to bars and beats (which it typically wouldn't have in the context of a live performance), MTC can't be used for this purpose.
- lbotos 12y agoSweet! Thanks for the detailed run down. As a DJ myself, at my residency we have a random splattering of strange movie clips that we just play and they are never beat matched but mentally something "always" hits a beat when you are watching it. I guess he's going for stuff actually changing in musical time.
- tkubacki 12y agoJavaScript is broken by design (eg. adding obj properties on the fly is killing perf and toolability) we need replacement. Why web can't get such a nice lang like C#, Swift? In the mean time I will stick with Dart
- chrisdotcode 12y agoWhat's interesting is that all of the 'niceness' seen is the result of a switch to the functional style. Excluding the singleton class (which could have been a single function itself), you've got your map/filters in the gif processing, and encapsulation of async activities[0] through monads via promises. Seems like JavaScript got good when it started embracing what functional programmers have been drowned out saying for years. Looking good indeed. [0] Async actions as a language-level construct, as opposed to a syntactic abstraction have always been A Bad Idea. Promises should have always been the default, and manually writing callbacks should have never been a thing.
- lucian1900 12y agoExcept for immutability. It's still nowhere near the norm.
- nwienert 12y agoI'm working on a JS stack that leverages React, es6, functional style programming, and immutable data. Check my profile for more info.
- _greim_ 12y ago> Async actions as a language-level construct, as opposed to a syntactic abstraction has always been A Bad Idea. Are you saying that the upcoming async/await features of JS are a bad idea? Or maybe I'm not following; can you give an example?
- chrisdotcode 12y agoThis: images <- get "http://example.com/images.json" is objectively easier to reason about than: var images; get("http://example.com/images.json", (err, resp) => if err throw err; images = resp; even though the former might be internally implemented as the latter. In addition, the former doesn't give the programmer the 'opportunity' to cause a race-condition, and encapsulates the failure entirely for you (automatically and defaultly); If `images` ends up erroring, and you use it again, then it'll short-circuit without crash, very similar to `then()`.
- MrBuddyCasino 12y agoSlightly off topic, and sorry if it seems obvious, but his coding workflow looks really neat. He must be using a Chrome extension to live-reload the changes? Did anyone recognize the editor?
- tomca32 12y agoEditor is Webstorm: https://www.jetbrains.com/webstorm/ https://www.jetbrains.com/webstorm/
- teamonkey 12y agoHe talks about using live-server[1] about ~2m in. It injects the live reload script into the page it serves so no plugin needed. [1] https://github.com/tapio/live-server https://github.com/tapio/live-server
- c17r 12y agoThe editor was webstorm with a very minimal UI
- rmrfrmrf 12y agoLooks like an interesting workflow, but I think I still prefer using a compile-to-js language like CoffeeScript over the use of shims. I know it's a silly thought, but to me, shims sort of violate the separation of responsibilities between the user and the developer. If I, as the developer, want to write more concise, scalable, and convenient code, it should be my responsibility to spend my development resources to convert that code to something the user's browser can understand.
- jnhasty 12y agoFor anyone building projects utilizing GIFs, check out the GIPHY api. http://api.giphy.com/ http://api.giphy.com/ Here's another project using GIFs and beat matching: http://www.seehearparty.com/ http://www.seehearparty.com/ Some other cool projects: http://giphy.com/labs http://giphy.com/labs
- atestu 12y agoWhat is the difference between this and require.js for loading modules? I feel like I'm missing something
- onion2k 12y agorequire.js loads modules that are written to the CommonJS and AMD standards. systemjs loads those too, but it also loads a few other things including modules that just dump things in to global scope and things written to the ES6 standard. It's sort of like require.js on steroids.
- atestu 12y agogotcha, thanks!
- nawazdhandala 12y agoFinally we have promises support built into JS.
- peferron 12y agoMy biggest issue with the recent additions to the language is that there's now a thousand different ways to do the same thing. Iteration: for (var i = 0; i < y.length; i++) { ... } for (var x in y) { ... } for (var x of y) { ... } y.forEach(function(x, i) { ... }) Object.keys(y).forEach(function(x) { ... }) Comparison: == === Object.is() (would have been a good laugh if introduced as ==== instead) Of course, this doesn't matter much if you're a single developer. I've started writing a bit of ES6/ES7 and it's pretty cool. But it's going to be a PITA for projects built by many developers of varying experience levels. The nice things about smaller languages is that there's often only one way to do something, so when you write code or review other people's code, your mind is free from the minutiae and you can focus on the big picture instead. It's a bit funny that it's when JS is, from the general consensus, finally getting "better" that I'm actually considering more and more switching to a small but well-built compile-to-JS language. I guess smallness and simplicity just matter a lot to me.
- serve_yay 12y agoObject.is is a very silly addition to the language. It does the same thing as === except in the case of NaN and positive/negative zero. I mean if you read a polyfill for it, it's such a silly bit of "functionality". And of course the name is terrible. Argh.
- ender7 12y agoThe new Map and WeakMap classes use Object.is() to determine if two keys are the same (otherwise it would be impossible to use NaN as a key to a map). Whether this algorithm should have been exposed to users is debatable, but it exists for a good reason.
- nawitus 12y agoI would think that most languages suffer from this at least as much as JavaScript. The solution is to have guidelines and enforce them through code reviews. Linters can also catch some of the rules. I'd say that JavaScript's benefit is that it's so simple that there are not too many solutions to do the same thing, unlike massive enterprise languages like C# and Java.
- BigChiefSmokem 12y agoInstead of creating yet-another-library, yet-another-framework or superset (TypeSscript, etc.) of it we should try to fix JavaScript itself. Why companies don't push for this even if it's in all their best interests is beyond me.