Live data from Hacker News

Human JavaScript

read.humanjavascript.com

31–40 of 43 posts

Re: Human JavaScript

#31

I really like opinionated books like these. I've a question for HN on one of the opinions in this book: "use Browserify". There is only 1 single reason I don't currently use Browserify for client-side web apps: debugging. If Browserify turns all my files into one big file, all the time, and that's the only way, then how am I going to debug without going insane? I know about source maps, but I use many compile-to-JS l…

Browserify manages to remap our source maps... but we're using coffeeify to do that

Re: Human JavaScript

#32
post #2

I skimmed a few chapters and as someone who writes Javascript all day, this looks pretty good. I want to dig into it more. But I'm going to be "that-guy" and say $39 is too much just to get the kindle/PDF version. I buy a ton of programming books and I tend to only fork that much over for authoritative paper textbooks on particular subjects. Rarely digital versions. Otherwise I'm all with Patrick McKenzie on charging…

You can likely write it off for a tax deduction, at least, or ask your employer to expense it.

Re: Human JavaScript

#33

> "What about load times and performance?!?!" If you're rendering everything on the client like that, how many HTTP requests are you making, other than the initial 3 (stylesheet + javascript + html document)? I'm especially focusing on mobile performance, here. On 3G you have 200-2500ms latency on the control plane, 200ms latency for dns lookup, 200ms latency on establishishing a tcp connection, your TLS handshake wi…

Yup, I don't disagree, this fact sucks. If you keep reading you'll notice I suggest not doing this for apps that aren't behind a login. You can use login pages to prime caches, pre-render, etc. That's certainly not a panacea, but can help. With the right cache headers on the main application assets and a primed cache you can start executing code immediately and eliminate all but your data calls on a good portion of a…

Yup. For those of us working on highly dynamic non-app sites things are a bit more difficult.

I only had time to skim the introductions earlier - I'll have to give it a full read.

Re: Human JavaScript

#34

Earlier quoted context omitted.

This probably only works if you're using a transpiler transform in the browserify pipeline. (instead of running browserify on an already-transpiled codebase)

Oh, got it. I misread the original comment.

No worries :)

I like that you're focusing so heavily on commonjs+browserify. We've made the switch for new projects as well. I'm curious as to why you advocate wildemitter over browserify's client side port of EventEmitter? Is it a lot lighter?

Re: Human JavaScript

#35

I really like opinionated books like these. I've a question for HN on one of the opinions in this book: "use Browserify". There is only 1 single reason I don't currently use Browserify for client-side web apps: debugging. If Browserify turns all my files into one big file, all the time, and that's the only way, then how am I going to debug without going insane? I know about source maps, but I use many compile-to-JS l…

You can't use the default transpilers. If you do, browserify can't really follow the source maps. But you're not alone!

For React JSX, you can use the browserify transform reactify. For typescript, you can use typescriptify. They should be right there in npm :)

If you're using karma as a testrunner though, I highly s suggest karma-browserifast over karma-browserify. It's orders of magnitude faster, and supports the latest jasmine and karma (the former does not). The former runs in O(n!) where n is the number of spec files. Yikes!

Re: Human JavaScript

#36
post #12

I'm really interested how people here react to the "Picking your tools" part in the introduction. Some pretty strong opinions that contradict current trends in front-end world. I actually waited for someone to break the mould and start questioning the status quo. Especially regarding the use of DSLs and logic in templates.

My personal opinions on templates, for Javascript and other languages are:

* Use something that is HTML-aware instead of something that treats HTML as text. Even if you have the template engine still spit out HTML strings in the end its going to be able to escape user data in a context-aware manner and get rid of useless whitespace.

* Logic in templates is fine and separation of concerns between view and model does not have to mean using different languages for them. My impression is that most "logic-less" templates eventually reinvent broken versions of variables, loops, conditionals and subroutines so I would rather use a real language from the start. An example I like is giving different classes to odd and even rows in a table. The solution is obvious if you use regular loops but can be quite tricky in many template engines.

Re: Human JavaScript

#37
I stopped reading at the tilde argument for readability. I find the tilde token far more readable and easier to spot, and there's no confusion as to what the indexOf is checking for, the existence of an element in an array, where with the equality comparison tokens I need to stop and read what the heck it is comparing to. These should be reserved for when it's checking for a specific index or range.

Those extra seconds add up and in my opinion readability is more about optimizing reading speed by using common shapes and patterns conventionally, not making something dumb proof.

It even suggests using a dependency like underscore for something that is already in the language. So if I don't use underscore, I need to stop my reading completely because my mind doesn't recognize this _(array).contains('foo') pattern and I need to actively read the entire line and in cases lookup the documentation of some random method in a random obscure _ library that I also need to lookup in the code to find the actual dependency name. Because even if I were to check the implementation of that underscore method using the IDE, it's even more obscure and magic. Good luck following the advice in this book.

Re: Human JavaScript

#38
post #37

I stopped reading at the tilde argument for readability. I find the tilde token far more readable and easier to spot, and there's no confusion as to what the indexOf is checking for, the existence of an element in an array, where with the equality comparison tokens I need to stop and read what the heck it is comparing to. These should be reserved for when it's checking for a specific index or range. Those extra secon…

I think the tilde operator and Underscore are both equally cryptic and represent similar degrees of obfuscation. Tilde doesn't get much use, because it's prone to quirky behavior, particularly with respect to negative one in javascript. Gven that javascript has junk lying around like NaN, undefined, null, ==, ===, I tend to mistrust anything that isn't dog-ugly bland convention.

Aliases are also ugly in my opinion, given that they can be reassigned any old time. Even the much-used dollar sign alias demands extra scrutiny, when inspectng unfamiliar code. The advantage is that they're (aliases, that is) are easy to write, not easy read. On the other hand, the "contains" function should adhere to the sanest contract most would expect from it, and if it does, "contains" is easy enough to understand. But yeah, depending on libraries is either laziness or bullshit, when it comes to core language functionality. The only thing advanced libraries really offer is cross-browser compatibility.

Meanwhile, (x.indexOf(y) == -1) is dead simple, as long as you know that arrays start at zero, never have negative indices, and that indexOf() returns a negative value when the argument isn't matched by an object in the array. Returning a negative value, as parlance for "not found", when an absolute integer value is expected, is a pretty sane convention.

Re: Human JavaScript

#39
post #9

Earlier quoted context omitted.

I guess it wasn't so clear after all. I think this makes the third example even stronger: use a method that is named what it does.

Haha, this is an epic typo :) Sorry, will fix.

No problem :) it looks really good - just thought I'd point that out!

Re: Human JavaScript

#40

I really like opinionated books like these. I've a question for HN on one of the opinions in this book: "use Browserify". There is only 1 single reason I don't currently use Browserify for client-side web apps: debugging. If Browserify turns all my files into one big file, all the time, and that's the only way, then how am I going to debug without going insane? I know about source maps, but I use many compile-to-JS l…

I use Browserify with Coffeescript modules, and the source maps work great. I'm using Coffeeify to do it: https://github.com/jnordberg/coffeeify
Post reply on HN