Slashdot Mirror
How Much JavaScript Do You Need To Know For an Entry-Level Job?
Nerval's Lobster writes: JavaScript is a programming language that's easy to pick up, but extremely difficult to master. Even some of its beginner-level functions are decidedly not beginner-friendly. When someone lands their first JavaScript job, they're going to want to know as much as possible, if only so they can navigate through some of the language's trickier aspects without needing to ask for help. Developer Jeff Cogswell picked through JavaScript and came away with a couple of lists of what he thought were the minimum baseline of skills for JavaScript use in a work context. That list included understanding how to use built-in objects, functions , closures, and DOM (Document Object Model). While his points are comprehensive, not everyone will necessarily agree with what he lists (and doesn't list).
There are no entry level jobs. Not for Americans at least.
All of it.
> JavaScript is a programming language that's easy to pick up
this statement is the single biggest source of damage to the ecosystem of javascript.
Brush up on Node or Io and you should to be good to go, bro.
If it's a web design job, you probably just steal someone else's modules and code like most web designers. Complete with not even changing the link back to their website.
For other jobs, why the hell are you using the abomination that is JavaScript anyway?
Last week it was "How much C++ do you need to know for an entry level job"
next week it'll be "How much Python do you need for an entry level job"
Must be nice crowd sourcing your job requirements from Slashdot.
Java != JavaScript; not even close, really.
Next question.
For a number of websites that I visit routinely, I disable javascript - too much overload. If you want to work for those websites, I will ignore you. Learn to code clean html without javascript - much better.
When did the syntax of a specific language become more important than the art of computer programming itself?
Java sounds like a great reason to get out of IT entirely!
also 90 years of experience with Windows 10.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
If you want to do JS in the browser you likely won't use the DOM but stuff like AngularJS.
For the back e.g. nodeJS end you need no DOM either.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
... is the ability to say "No" to an idiotic team leader who thinks it's OK to display nothing but a blank page when the client is behind a company firewall and JS is blocked or constrained or not available on a low-power embedded system.
Graceful degradation seems to be a lost art among many so-called "JS experts" who seem to have no idea how to make a website resilient to client diversity. If you can deal with their nonsense and show them a better way, you'll be worth your weight in gold to the company.
While Angular and React might be all the rage today, you're expected to be an expert in whatever framework comes out tomorrow.
You should be able to write the same Todo List application several thousand times, justifying the existence of each one.
You should also demonstrate a strong desire to re-implement every single piece of software in existence in Javascript, including Linux (http://bellard.org/jslinux/), 8bit Console Emulators (https://fir.sh/projects/jsnes/), and possibly the software that drives your Kuerig. For example, I would expect you to tell me that you're just dying to start a new github project where you'll re-implement MS Flight Simulator 10 in Javascript, and how awesome the cockpit checklist feature will be.
You must demonstrate a complete misunderstanding of the differences between asynchronous and concurrent, and you must also be able to give a short presentation on what "web scale" means, without being able to explain it. You'll probably win a few favors by throwing in the term "cloud".
This and more, is what it takes to be a 21st century javascript developer.
I'm god, but it's a bit of a drag really...
It's a shit language, but it's here to stay.
And even as a shit language, it's still preferable to python.
The biggest problem with it are the twits who are using it on the server. I learned 15 years ago that server side javascript was a bad idea; and now we have fucking node.js
I'm anxiously awaiting the twits who insist on using that shit on the server to give the fuck up and go back to their browsers.
Real programmers use C and provide the foundation that web kiddies rely on to get anything done.
Now get off my lawn.
Considering the comment, glad you did.
to know that you don't want a job maintaining JavaScript. Okay, truth be told, "maintaining JavaScript" usually means "tear out this utter piece of shit I don't understand and replace it with useful code I developed." Then when the next guy comes along, rinse, repeat.
someone that knows JavaScript is not Java
Your comment is a perfect example of Cockfoster's Law in action: When a professional computer programmer with decades of experience presents a thorough and insightful analysis of a contemporary programming language, some shithead will always come along and babble about getting off of lawns.
Anyone who can ask this question cannot possibly know enough javascript to get a job where they will be required to program in it.
It takes a freaking rocket scientist to properly check for 'equals' in that language. If you don't think so, the odds are extremely high that you are doing it wrong.
I would (almost) rather someone force me to learn PERL, rather than ever seriously programming in javascript again. I'm sure it's not the worst language ever invented, but they gave it the old college try, and unfortunately for the rest of us, it caught on.
I think the author is wearing blinders based on his previous positions. As someone who has spent the past 4-years 60-70% writing JS (and irregularly since the 90s) most of what he considers important is almost never used.
Because that's all it takes to learn Javascript...
https://www.youtube.com/watch?v=Ukg_U3CnJWI
One is essentially a toy, designed for writing small pieces of code, and traditionally used and abused by inexperienced programmers.
The other is a scripting language for web browsers.
Is this Dennis Ritchie? Thanks for the enlightenment Einstein!
A few months working with jQuery.... Events.... DOM on realistic websites, some fiddling with Prototype.js, and you'll be fine.
Thas' assuming you know programming in general, and not just Javascript, and had time to learn Javascript's language quirks, such as functions, variables, conditionals, ===, strings, integers, dates, custom objects, and basic structures.
We could all use a little K&R in our lives.
Most of my career has been bumbling along doing systems programming in c, perl, python, and lately c# writing a lot of console apps/utilities. Unfortunately, everyone now wants web developers and the like, so I find myself in the unenviable position of playing "catch up" and facing the possibility of having to return to a jr. role due to "lack of experience", but I'm not so proud to do these things if it gives me a steady paycheck with room for advancement... I digress...
I'm going through Eloquent Javascript at the moment with a look towards the SImpson "You don't know" series to get a little more in-depth in some of the areas that I see people having issues with.. followed by working with node and angular (basically, the MEAN stack). I don't know where this would put me vs "beginners", but it's the route I'm headed down.. :P
If you were me, you'd be good lookin'. - six string samurai
STFU already Dice. We won't fall for your click bait articles.
The basics of JavaScript you need to know are:
Then, you need to learn the basics of the libraries that are advertised in the job posting, which will likely be:
Finally, you need to know how to look stuff up on Mozilla Developer Network, which is the only JavaScript documentation worth looking at anymore.
If you want an entry level programming job and don't have any experience, you'd had better made something non-trivial on your own time that you can show in an interview and explain the code. If I'm skimming your code and I see you picked a certain data structure or implemented a algorithm when there is more than one way to do it, you should be able to explain your reasoning for coding it the way you did. Also make sure you learn at least the basics of one of the popular frameworks and use it in your demo.
So make a Javascript web app, or something on the server side with a free or low cost hosting account. Make it functional, make it as bug proof as you can, make the code clean and easy to read, and be prepared to show it to a skeptical audience. Think of your interview as an audition and your code as the music you're going to play.
If you can't make something to show, you don't know enough Javascript yet.
It's interesting to me to compare Cogswell's post to Matt Briggs' one on the role of senior developers here. http://mattbriggs.net/blog/201...
It seems to me that Briggs has the right of things; the skills that bring real value to development efforts are less connected with specific language functions or quirks and more associated with understanding how to develop software projects.
You just need to read [JavaScript: The Definitive Guide].
Read it cover to cover a couple times
Why not just read the good parts? Bonus: knowing the good parts of JavaScript may help you tame the fractal that is PHP as well.
Pick a mainstream web page as an example of visually ugly [JavaScript] code! They're everywhere!
That's because mainstream web sites have minified their scripts. This process removes blank space and shortens variable names in order to pass fewer bytes over the wire.
Stop trying to say that it is. It happens with Node, Angular, and other stuff to a lesser extent, but jQuery seems to be the de facto JS gap-filler that everyone insists is part of core JS skills.
But even worse are the feckless noobs who say they don't know JS, but know jQuery instead. That's like saying "I don't know English, but I know its verbs."
The biggest problem with it are the twits who are using [ECMAScript] on the server
Without using the same language on the server and client, and without repeating yourself, how else are you supposed to have both client and server perform the same input validation logic?
Open the "Reply to This" link in a new tab and you'll get the no-JS version of the comment composition form, which I'm using to enter this very comment.
Say you're designing the front page of a news or blog site. You want anonymous visitors on small "mobile" screens to see a list of headlines, but you want anonymous visitors on larger "desktop" screens to see headlines and a one-sentence summary of an article. Anonymous Coward says script is better than User-agent sniffing. How would you implement sending only headlines for mobile and headlines plus first sentence for desktop?
I swear to God, you can pick any 10 words at random from a dictionary and 4 of them will be the name of some half-baked framework.
So in what language do you write input validation logic for the server, which gets translated into JavaScript to be used as input pre-validation logic on the client? Writing it twice, once in JavaScript and once in your preferred server-side language, is repeating yourself and can lead to subtle disagreements in behavior between the two implementations.
So how do you deploy your client-side C code to 14 different client platforms? Consider that some of these platforms have onerous developer qualifications designed to discriminate against startups, a devkit fee of thousands of dollars, and final veto power over apps. I guess perhaps you could use Emscripten to, well, compile your C into JavaScript.
Forall X? Honestly, the DHI shilling has a mediumish level of intrinsic offensiveness which is greatly exacerbated by lazy content-mill plugs and gender trolling. If you're going to abuse a non-captive audience, there's a cap on the level of abuse possible. And if you didn't know what to do with Slashdot, which you plainly don't, why buy it? What was the theory? Enrage, bore, and alienate the readership, then...profit?
I think I'm going to go on a Slashdot vacation until there are no more dice plugs. Any suggestions for alternatives? Soylent news seems like it might be nice one day, but it currently has less traffic the official star wars holiday special forums. Reddit is full of beautiful microcommunities of people who can go days without experiencing a complete thought. Maybe I'll just go reread old k5 posts from 2000.
because you know it's true
It takes a freaking rocket scientist to properly check for 'equals' in that language
In both PHP and JavaScript, === checks whether two expressions have the same type and value. Anyone who read Douglas Crockford's JavaScript: The Good Parts knows that. Now can I work for NASA?
Your complaint is that a script language is not Object Oriented enough? Are you the same guy who complains about Perl and Python not being Semaphore ready? It's a scripting language! Scripting languages are not really intended to be object oriented, they are intended for task management with pragmatic functionality. JS has about the same Object Orientedness of Python or Bash. You can use those scripting languages for some pretty complex stuff and define all the functions you want. You have a massive performance penalty, but you can.
There are surely a couple of valid complaints about JavaScript. Like:
1. Lack of consistent implementation and/or libraries by every browser vendor and often even version to version in the same vendor.
2. Lack of documentation on functions that are built in, so it's a huge amount of trial and error.
To TFA's question, just like the same exact question 2 weeks ago about C++ it depends. If you are creating a custom front end for an ERP system, you had best be up on lots of JS, including all of the various browser implementations your app needs to support. If you are writing simple proxy auto configurations or simple web pages you need to understand coding more than subtleties with the language.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I have seen shit code in every language I have worked with. Starting with Cobol and Fortran, then to Pascal, C, Perl, Python, and various *SH. The language is not the reason for the shit code, it's the programmer.
Want to read some great JS, go get a WordPress rootkit. JS is used to it's fullest in those (no I don't use them, I spent years learning how to hunt them down). PAC files are another area that usually has well written JS, and plenty of examples exist.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I've been working in JS for years and there is no such thing as some "minimal amount" you need to know; the language and the DOM are just too fucking disorganized and sprawling. The syntax is garbage and constantly evolving, who can remember the differences between innerText and textContent? Then there are the platform specific inconsistencies: event handlers or Ajax requests are maddening without external libraries. Then there is the pseudo-standard tooling for which there is always 2+ competing solutions: NPM and Bower for asset management, CommonJS and AMD and WebPack for packaging, Gulp and Grunt for builds, Closure Compiler and Uglify for minimization/compiling ... it's maddening!
Trying to keep even a fraction of that in your head is impossible. If an employer wanted me to do an intense coding session without Google, I would laugh and just walk out of the interview.
...the proper answer should be "none."
I don't really care what languages people know when I'm interviewing. I care how they think, that they have the ability to solve problems, and that they know how to research to get themselves out of holes. The specifics of any given language can be learned on the job by a reasonably smart person who understands how to break problems down and solve them algorithmically, and if they know how to use Google they'll be able to pick up the syntax of whatever the language of the day happens to be.
I really don't understand this fascination with checklists and expecting people to have memorized giant chunks of specific languages or libraries when it comes to programming. Just show me some stuff that you've built on your own time, in any language, and talk with me about it intelligently and convince me that you didn't plagiarize the code. That's what matters most at entry level, not whether or not somebody has used closures or promises or whatever. They can learn that stuff as they go, usually in short order, if they're actually smart.
picpix image polls. create - share - vote. fun!
This. This just shows the skills level of people working with the language. I have been programming for 30 years and have seen & used a ton of languages myself, including COBOL, Fortran, PLI, REXX, Pascal, Assembler on various processors & architectures, C, C++, Java, C#, Visual Basic, SAS/SCL, R, Matlab, Ruby, Perl, PHP, Python, JavaScript, not to forget the likes of 4GLs and document languages among which SQL, SAS, HTML, Script, Bookmark, LaTeX , XSLT, as well as a few batch scripting environments on all walks of operating systems. My programming mileage is likely on the upper side of 750'000 to 1 Mio LOC (estimate), not including the miriads of code reviews and maintenance jobs. In other words, I know my way around. Over the years I have also written several of what today goes by the name of DSL, internal and external.
In my conclusion, by far the worst language by any standard is XSLT, right next to COBOL, quickly followed by Visual Basic especially in its scripting incarnation a.k.a. VBA, what a mess. Follow this up by the body of code written in (badly crafted) Perl, and you've got yourself a pretty descent nightmare. Oh and that's not even considering PHP, which even by the words of its creator is technically not a programming language - it is just a pile of crap built ontop of another pile of crap (Pile of Huge crap, on another Pile).
However, JavaScript is certainly not a bad language, at all. It has a well thought out syntax, a consistent type system and a nice language-provided library. The ecosytem is vast and provides most everything you'd need and want. I've been using JavaScript's object oriented features both on client and server side, for almost two decades now, i.e. ever since the language existed, and long before it became mainstream to do so. All I can say is this: if you think JavaScript is a mess, you have yet to master a few basics of computer science & math, such as data structures and basic algorithms, and certainly higher order functions. Anyone with said set of knowledge and insight will immediately get how to write efficient and quality code in JavaScript. If you don't, and still think global variables are the best thing since sliced bread, so easy to access, more of that please, well then my friend, qith all due respect, it's not the language that sucks.
On the OP article, the key skills that are totally missing on the list are to understand how to modularize applications, and probably even more important to know the commonly used tools for build and package management, like grunt, bower and npm, as well as testing frameworks like e.g. Jasmine or JSUnit.
Write a shopping list app. If you have a significant other, you'll be a hero, and besides todo apps are so 1990. Use a framework like angularjs to learn front end MVW, and learn how to consume web service calls that deliver json to populate your model. There will be enough javascript in this small app for you to wrap your head around it. In an interview, smugly say "I know jquery, but I avoid it". That much should at least get you out of the bottom of the pack.
If you want an entry level programming job and don't have any experience, you'd had better made something non-trivial on your own time
If someone has made something non-trivial, then they have experience.
Framework developers stopped using real words a long time ago.
Then you need not know any JavaScript. Otherwise, you need to have read at lead 2 books on JavaScript and have made several professional looking websites utilizing it.
By definition, the answer is "none". An entry level position doesn't need to require experience in a given programming language. It needs to require some familiarity with programming, sure. There is all kinds of stuff you probably should look for in such an individual. Aptitude to learn (from your senior and mid level developers who you picked partly because they are good at sharing knowledge), existing understanding of symbolic logic, common software design concepts like when to use sets instead of lists, the list (pun) goes on.
It is really absurd how snobby software developers are about who joins their ranks. Part of the absurd job req ads in tech aren't just due to hr managers trying to game the h1b system. They are in part there because of clueless software devs who have been moved into management because that is (for god knows what reason) considered a normal career path. Don't respond with "it is better to have no one then to have a bad coder!". You're right, but inexperience with a given language doesn't mean they won't be productive with that language in two weeks to a month. This is the very definition of entry level.
For reference: http://youmightnotneedjquery.com/
If you are "entry level", you should NOT be writing anything using jQuery unless jQuery is already used for a significant part of the project. So many damn times I see people load the goddamned jquery library just to do a lightbox effect that could be done in straight CSS!
Before you do something in jQuery, make sure you can't already do it with straight CSS/HTML.
Beyond that gripe, learn C so you know what you're doing. Learn to initialize variables, it's easiest to explain this coming from C context because you can run a program in C that didn't initialize variables, and it will work ONLY the first time. Every subsequent time it will use dirty memory and as a result not work. In Javascript, it's assumed that memory is pre-initialized. It is not. This is how a lot of drive-by malware exploits bugs in browsers. By finding that function that assumes memory was properly initialized and breaking where the instruction pointer should be reading data instead of code. Once you know why variables of are certain sizes, lots of things make a lot more sense in Javascript, and it makes it far easier to optimize by not needly creating global variables when you need locally scoped variables.
Script, plus everything else except comments. Both support /* */
This would have been more funny 10 years ago when people still said 'Java applet' without laughing and both statements could have been applied to either language. I rather like the top answer though: 'Java and Javascript are similar like Car and Carpet are similar'.
I am TheRaven on Soylent News
Assembler. C.
I'm also a programmer since the '70s, and the list of languages / OSes / systems from big iron down to the embedded that I've been involved in is almost similar to you --- except one
LISP
Have you tried LISP?
Try it -- you'd love it!
There's a nice paper from the developers of the Apple Newton, which argues that class-based OO maps very well to model objects (where you have lots of objects that are mostly the same), whereas prototype-based OO is a better fit for views, where you want a bit of customisation for almost every instance
Perhaps I'm kinda dense today ... I just couldn't find that 'nice paper' that you have mentioned
If there is a link somewhere, would you kindly share the link with us?
Thanks!!
Muchas Gracias, Señor Edward Snowden !
When I was a hiring manager the joke was "I'll hire anybody that spell computer"
Do you know what jquery is? Do you know what DOM means? You're hired!
None. But it would be weird if you didn't.
Religion is what happens when nature strikes and groupthink goes wrong.
...a "thorough and insightful analysis", but I only got a rambling post of ZERO value.
Wrap your head around promises/deferred's. Event firing and handling still has its place, but that place is shrinking.
Probably the most heavily used technique in modern js is the async call wrapped in promise/deferred methods. Hell, more and more often non-async methods are wrapped in a promise for (apparently) no other reason than to take advantage of chaining.
This is one area that is getting messy as hell real fast as there arent yet many established patterns for this shit.
Too many of these "how much X do you need to Y" filler articles!
The key is to really understand how closures work (and by extension, why javascript "classes" look the way they do). If you manage that, the rest of the language just comes easy and shouldn't be an issue. ;P
JS alone will get you nowhere. JS is part of todays web ecosystem. And developing for the web today is so hard, people doing it are either inexperienced and naive or - like me - sort-of specialized/focused in some vertical toolstack like LAMP + Wordpress + Bootstrap or something and never really happy with their results.
The problem is, that you have to know HTML5, CSS3, DOM perhaps some jQuery UI or HTML canvas stuff + UX + responsice webdesign + Typography & Layout + a workable set of backend tools (LAMP or such) to do anything usefull with JS. Which makes the whole thing basically impossible for an "entry level" developer to learn.
I suggest you find a team that has a working development pipeline, uses versioning (far to many webshops don't) and puts out good results and learn by doing.
As for JS in general - there's a lot of academic ragging on JS here, but most of it misses the point about JS entirely:
JS alone is like a mix of Python and Ruby made to look like Java (yeah, I know) and doesn't look very modern. However, what makes JS interesting is the fact that as a platform it is available basically anywhere. JS is todays PC of platforms. A toy, not taken seriously by anyone, but available for cheap/free everywhere. Which is why it is going to win in the long run, just like the toy-technology x86 did, eventually squishing every other architecture like a bug on it's way to total world dominance. In the early eighties, people would've laughed you out of the room for predicting that.
I personally wouldn't be suprised if JS eventually replaces PHP, Java and Co. on the serverside and takes over everything but system development on the clientside within the next decade or two. Be it natively or with languages that cross-compile to JS ... We already have a ton of those. Google is heading for bringing the second half of humanity online, and as far as I can tell, they're succeeding. Which in itself does put JS in a future-safe position.
JS, Browsers and the clientside webstack are a mess, but they are truely cross-platform, open and not controlled by a single entity. Very much like x86.
So no matter what you're doing, getting into JS at a professional level one way or the other isn't the worst thing to do.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
The right way to do that sort of thing becomes clear when you think about it for a bit: Most of the time the only discernible purpose of all that stuff is to slow down the "user experience", make it less intuitive because different from expected, and so on. The solution is to take all that javascript reinventing wheels, badly, and just doing away with it.
It really isn't hard to take those bits of text and pictures that still make up the majority of websites, and generate the requisite html boilerplate around it once after editing, add a bit of css to dress it up, pre-compress everything, and serve it with a super-fast static-content httpd. No need for backend databases, CMSes, or javascript in the browser, stealing cycles at every page load in the client for what really should've been done once serverside and simply served up whole afterward.
> a consistent type system
Mwuahaha. I was following you until you said that. With JS you get stupid automatic silent conversions that are the source of hidden bugs. And just to drive the point home (JS starts @ 1:22 )
* https://www.destroyallsoftware...
Javascript's == operator is fundamentally broken as this chart shows:
* http://dorey.github.io/JavaScr...
When even Douglass Crockford, who wrote the excellent "Javascript: The good parts" says @34:31 "Why am I betting my life on this piece of crap" in this video "Javascript: The Better Parts"
* https://www.youtube.com/watch?...
You know there is something horribly broken with JS.
A few years ago, I worked for a very small, very talented IT security company that was acquired by a large multinational. When I started, there were maybe two Indian programmers in the entire company (~100 people). When I left a couple of years later, the entire development wing was Indians. I learned from a manager friend there that the Indians were being brought in and the Americans were being replaced because of cost. The Indians were being paid around 60k a year vs 90k a year for the Americans.
This company was founded by two American men to secure American companies' networks. I call shameful. The founders were driven out and the company sold to the aforementioned multinational. The company now is 95% Indian. The friend survived a few rounds of layoffs and left because the smell of BO and masala was too much for him to handle (literally). He was literally not taken seriously by the Indians, who hired their own despite my friend being able to code rings around these guys. He said their code was "OK" but the Americans wrote better code.
The Indians literally re-wrote things in Java and switched the DB over to Oracle because it was all they knew. The original stuff was all C/C++ running under BSD and PostgeSQL. The Indians converted everything over the Windows. As a result, the systems became hideously unstable and the mission altered. I still cannot, to this day, fathom why anyone would have bought this company after the bastardization of the mission and tech that was built from the ground up by very talented people.
Look at Disney now. All the Americans are being replaced by foreigners and for why? To save a few shekels. American companies should be ashamed -- all for a little money. I'm thinking of starting my own IT company, and I can tell you this straight up. If you are not American -- born here -- I will never hire you. This can all be done legally.
Wish I could RTFA, but these annoying "social media" icons are plastered across the middle of the screen, floating with my scrolling.
:P
Yes, I know JavaScript can be used to remove them, but the point of TFA is (supposedly) that I don't know JavaScript.
The problem with JavaScript is that it appears easy, but in reality it is a fairly complex language that requires skilled programmers to use correctly. I would be more apt to hire an entry level programmer for C/C++/C#, and leave JavaScript for the more senior developers who can use it correctly.
Someone without a lot of experience with good coding practices and software architecture concepts may be able to write some "working" JavaScript, but it will probably be unorganized spaghetti code that is impossible to maintain, inefficient, and probably contains a ton of undetected bugs.
I am a team lead, and If you want to get hired at the company I work for.. all you have to be is smart and not too socially toxic.
Sure, we give a programming test that basically asks "have you ever written any code in any language?" 90% of applicants fail this test (Think Fibonacci or leap year level difficulty, not 9 queens or tower of Hanoi hard). Any applicant that passes the "have you ever written a line of code" test, we just talk.
I don't care if you know node.js or angular.js or Knockout or whatever. Angular and node are both 6 years old. If I required every developer to know everything about a 6 year old framework, what happens when something better comes along? How hard will it be to get them to use the new thing, or learn it. If I hire a smart person who can learn whatever, then when something new comes along they can learn that too.
Encyclopedic knowledge is not a selling point by itself. FAQs are free, brains are expensive. Hire the brains and feed them FAQs, not the other way around.
The minified JavaScript file is smaller than the corresponding file before minification even after both are gzip compressed.
Great minds think alike ...
Wrote this yesterday on the other site ...
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
So how do you deploy your client-side C code to 14 different client platforms? Consider that some of these platforms [are controlled by an entity with] final veto power over apps
Package it using an exploit kit ;-)
We saw how badly that went for George Hotz.
Javascript can be an interesting language if you embrace it and keep it simple. If you already know how to write eloquently in any language you can continue to do so in javascript (and the reverse is also true).
I prefer to create classes (of course they are really just objects) to encapsulate my object and behavior. I use inheritance sparingly and when it is really obvious.
I keep my classes generic (so each class refers to itself using the this keyword and not the implementation variable name) . This is important and it will force you to learn about scope. Unless you use inheritance keep your objects immutable.
I use libraries (example jquery) as a convenience and only its simple syntax. For example $('#myVar').val() $('#myVar').html() but not some monstrosity like .second .item span p.bold').html(). Keep it really simple and figure out how to write your code so you do not include this kind of nonsense.
$('#myVar li
Do not depend on complicated functions in libraries. Behind the scenes they still need to do the work. If you use jquery realize the library has already iterated the dom so you can make use of it (for example: jquery delegate is rather cool and does not cost extra).
I like this Simple JavaScript Inheritance library (John Resig): http://ejohn.org/blog/simple-javascript-inheritance/
a lame (and quick) example of what I mean by class: ..ajax...}
var pform = {
submit(args,callback){
updateCities:function( this.submit(province,citiesSuccess) )
showHelp:function(){}
validate:function(){}
init(){
delegate();
delegate();
delegate();
}
}
something was missing: ..ajax...} ...
var pform = {
submit(args,callback){
updateCities:function( this.submit(province,this.citiesSuccess) )
showHelp:function(){}
citiesSuccess:function(response){{}
validate:function(){}
init(){
}
}
I haven't, directly, needed to write any Javascripts in over five years. I've fixed a few nit-wits hand-coded JS, but that's it.
because you're too fucking stupid to make money off them and rather be a broke has-nothing technocrat
except when someone else's code that you call has conveniently changed the variable type on you.
If the type of the value your code gets from someone else's code is either not documented or not as documented, you can A. report this as a bug in someone else's code, B. cast the values to the expected type before doing anything with them, or preferably C. both.
When I was 15 I managed to get an entry level job washing dishes and they didn't even ask me about my programming skills generally, let alone about JavaScript specifically.
Using files complicates concurrent attempts to write, such as if two users attempt to leave a comment at the same time. By the time you write a library that guarantees correct locking behavior for concurrent writes, you might as well just use SQLite and be done with it.
JavaScript: The Good Parts
Unearthing the Excellence in JavaScript
By Douglas Crockford
https://kat.cr/douglas-crockfo...
Casteism
Yeah the Car/Carpet one is probably a better 'answer', but not as funny :P
See subject "Forrest" & this -> http://tech.slashdot.org/comme...
Every comment is its own file, obviously.
This carries three disadvantages compared to use of SQLite:
one command that comes to mind is: grep.
O(n).
If you want an index use Lucene.
So now you're recommending that the server administrator install the Java virtual machine, which is listed on the front page of Lucene's site as one of Lucene's dependencies, as a means of avoiding use of SQLite. Oracle's legal shenanigans aside, I was under the impression that switching to a plan that includes Java support was unaffordable to a lot of shared hosting customers.