Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Human JavaScript

read.humanjavascript.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Human JavaScript

#21

Post by HenrikJoreteg »

pablasso wrote: post #4
dmix wrote: 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…

Agreed, I don't have a problem buying digital books, but $39 is too much.

It seems a tad silly to argue about price when it's free, no? ;)

If you pick up a single tip that saves you an hour of effort you've paid for the book.

Re: Human JavaScript

#22

Post by HenrikJoreteg »

rhengles wrote: post #16

I agree with almost everything, except Browserify. I guess he prefers CommonJS to integrate with Node and npm, but in the browser I'd rather wrap the modules in AMD and use an AMD module loader (not necessarily RequireJS).

It's merely an opinion, to each their own. If AMD works well for you, that's great.

Re: Human JavaScript

#23

Post by HenrikJoreteg »

Yahivin wrote: post #9
l8no7cougyi wrote: post #7

In the 'Writing code for humans.' section are the first three code examples meant to do the same thing? The first and third check whether the array contains 'hello' but the second does the opposite.

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.

Re: Human JavaScript

#24

Post by HenrikJoreteg »

Joeri wrote: post #14
odiroot wrote: 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.

I'd like to comment on this remark: "Tools that are "just JavaScript." Not tools where you describe your app in a DSL (no Sencha). This is to avoid requiring too much knowledge of the framework itself before being able to contribute. Focusing on JavaScript also offers some protection against investing too heavily in framework-specific knowledge." I've been using ExtJS since 2008, so I can give some experience here. W…

Sencha/ExtJS does certainly give you a lot of stuff out of the box, which is really cool. The main pain points I had were when building with it emerged when I had to do something that wasn't supported out of the box.

Picking the right abstraction layer is a fine line to walk. As you pointed out, there's tradeoffs on both sides.

Re: Human JavaScript

#25

Post by warfangle »

> "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 will have a latency anywhere from 200-400ms and the actual http request will have a latency of 200ms.

That's 1000-2900ms per http request, minus 100 if your client can cache DNS responses (and everything is on the same domain). Sometimes these will be multiplexed. You can't count on it though. 4G is only marginally better: you have an overhead of 240-500ms on 4G.

And none of that takes into account the time it takes your server to process a request, or the time it takes for the client to parse and execute your rendering codebase.

If you're aiming for sub-1000ms request-to-glass, you can't follow the advice of this book (don't render anything on the server ever) - unless you don't mind the client showing a loading animation for the 2-15 seconds it'll take to load your "app."

(good luck with that mobile bounce rate)

0. https://www.youtube.com/watch?v=Il4swGfTOSM

Re: Human JavaScript

#26

Post by warfangle »

HenrikJoreteg wrote: post #19
skrebbel wrote: post #15

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 has had source maps since v2: http://thlorenz.com/blog/browserify-sourcemaps Just pass {debug: true} to build function.

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

Re: Human JavaScript

#27

Post by HenrikJoreteg »

GhotiFish wrote: post #13
odiroot wrote: 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.

I generally agree with him regarding the picking your tools part, but some of it seems a contradiction. Tools where you build the app by writing code in JavaScript files, not by trying to declare too much of your app logic in your HTML (no AngularJS, sorry). The DOM is simply a view of the state and reacts to changes in the model layer. That's pretty much Angular's philosophy as well. that said, this: People who alre…

My main point was just that it's never felt right for me personally when I try to write too much logic into templates directly. Because at the point where you hit the limit of what that abstraction supports you now have to solve that problem outside of the abstraction, fragmenting your code.

/me shrugs

It's all about how much you actually need to customize beyond what you get from something like angular out of the box.

I'm not wanting to fight a framework war, that's for sure. If angular works well for someone, that's awesome they should keep using it.

The item you pointed out in the second quote, yup... that's a big deal for us.

Re: Human JavaScript

#28

Post by HenrikJoreteg »

warfangle wrote: post #26
HenrikJoreteg wrote: post #19

Earlier quoted context omitted.

Browserify has had source maps since v2: http://thlorenz.com/blog/browserify-sourcemaps Just pass {debug: true} to build function.

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.

Re: Human JavaScript

#29

Post by HenrikJoreteg »

warfangle wrote: post #25

> "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 app loads. From my experience, with a primed cache it's not too difficult to get comparable load times to opening a native app.

I'm hoping ServiceWorkers, Improved local databases, and HTTP 2.0 can help us out here.

There's also the option of trying to do the initial render server-side. I've experimented a bit with this, and have some more thoughts and approaches I want to try for this. But, I have yet to see someone do this is a way that didn't add a significant amount of complexity to the codebase :-/

Re: Human JavaScript

#30

Post by odiroot »

klibertp wrote: post #17
odiroot wrote: 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.

Until recently I didn't even know that there was a status quo in the frontend development. I worked with JavaScript in exactly the same way I'd work with any other language where stdlib is minimal at best (like Scheme or C) and that was to design the app, fill as many blanks as possible with libraries and write the rest myself. Now I'm forced to use Angular and frankly, I'm frightened. There is no room for designing…

Hi, likewise :)

On topic: agree on Pyramid / Django comparison. It was a nice, eye-opening experience to work on Pyramid project after only Django-based ones.

Though I doubt the same applies to Angular / Ember.

Post reply on HN