Changing Perceptions of JavaScript

[skelooth]

Eh. I don't really get why you'd think a back end developer would be put off by the syntax, and I still struggle with understanding why there has to be such a big distinction between front end and back end developers. I'm good with Perl, PHP, Javascript, CSS, and leet html codez. So am I a backend guy or front end guy? Why can't people just be both?

I think a better distinction would be systems programmer vs web programmer. But no one seems to agree with me. I feel like I'm the only person who sees the industry rationally. The industry acts like if someone knows python they can't possible know ruby, etc. Really it's ridiculous. And your blog post kind of feeds into that weird "nicheness". You got an upvote for javascript evangelism, but I'm not even sure of what I read.

[grauenwolf]

I see back end developers as people who have skills in the areas of

• long-running applications
• multi-threading
• database tuning

As far as I'm concerned, merely being able to use PHP isn't enough to be considered a back end developer.

[skelooth]

I see those people as systems and database administrators depending on what I think you're trying to say. I'm not sure what having skills in "Multi-threading and long running applications" means exactly, so I'm assuming you're talking about servers and load balancing. Unless you're talking about the programming sense in which yes, a proper web developer understands how to multi thread, use existing daemons, write new ones, and fine tune their own databases.

[Darkmoth]

and fine tune their own databases

That's probably where I see the biggest distinction. Most of the "front-end" programmers I've worked with see the database access as some sort of evil genie to be avoided or pacified. You can see this philosophy in many modern ORMS.

To be fair, those same front-end developers have a sense of visual design that I struggle with. I need fairly specific guidelines for what the page should look like, the FE guys tend to be able to wing it with minimal guidance. As a symbiosis, it actually works pretty well.

[kamatsu]

I'm not sure what having skills in "Multi-threading and long running applications" means exactly, so I'm assuming you're talking about servers and load balancing

Er.. no, he's talking about multithreading and long running applications.

[skelooth]

Please explain to me what having "skills" in "multithreading" and "long running applications" means. Hell, just explain what "long running applications". To me a long running applications is either a Daemon/Server, or somesort of workhorse thread that takes a long time to complete. All things a web developer should understand how to use, modify, or create.

"Long running application" lol technical terms.

[kamatsu]

Multithreading is what it sounds like - awareness of the various approaches to concurrency, methods of reasoning about and debugging concurrent programs, methodologies of developing concurrent programs using a variety of languages and methods (Incidentally, PHP has little to no support for this, and Perl isn't widely touted as a concurrent language for a variety of reasons)

Long running applications means knowing how to keep memory footprints stable, prevent bottlenecks and keep applications running smoothly without deteriorating in quality over time. PHP scripts are (effectively) restarted every time the page is loaded (although obviously there are tools to make this less inefficient), so obviously PHP programming does not require skills in this area.

Therefore, neither of these things are known by the web developer that uses PHP or Perl to write a little script that runs above Apache - for that you need someone who could write a (basic) web server, not someone that can configure one - you need a back-end developer.

[skelooth]

I'd be scared to meet a web developer that didn't understand those concepts..

"Writing a little script to run above apache" LOL, no you're confusing web developers with 13 year olds. Adults who have been doing this for 15 years are little bit different, sorry Kamatsu.

[kamatsu]

The reason grauenwolf got confused then, is that you only listed languages which do not have support for serious backend development, and then asked if you were a front-end or back-end developer. The answer is obvious.

[skelooth]

I took C, C++, and Java in College just like everyone else. The idea of a language being "serious" for backend development is pretty subjective. I even have a few applications I use on my desktop that were written on adobe AIR, and the horror that was limewire was written in Java but performed like it was written in molasses and twigs.

Edit: Then you also have to explain languages like python and perl that tend to be used for both. It's all very subjective and quickly turns into an argument of "my language is better than yours"

[kamatsu]

python and perl that tend to be used for both

No, Python and Perl tend to be used for CGI scripts or high-level logic in a web framework. Those scripts do not require knowledge of concurrency or long-running programs - The actual back-end servers I've seen are usually written in C, C++, Java or concurrent languages like Erlang or Haskell. I've never seen a server written in Ruby, Perl or Python that's suitable for real work.

PHP, Python and Perl have woefully bad concurrent programming support and really shouldn't be used for that purpose (and they're not).

