Comment by txutxu | Hacker News Reader

Comment by txutxu | Hacker News Reader

Parent Full thread

I think about frontend designers (User experience people). They should know a little bit about TCP, SSL, HTTP, networking, monitoring, statistics, and everything related to frontend markup bloat, bandwidth, compression, etc.

I've work with many of them, very good about Adobe products and Apple last thing, but clueless about, why their final code is of poor quality.

Fortunately, many of them did get their Ego down, when the web did start to move from markup (html+css) to code (js). Until then, they did take any feedback from a sysadmin, as an attack to their work.

About developers and architects... they should simply be the final support (24/7 calls included) for their work and changes.

As a side note... a sysadmin IS A developer (a systems developer). An application developer, usually should be a systems developer if he/she is working in a project that includes a platform to run (unless he/she is just uploading an app to any appstore). An operator with limited privileges, is just that. The concept of "pure developer" or "pure sysadmin" is so 199x...

> They should know a little bit about TCP, SSL, HTTP, networking, monitoring, statistics, and everything related to frontend markup bloat, bandwidth, compression, etc.

This is why Ilya Grigorik's book, High Performance Browser Networking, exists. It's a great reference to that end as well.

This book is also available to read for free on http://chimera.labs.oreilly.com/books/1230000000545/index.ht...

Agree with most of the list but why is TCP important for frontend developers? I'm struggling to find the arc for that one that isn't abstracted away much like CPU pipelines are for back end devs.

A front end developer should understand that a TCP request (i.e what an HTTP request is) consists of a handshake which means to receive a file from a server, it takes roughly 5/6 calls to and from the server. So if your UI consists of 1000 100b files, that's 6000 calls. So you would probably be better concatenating them to a single 10Kb file.

But then you need to understand the differences between HTTP 1.1 and 2.0 and how it handles multiple requests from the same page. 1.1, you would probably be better off with a single concatenated file, 2.0, perhaps several. And then what about compression? Any good UI developer should be considering compression of that file, cache control, etc.

I see too many front end developers shy away from this stuff and create bloated monstrosities. They feel it's someone else's job... but if not the UI developer, then who??

I guess my point was more that even just if you understand HTTP then you'll get all those insights already. A bit pedantic I suppose.

This stuff does get pretty complicated. Mainly because the tech is evolving fast (browsers do a lot of tricks now). Even in HTTP 1.1, there are times where multiple files might be more interesting due to how large files are handled

But can you really understand HTTP without understanding TCP?

I prefer to work with a frontend engineer that knows a little bit about packet loss, routing, load balancing, white/black listing, retransmission, packet fragmentation, latency, mobile connections, socket limits, common error messages on network diagnostics, etc... that with an engineer that just knows "the page is slow".

Well, indeed, the higher level protocols, like HTTP, DNS, etc, are more useful on a daily basis.

Reply on news.ycombinator.com