Programming tends to this pattern where people get super-excited when a language gets a feature everyone else has taken for granted forever. It's like a guy getting out of the hospital after shooting himself in the foot. You know what's better? Not shooting yourself.
Congrats Javascript--on almost being as good at data-binding and layout as VB6! Me, I'm going to keep kvetching about javascript frameworks until flexbox is widely supported, the strongly-typed language flavor-of-the week actually is stable, and frameworks like angular don't embrace silent failure modes as a feature.
Yes yes, everything that's happening now has happened before with other technologies. Except this time:
1. it's in a runtime that is in more machines than any other in history.
2. can be loaded instantaneously with no installation procedures.
3. and no plugins
4. On almost any platform, linux, mac, windows, ios, android, windows phone, blackberry, palm, chrome OS, even game consoles. Including the nintendo DS!
5. is broadly accessible to people with various kinds of disabilities
6. doesn't require a team of 20 engineers taking 4 years to build. (which other tech has achieved, and arguably much better, but not combined with the other things above)
7. Works on miniature computer machines small enough to fit in your pocket, and can download your app wirelessly. From the air. in your pocket. FROM FUCKING OUTER SPACE
(incidentally, did HN skip out on the whole ordered list notation of markdown?)
edit;
To add a couple more points:
* SEARCH ENGINES can automatically index your shit.
* We have these things called hyperlinks which allow automatic, ubiquitous and pervasive interoperation everywhere.
I see a common pattern on HN where whenever the topic of javascript comes up, all you see is pages and pages of wretching about how AWFUL it is, and how you could do X in Y language Z years ago already. That's not the hacker spirit. A hacker looks at what's out there, and what's possible, shuts up, and builds something awesome with it. (and then wretches about how awful it was)
In fact, the WORSE the underlying technology used to build something awesome, the more proud the hacker is that they achieved it. Where's that spirit?
Sure it's not as nice to program in as your favourite language or environment, but it's come a long damn way. would you give it a minute?
There's the stuff we wish we could have done 50 years ago but couldn't. There's the stuff we could have done 50 years ago but only one person could do it by making a $1m multi-user computer not so multi-user. Then there's the stuff we didn't even know about. They're all awesome.
Yes, Javascript has genital warts, but I don't have to care. I can write sorta-lisp, which means I can layer my own stuff on top, and it magically works. I mean, emscripten!
The things that I miss, like automatic image-based persistence, are coming back anyway, and they'll be fast, probably open source, and can be integrated in a hazy, drunken, weekend.
Absolutely not. These statements are boring because everyone knows there are javascript everywhere on the internet. But so what? We should pay more attention to GOOD languages rather than popular languages. It's not javascript a great language but the people made the products great people. They could do even better if javascript is not so popular.
What about javascript's popularity, exactly, is stopping you from making something great? Use whatever hipster language you want, I say. The only question is how are you going to get people to look at what you make if you can't put it on the internet?
Internet runs fine without JS, just like Hacker News... But yes, I should not spend time arguing something which doesn't worth it and go back make some real things.
There are great things in other languages and they are not so hyped like in the JS world. JS is more like a language used to say average (or below) things.
This post is great. The argument that followed was an unfortunate case of miscommunication on both side, oops!
JavaScript has many similarities to BASIC!
At one point, yes, points 1-5 were definitely true. Thank you for reminding me! Don't forget about BASIC!
Here's just a few of really big differences:
1.) BASIC didn't have a DOM.
2.) BASIC didn't have network abilities.
3.) BASIC didn't have advanced language features.
4.) BASIC wasn't didn't load and execute from a simple network request.
BASIC was SUPER important to the command line PC-era, just as JavaScript is really important to the cloud-era.
Microsoft and BASIC... Google and JavaScript...
Because JavaScript is attached to the DOM, and the DOM, aka, web pages, are SO crazy successful at delivering, presenting, archiving and navigating media, it really adds a level of longevity to the language that BASIC could only have dreamed of.
The c64 did, but could you download a basic program from the bbs and run it in place without stopping the modem software? Could that BASIC program then proceed to, in place download more content to view, from same, or any other BBS? We're talking about BASIC here :)
Now, if you wanted to move forward a few years then the Amiga could do those things using some proprietary graphical modem software and a bespoke graphics/interaction language whose name totally escapes me at the moment. It wasn't BASIC.
But, you know, you needed an Amiga to use it, and almost nobody had one.
He said BASIC didn't have networking capabilities. And well, that's true. c64 is a computer. BASIC is a language. they are two vastly different things.
and no, YOU'RE being extra argumentative in this thread.
no they didn't. (what alternate universe did you arrive from?) And /not VB6/ because microsoft lost that battle. And not java, because sun lost that battle. And not flash, because adobe lost that battle, and not unity, because they haven't, and won't win that battle, for the same reasons all the others lost.
1. it's in a runtime that is in more machines than any other in history.
No. Never has, never will be. It's just a plainly obvious fact, no explanation needed.
2. can be loaded instantaneously with no installation procedures.
No. see above.
3. and no plugins
No. see above.
5. is broadly accessible to people with various kinds of disabilities
No. What makes you even barely think this even slightly applies?
6. doesn't require a team of 20 engineers taking 4 years to build. (which other tech has achieved, and arguably much better, but not combined with the other things above)
I'll give you that one, but not without a windows machine, and a multi-thousand dollar piece of proprietary software.
I'll admit I am not sure whether you mean BASIC or VISUAL BASIC. But none of these points apply to either, 6 even less.
Are you familiar with early Apple and Microsoft products? I mean Basic. 5 we can strike, the interface was text-only. 1 was true at the time Basic was released, and that's why "it's different this time" is not relevant there.
So it was text only. That makes it accessible how, exactly? Can you cite specific examples of supporting technology for this?
1. was true at the time Basic was released, but so what? it has none of the "features" that we're actually talking about, and is less powerful than even javascript version 1. By the time visual basic had our beloved features, 1. was no longer true.
I said we can strike 5. That means I agree with you about 5.
Your argument is "it's different this time" because of reasons 1-7. I'm claiming 1,2,3,6 are not different when compared to Basic, at the time Basic was released.
My argument is incredulity that you'd make such assertions that are baldly false, and don't apply to the actual reality that we live in. "Visual Basic" and "Basic" are not the same technology, and you can't simply merge them to get more points.
1. was true of BASIC for a brief time in the 80's, but was never true of VB
2. Not applicable to Basic (you had to type basic programs in by hand from a book, not exactly instant), not true of VB
3. Not applicable to Basic. What does "plugin" even mean there? You still have to type it in by hand. Not true of VB
5 was true of neither as you've conceded.
6 was true of visual basic, but never true of basic- to the degree that we're talking about sophisticated GUI apps, not simplistic text based adventures or weather quizzes.
Well, I said "Why not VB6?" because I don't know much about it. But I'm pretty sure about Basic. You presented a list of reasons why JS is superior, and many of those were true of Basic at the time it was popular.
2. You can load Basic programs instantaneously. They're interpreted, and the interpreter came with the operating system or even the computer's hardware. How is JS any more instantaneous? You didn't have to type in a whole Basic program every time you wanted to run one - I'm guessing this is the confusion here.
3. There were no plugins. That's all that claim 3 ever was. I don't know how typing in a program by hand is relevant at any rate. Surely every program has to be typed in by hand, unless you're doing visual programming.
6. I thought this was about Basic itself, which did not take a team of 20 engineers four years to develop. As for applications, at the time it was really simple to program in compared to something like C.
So it comes down to 4, 5, 7. These aren't true of Basic, but they don't necessarily make JS a winner:
4. Basic programs were portable to machines that had interpreters, and there were lots of them. But sure, it probably wasn't as portable as JS, as I don't know if you could run it on a mainframe. C is a very portable language though, and always has been, so why does this mean JS wins?
5. Improvements in accessibility compared to the 80's applies to all technology. How is the disability support in JS better than other languages?
7. Home computers were IN YOUR FUCKING HOUSE! at the time Basic was popular. But non-Basic programs ran on those computers too, just like non-JS programs run on your phone. Miniaturization benefits all languages.
This argument is absurd. I can't help but feel that I've been majorly trolled here, so I give up. Have fun writing your next big app in BASIC. I'd love to see how far you get. It sounds like you could go far, since you have one of those fancy new computers with a DISK drive on it.
I never said I thought Basic was a good language (for programming in today). I just said it has (had) many of the same features that you believe make JS a good language. Where Basic doesn't have the features of JS, those features are readily available in other languages, due to technology advances.
I'm not even saying that the features you listed are bad features, nor am I saying that JS is a bad language. I'm simply refuting your primary claim about JS superiority due to some list of features, and about how this is different than all the other times. All popular languages have their place, by definition, and JS is one of them.
For what it's worth, I wasn't trolling, but I was arguing for the sake of it. Since I now get that you're pretty upset, I just wanted to say sorry about that.
> Congrats Javascript--on almost being as good at data-binding and layout as VB6!
That's total garbage. The browser does awesome presentation and layout with the markup you give it and you can control what happens via declarative CSS. VB6 couldn't even make a dialog look nice when you changed the system to Large Fonts.
Silent failure? You must have forgotten `on error goto 0`.
I would. I've been doing web development for a long time, along with many other types of development, and although there are quirks (as there are with anything), you can do nearly anything via web layouts. The flexibility of the system, and things people have accomplished with it, is really amazing when you stand back and look at it as a whole.
I don't mean to offend, but it sounds to me like you've just internalized the limitations of web layout.
For example, look at email clients. The native mail apps on my Mac and iPad can show me all of my inbox in one big list. I can scroll through tens of thousands of messages naturally, easily jump to the bottom or top of the list, etc.
Web pages cannot support this. Yahoo mail attempts to present the messages in one big list, but the experience is pretty bad. The scroll bar looks fake and feels wrong, find doesn't work like you'd expect, the scroll thumb changes size and jumps around as you scroll, scrolling to the bottom is Sisyphean, etc. And Yahoo mail is one of the better webmail clients.
Gmail didn't even try. Instead it refuses to show more than 100 messages at a time, with buttons to paginate.
When I work on web pages, I don't get a feeling of freedom or flexibility. Instead I find myself forced to compromise on the user experience over and over again, just like Google and Yahoo did with their webmail clients.
Your examples don't strike me as limitations of the tools for designing a UI in the web...the limitations you mention are just due to the nature of it being on the web.
Frankly, a list of tens of thousands of messages sounds completely worthless to me. The first email application I've ever really liked and use all the time is Gmail. I think Google helped to redefine what the email interface should be, so much so that other desktop apps sought to imitate many of their features.
I believe that some of the limitations on performance actually force developers to build better interfaces than what you'd get if a desktop application was built in its place. I have to focus on what is most important and determine the best way to deliver that functionality to you. I suppose that's why I find myself anymore using web applications far more than desktop apps. The only native desktop apps I use anymore are things that I have to have the performance for (IDE's, Photoshop, etc...)
In WPF you have a grid layout out of the box. It just works. It takes minutes to setup. In HTML you are forbidden from using table and divs require all sort of third-party crap that doesn't really work with scaling windows and such. Tried using Twitter BootStrap fluid. Had to tweak the thing for days. Still not happy.
Why is it important that it's "in the box". You can have a html page started with a link to foundation and be doing a progressive grid layout in less than a minute. If you don't like their grid implementation use one of a dozen others. I'm guessing you used pre 3.0 twitter bootstrap. The latest bootstrap (I don't know how good it is, I have mainly used Zurb Foundation) is supposed to be much better at supporting progressive grids.
When making Web UIs, I miss the ability to think of screen space in the simplest terms possible: as (a portion of) a Cartesian plane, with the Y axis rotated 180 degrees so that the Y coordinate increases downwards. None of those contrived CSS constructs seems to offer the same degree of simplicity.
People get excited about things happening to Javascript because, if you want to run your code in a browser, there's no alternative. So it's not so much "Javascript", some crappy language, getting that feature; it's all-web-programming getting that feature.
Some people (myself included) prefer a more radical approach: Rather than fixing the inteface JavaScript presents ot the programmer, we replace JavaScript (or, actually, all three of HTML, CSS and JavaScript) with a different language that is actually designed not to be crap. For example: http://elm-lang.org/
Once you get Microsoft, Apple, Google, Mozilla and Linux to all agree to and implement your new language please let us know so we can have you go fix congress.
It is not really my language, I am just a user. And Elm is already implemented using a compiler that translates Elm source code to HTML, CSS and JavaScript.
Does Elm have a progressive enhancement story at all? http://elm-lang.org/ is blank, and at a glance it entombs all content in javascript string literals, making linking and repurposing and any kind of semantic work just about impossible. The attitude that my content has only one useful rendering and I am fully responsible for it, and the client should only be able to execute that precisely, is destroying the web.
I can't speak for prodigal_erik, but I strongly disagree. User agent strings are, to put it mildly, a clusterfuck.
First off, they identify browsers, not features. If a user disables JS, you can't detect that.
Worse, you would need know every UA string out there. This is, of course, impossible when a new browser shows up. And even if it weren't, it's not an elegant way to handle the situation of different browsers having different features. You're either going to have to do a separate code path for every version of every browser you support, or you're going to have to create a dictionary on your server to tell you what features are supported for each UA string, and then essentially do progressive enhancement on the server side. At that point, you're going through an awful lot of effort to do the work on the server instead of the client, with no clear net gain.
But the problem of new browsers is worse still. When existing browser vendors release a new version, they don't want all of the new features they added to be ignored by sites that rely on the UA string. And when someone makes a new browser, they don't want it to have everything disabled on every site it renders. So they go to elaborate lengths to load down the string with as much crazy as possible to trick sites into misidentifying them as existing modern browsers.
The big reason to do server-side browser detection is latency. Each feature you support takes code, and if you ship the code to the client-side, that code takes bytes and slows down the page load. If you do your browser detection on the server side, you can avoid shipping code to the client that won't work on it anyway.
It's usually a poor business trade-off to slow down the several hundred million Chrome, Firefox, and IE users for the sake of a few thousand users on a new browser. Numerous studies (first publicized by Google but replicated several times since) show a direct link between latency and conversions: the slower your webpage is, the fewer people buy from it.
The vast majority of the code you'll be "shipping to the client that won't work on it anyway" will be to old browsers. In almost all cases with modern browsers, the amount of code we're talking about is small enough that it will almost certainly not have a perceptible impact on latency. So you aren't slowing down those hundred million users. You're slowing down the rapidly shrinking minority users with ancient browsers.
If you're not doing server-side browser detection, how do you avoid shipping the code to support old browsers to new browsers?
Pre-IE9, most browser-specific hacks weren't of the form "Old browser X doesn't support new feature Y". They were of the form "IE does things differently." That required shipping a version for IE, and shipping a version for everyone else. If you gate these with feature detection on the client, you need to ship the IE code and the conditionals to gate it to the client.
Post-IE9, most browser-specific hacks are of the form "Emerging web standard X would be very handy but isn't supported in browser Y, so I'm going to emulate it with Javascript." That involves shipping JS to old browsers, not to new browsers.
You could use UA strings to serve the shims and workarounds, I suppose, but you could also use client-side feature detection to do the same thing more reliably. If certain features are missing, you load in the extra code. If not, you don't, and page load time is unaffected, except for the tiny amount of code required to do the feature detection. In either case, what you're doing is more graceful degradation than progressive enhancement.
But the idea of progressive enhancement is not just about supporting everybody's browser so that you will get more conversions in the short term. It's about the long term. Targeting the majority and saying "screw the fringe demographics" is what led to Microsoft having control over web technology years ago, and it's important to our livelihood to prevent that from happening again.
Markdown is an embedded language for content inside Elm, so it is strictly speaking not a single syntax. And Elm provides a better way to specify dynamically evolving content that eliminates the need for a separate language for specifying static styles.
> if you want to run your code in a browser, there's no alternative.
^^^^ YES. Although:
1. there was Java in the browser until recently when the Government said not to use it. Eh, it was dead anyway (in the browser at least- very few new projects using it).
2. there are those things called Flash/Flex/Air/etc. that Jobs killed when Apple wouldn't support them- they still live too all over the place though.
3. HTML 5- it's not just for breakfast anymore.
4. Javascript isn't just there because it is the only thing- morons at Google, etc. helped make faster JS compilers/interpreters. How is another scripting language going to erupt if they keep making the bad one faster. It's like PhP all over. Bastards.
Now back to the post to comment on just one thing:
> Just take 10 minutes and read the documentation! 10 minutes!
I was with it and then I read that and thought, "That's bullshit. Total bullshit." So #1 magic JS MVC framework? AngularJS. AngularJS documentation? Yes it has it... but even though I understand it, when something goes wrong, it is not RTFM, it's TFM: Too Fucking Magic. Batarang doesn't help when things aren't wired correctly, and when it does, it is not written for the beginner. EmberJS? EmberJS has only a community of hardcore Rails devs and Sproutcore people that didn't care it got renamed twice (sproutcore->amber.js->EmberJS) and DHH won't embrace it, so it's is F.U.C.K'd- even one of its big time proponents admitted it would be years before it is ready:
Are you saying that VB6 as a platform is superior to the web in its current state, all things considered? The comparison is silly, there is no competition in terms of distribution, portability, flexibility. Can you not see how it is remarkable that web development tools can rival desktop GUI environments, given that by design, everything on the web is running in a very limited sandbox, one based largely on the work of slow-moving standards bodies?
Yeah, you're right, that is cool and that is remarkable. But Javascript still really sucks sometimes.
To use an analogy: I'm not saying the plane doesn't fly, but I am saying the plane seats are uncomfortable.
Also, this is a total aside: what if there actually was a way to stuff like C++ on a computer in sandboxed environment that could be loaded automatically by a user in a seamless way? If that happened, if you took away Javascripts monopoly of the highly portable and convenient environment, it'd be dropped so fast you could blink and miss it.
> Also, this is a total aside: what if there actually was a way to stuff like C++ on a computer in sandboxed environment that could be loaded automatically by a user in a seamless way? If that happened, if you took away Javascripts monopoly of the highly portable and convenient environment, it'd be dropped so fast you could blink and miss it.
This is what asm.js enables for non-garbage-collected languages, and what Binary Data enables for garbage-collected languages.
But I think you're overestimating how much people want to move away from JavaScript. The overwhelming majority of Web pages never leave the JavaScript interpreter in Firefox, because they just aren't bound on JS execution speed. What is far more important than raw JS speed on most Web pages is ease of development and DOM/CSS performance. I think it'd be hard for C++ to gain much mindshare on the long tail of Web sites, even in a world where asm.js was universal, easy to use, and 100% of native speed.
JS has plenty of faults, but one thing it's never lacked is convenience. Conversely, C++ has many virtues, but one thing it's never had is ease of use. Given that calculus, I expect JS to continue to dominate for a long time.
> JS has plenty of faults, but one thing it's never lacked is convenience. Conversely, C++ has many virtues, but one thing it's never had is ease of use.
That is a weird thing to say. Maybe it is just me, but when I use JavaScript, I cannot stop worrying about the possibility that there is yet another corner case I have not contemplated. Admittely, C++ is full of corner cases too; but, in my experience, it can be coerced into being a more or less civilized language by making a list of strictly verboten constructs, including, but not limited to, void pointers, manual resource ownership management and casts other than static_cast. When you leave these out, you actually have a smaller language that is easier to reason about. With JavaScript, no list of bad constructs can do - you need to actively rely on the semantically crazy stuff to do anything useful.
What semantically crazy stuff do you have to rely on? I don't advocate mindlessly buying into the cult of Crockford, but he outlines a pretty reasonable subset of the language in "JavaScript: The Good Parts"
The only thing I can think of that you might mean is function scoping, which I would agree with.
Which is awesome to actually use, but it doesn't have the interoperability that Javascript does. Maybe one day it will, and that'll be awesome. But till then, we'll never know.
Even today, web apps do not rival the desktop apps of a decade or two ago. Yes, there has been some advancement, but web apps are still inferior in every respect.
The performance of web apps is much worse than that of desktop apps, for example. Complex desktop apps written in C, VB, and PowerBuilder ran just fine on 486 or early Pentium systems that have a very small fraction of the processing power and resources of a modern system. Yet it's still common to see web apps in general perform quite poorly on these modern systems, while doing less than the mid-1990s apps did.
Developers at least have some choices when it comes to desktop apps. They can use a multitude of different languages, along with a variety of different libraries and frameworks. This is a much richer ecosystem than what we get with web development today, where you're basically stuck with JavaScript, or a language that's nothing more than a slight veneer over JavaScript (CoffeeScript, TypeScript, and even Dart). Don't even bother mentioning asm.js or Emscripten. Asm.js is merely a rancid subset of JavaScript, and Emscripten is experimental at best.
The portability argument isn't even valid. Languages like C, C++ and Python offer superb portability today, especially if used with one of the extremely cross-platform GUI toolkits available for making desktop apps. Given that almost every major JavaScript implementation today is written in C and/or C++, the portability of JavaScript is inherently no better than than of C and C++.
The ability to communicate over a network isn't anything special, either. All sorts of desktop apps have been doing this for several decades now.
The distribution argument also isn't valid. The package management systems offered by most Linux distributions, for example, are far nicer to work with. They make it trivial to find and install native apps, and unlike web apps, you get to choose if and when you upgrade, rather than having changes forced upon you time and time again.
The sandbox argument is also irrelevant. Various mainframe and UNIX-like OSes have offered several different ways of jailing or otherwise isolating processes for many, many years now. It's nothing new. But unlike the browser, they give real control over how much access is allowed, and without imposing horrid performance loss.
All of these limitations of web apps come together to make for a user experience that isn't enjoyable.
At best, web apps can imitate desktop apps, usually at a quality and user experience level 10 to 15 years behind desktop apps. It's objectively incorrect to claim that web apps "rival" desktop apps, when all of the evidence shows that they clearly do not.
Parent specifically stated that modern frontend development tools pale in comparison to VB6. You couldn't write a VB6 program and run it on Mac, Linux, a random smartphone, tablet, eReader, hell, even video game systems like the Sony PSP have had web browsers and been able to load web apps for a while now.
You throw out "the distribution argument also isn't valid" as though firing up a Linux package manager or going to download some binary program on Windows/Mac is at all comparable to simply clicking a URL in an email. Not to mention the security implications of desktop distribution.
No, the mediums are not comparable. Your rebuttals consist of "your argument isn't valid" but offer no counterpoints, rather, they simply describe the way desktop development is done these days. It's fine and dandy that you think desktop programming is the state of the art, but there are vast differences between web and desktop environments, and it's why things like the Chromebook can exist.
There are many people these days for whom the internet is the computer.
Lets say we've reached this plateau where we can run these moderately limited apps almost everywhere, in a browser. Great! We've been here for some time now though, since HTTP/HTML has always run anywhere a browser could be found... All you're saying is that we have browsers in more places now. That is pretty fantastic, no kidding. There's still nothing wrong with saying that the foundation it all runs on mostly sucks for building application front ends.
What's wrong with wanting better? How awesome would it be to have a safe, well engineered browser that wasn't limited to just HTTP, HTML, CSS and Javascript?
Give me a full duplex network stack, native graphics and broader input controls. Give me file access and a multi-language runtime! Sandbox it all, I don't care!! Microsoft has done all of this (exceedingly well, in a very short time) with Silverlight which can run dynamically downloaded C#, F#, VB and Python modules on Windows, OS X and (limitedly) on Linux. It could definitely be done better by a more open group.
Now Silverlight was _actually_ innovative and modern. As opposed to 20-ish year old broken script and mark-up languages that have to be backwards-compatible.
If "web apps are still inferior in every respect," why do we find ourselves using web apps more and more and desktop apps less and less? Should I expect to download the next gen of great applications from a cool shareware site like in the good old days of a decade or two ago?
Web apps have won the desktop, at least for now. It's what people want, and it's what people are getting, mostly for the reasons cited above. Mobile, now that's a more interesting story.
> why do we find ourselves using web apps more and more and desktop apps less and less?
Do we?
> Web apps have won the desktop
Tell that to my text editor, photoshop or audio editor. Or my email client - or even the native Evernote application. For all of these there's no serious web version.
This comment might sound snarky but I'm honestly trying to think of what web apps I regularly use. And I can't come up with one.
I have yet to see any widely used Web development tool that facilitates local reasoning: looking at a piece of code and knowing what it can or cannot do, without having to look at the rest of the program/page/stylesheet/whatever.
And Angular directives are pretty self contained, with their own scope, template, functions, etc. You need angular.js obviously, but that's just the generic library.
The problem with silent failures is that they are a bad default. Sometimes, the best default is providing no default at all: just throw an exception that must be handled by the programmer. If you want to recover the silently failing behavior, you can always provide a wrapper function that catches the exception and handles it by doing nothing at all. (Admittedly, this is not so easy in nonfunctional languages like JavaScript that make it painful to program with combinators.)
The reason Angular has silent failure by default is because failure is designed to happen all the time - this means angular expressions can deal with data that hasn't arrived/hasn't been created yet.
This might sound like a bad thing, but it actually makes the page work without confusing the expression syntax with endless or statements.
That said, I do see your point - it's frustrating to find something not working due to a typo in an expression, with no errors to point it out. A halfway solution could be some kind of debug directive/tag that logs when an expression doesn't evaluate? Or perhaps something integrated into Angular Batarang? (https://chrome.google.com/webstore/detail/angularjs-batarang...)
VB6 had structs - they were called user-defined types. VB6 does not autodeclare global variables when you forget to type "var". And, if you use Option Explicit and avoid Variants and Objects, you can have some limited degree of type safety.
VB6 is by no means a good language, but JavaScript is much, much, much worse.
> VB6 does not autodeclare global variables when you forget to type "var".
Nor does JavaScript... "use strict";
Being what it is, JavaScript has come on a long way. Saying "avoid this specific feature" does make a language better. The same can be said about specific features of JavaScript (with, eval) but I'm sure you wouldn't make the same argument.
The fact seems to be that people are stuck in their ways and hate on JavaScript because they don't know the language as well they could and they haven't kept up to date with the evolving standards.
People who "hate on JavaScript" tend to know the language very well. They also know at least several other languages very well. This knowledge makes JavaScript's many flaws much more obvious, and much less justifiable.
The basic fact is that prototype-based OO, for example, is much less practical than class-based OO. Experienced developers comprehend JavaScript's attempt at it just fine. This understanding doesn't change its inferiority, however. This is exactly why so many developers need to compensate for JavaScript's lack of desired functionality in this area by trying to fake class-based OO using the limited functionality that JavaScript does offer.
The same goes for many other aspects of JavaScript. Bad tools are still bad, even in the hands of experts.
I'm not really sure what you're talking about when you mention "evolving standards". If anything, JavaScript's standards haven't evolved well at all. Harmony is only now proposing the addition of core functionality that has been present in other languages for decades now, and should have been in JavaScript from the very beginning, too. JavaScript is merely "evolving" to where it should have been many years ago.
To be honest, I am not so convinced about classes as units of program organization either. Classes conflate in a single mechanism several concepts:
1. Types (classes)
2. Encapsulation (private, protected)
3. Polymorphism (virtuals)
4. Code reuse (inheritance)
While it is much better than prototypal inheritance, it is still less than ideal. On the other hand, there are languages like Haskell and ML which compartmentalize better these concepts:
1. Types: algebraic data types and type synonyms
2. Encapsulation: modules
3. Polymorphism: type constructors (parametric), type classes (ad-hoc, Haskell only)
The result of providing these features independently from one another is a net increase in flexibility. You can have, say, a module that exports two or more types, and a single function inside that module that can manipulate the internals of both types.
===
Edit: And Rust gets this right as well, of course!
1. Types: structs and enums
2. Encapsulation: modules and crates
3. Polymorphism: generics (parametric) and traits (ad-hoc)
4. Code reuse: trait inheritance and trait instances for generic types
I'm extremely confused by this post. You claim to know JavaScript very well, which is fine, but then you go on to say that developers "fake class-based OO using the limited functionality that JavaScript does offer." That doesn't square with the fact that prototypal OO is strictly more expressive than class-based OO. You can implement class-based OO in a prototypal OO language. You cannot do the converse.
A lot of people who know JavaScript and several other languages very well don't hate on JavaScript. JavaScript has more than it's share of warts, obviously. We all know the story: it was written in a week, etc. It also has more than it's share of good parts, though, and if used correctly it is a very expressive language. In my experience, the haters are more frequently people who don't know the language as well. Clearly our experiences differ. I find it hard to believe, though, that anyone experienced in both languages would claim that JavaScript was worse than PHP, and PHP is still the most common back-end web language.
> That doesn't square with the fact that prototypal OO is strictly more expressive than class-based OO. You can implement class-based OO in a prototypal OO language. You cannot do the converse.
Actually, you can implement prototypal OO in a class-based language. First of all, you need a single class with two members variables and a member function. The member variables are a pointer or reference to a base object, and a hashmap from strings (member names) to objects (member values). In C++, this would be a std::unordered_map<std::string, boost::any>. The member function is an overload of the subscript operator (operator []) that takes a string argument and checks whether the hashmap contains the string as a key. If string is indeed a key, then its associated value is returned. Otherwise, the same subscript operator is evaluated for the base object and the same string. If there is no base object, then either an exception is thrown or a special undefined value is returned.
The feasibility of doing this is no big surprise. After all, dynamically typed languages are a very, very restricted subset of statically typed languages: http://existentialtype.wordpress.com/2011/03/19/dynamic-lang... . The main reason why users of class-based languages do not do this is that this breaks type safety for very little gain.
Actually, the supposed encoding of class-based OO in a prototypal language is not correct from an operational semantics point of view. In a statically typed OO language, methods and member variables must be known to exist, so they are directly used. The prototypal "encoding" fundamentally relies on testing at runtime whether methods or member variables exist, because it uses the mechanism described two paragraphs above. So it actually does something different than what statically typed class-based OO languages do.
> It also has more than it's share of good parts, though, and if used correctly it is a very expressive language.
For me, an expressive language is not a language that lets me encode hacks (after all, even C can do that), but a language that lets me encode mechanically checkable assurances that my code will work in specific ways. This allows other programmers to reuse my code with full confidence that it will work in the way they expect it to.
That's a pretty good try, but that does not implement the full flexibility of prototypal OO. Also, note that I wasn't talking about statically-typed class-based OO specifically. Classical OO exists in plenty of dynamic languages too, so your comments about type systems are kind of out of place. I prefer static typing too (as long as it comes with inference and polymorphism), but that's orthogonal to the discussion at hand.
> That's a pretty good try, but that does not implement the full flexibility of prototypal OO.
Are you talking about JavaScript's "this" keyword? I did not mention it in my preceding comment, because that is an implementation detail of JavaScript functions. I think my point still stands that (static) class-based OO languages are sufficiently powerful to encode the semantics of prototypal inheritance.
> Also, note that I wasn't talking about statically-typed class-based OO specifically. Classical OO exists in plenty of dynamic languages too, so your comments about type systems are kind of out of place.
You have a point there. When they say "classes", I usually think C++ classes or Eiffel classes, but you are right that there are dynamic languages that uses classes, too.
> that is an implementation detail of JavaScript functions.
Oh? So in an example where B has a method m, and A inherits from B, how is it that `this` refers to something different when calling B.m() than when calling A.m()? They're the exact same function.
That said, I do need to clarify. I was talking about implementing classical inheritance with prototypal inheritance, and implementing prototypal inheritance with classical inheritance. You can implement either using base language features if you want to create a new object system, but that's not what I was referring to.
> Oh? So in an example where B has a method m, and A inherits from B, how is it that `this` refers to something different when calling B.m() than when calling A.m()? They're the exact same function.
Just like in regular class-based OO languages, "this" is an implicit argument of every method that refers to the object on which the method was invoked.
You can even avoid manually doing all the "this" juggling yourself: Make a delegate class, which holds a reference to a method (including its captured variables) and a reference to the "this" object. When a method is retrieved from a an object, actually construct a delegate referencing both the method and the object. (If the method is retrieved after traversing the inheritance chain "upwards", fix the "this" reference along the way "downwards".) Finally, when a delegate is assigned to a variable or as a member of another object, get rid of the "this" reference and assign the method only instead. Client code never gets to see the "this" juggling.
Oh I know how to implement it, I was just responding to your claim that it was "an implementation detail of JavaScript functions." It's an implementation detail of method calls, the function itself is completely this-agnostic. I guess I was just being pedantic ;)
Obviously not. I do, of course, disagree with your reduction of prototypal OO to "looking up missing keys in another map".
That said, I do need to clarify. I was talking about implementing classical inheritance with prototypal inheritance, and implementing prototypal inheritance with classical inheritance. You can implement either using base language features if you want to create a new object system, but that's not what I was referring to.
Well, it would help my understanding if you could elaborate on your disagreement rather than just saying that you disagree.
The additional constraint of not creating a new object system prevents me from making OO of any kind at all in C, but leaves most scripting languages that implement "classical inheritance" very open to implementing "prototypal inheritance". This is partly because they actually use "prototypal inheritance" and expose a "classical interface" as the primary one, so fiddling with __mro__ feels a little like cheating. If I want to avoid fiddling with the existing __mro__ and build my own, I can override __getattribute__. This certainly doesn't feel like making a new object system to me, but it also doesn't feel substantially different from overriding [] in C++.
To be honest, I have no idea how to implement the exact operational semantics of prototypal inheritance in a dynamic language with classes. (Perhaps it is possible, but I would not bet on it.) In JavaScript, objects are statically known to be internally a pair of a base reference and a hashmap. In Python, you can define a tuple or class that has a base reference and a hashmap as members, but internally your program will test for the existence of these members all the time. So, different semantics.
But a static OO language can faithfully reproduce the operational semantics of prototypal inheritance.
The difference between "checking for the existence of the proto key in a hash map" and "checking whether the proto pointer that I am certain to have points to NULL" is due entirely to the differences in the semantics of Python and C++. Is it important just to implement prototypes, or to ensure that the guts of the prototype system are the same as the guts of a particular JS implementation? I'm not sure precisely where the goalposts have gone, so here are some prototypes in Python. http://pastie.org/8263966
Edit: Now with method binding that works instead of not working!
Congrats Javascript--on almost being as good at data-binding and layout as VB6! Me, I'm going to keep kvetching about javascript frameworks until flexbox is widely supported, the strongly-typed language flavor-of-the week actually is stable, and frameworks like angular don't embrace silent failure modes as a feature.