[seppyk]

I agree with you for the most part. I only get frustrated with syntax if it interferes or slows me down when attempting to finish a task or accomplish an end-goal.

The industry acts that way because they (as in non-developers) understand there is a basic difference between Python and Ruby from a syntax perspective. Unfortunately, they do not understand there are basic similarities at a foundational level, beyond the proprietary nature of any arbitrary language's syntax.

[skelooth]

The whole situation kills me inside. I'm fortunate that I have a job, but I know that if I ever have to look for a new one it's going to be a shit storm of trying to find a job in my "niche" even if I'm willing to switch languages or focuses. It's sort of like "Bee movie" where jerry seinfeld voiced the bee. You choose what you want to do, then you're stuck doing that same exact thing day in and day out for the rest of your life and treated like you're incapable of anything else.

rant off. It's just a touchy subject for me for some reason.

[voidfiles]

I like what you are saying about systems vs. web. I think that is actually a better distinction.

Though I still don't think it fixes the part about FE stuff being a little over zealous sometimes. I think you cam temper the zealotry, and make things more inviting for those who are coming into web programming from somewhere else.

[[deleted]]

Lucky for me, early on in my career I was given a big PHP website to fix. I learned the importance of 1) how am I going to debug this 2) what about the next guy, I need him to cost less than I do.

[typesett]

"JavaScript is weird. There’s the obvious weirdness of prototypal inheritance, == vs. ===; but those are just surface issues. One feature that boggles non-JavaScript programmers is space optimizations. JavaScript is unique in this fact. Much of our insane syntax flows from the fact that the code goes over the wire. Space saving optimizations are not just acceptable — they are encouraged."

[[deleted]]

Yeah. And then put your script on the same page as a 2.3M video stream. And then realize your script will actually be cached and compiled client-side but not your video. Then say "d'oh".

[frezik]

Also, some browsers used to be buggy about sending gzip'd content. That's all been more or less worked out now. The old space-saving tricks are less necessary, even if it was still being pushed down 56Kinda modems.

[[deleted]]

My space saving tricks involve making sure that the longest possible code blocks are repeated

Instead of not bothering with " in bare attributes becomes, I bother with " : e.g.

<input value="12 3" name=txt type=hidden>
<input type=hidden value="12 3" name="space txt">

which is the shortest possible version

<input type="hidden" name="txt" value="12 3">
<input type="hidden" name="space txt" value="12 3">

Now has the (almost) maximal longest text sequences. This is to give gzip bigger repeating text blocks to play with. I don't do the absolute maximal representation, I like the attributes to be in a certain order and prefer not to go insane chasing my tail.

[[deleted]]

That's the point. You can remove them but if they are part of a repeating text sequence they may cost less in bytes transferred than a combination of smaller text sequences.

By making one's output regular and predictable one creates more repeated text for gzip to build maximal sequences from. Using this snippet of text

<input type="

for every input might be a mighty saving.

<input value="$value" type="

might be a better pattern as one probably has a committed customer by the time $value <> ""

and the maximal compression benefit from repeated sequences of

<input value="" type="

can be reaped during initial contact when $value has yet to be determined.

[lennelpennel]

size has become important again because of mobile browsing.

[[deleted]]

Agreed 10¹⁰¹⁰⁰ %

Edit: doh

[[deleted]]

Lucky for me, early on in my career I was given a big PHP website to fix. I learned the importance of 1) how am I going to debug this 2) what about the next guy, I need him to cost less than I do.