Hacker News new | past | comments | ask | show | jobs | submit login

JavaScript is an awful language, no matter how much some people stress that you can build working things if you are just careful enough and all that. But that is only the beginning, the entire stack is more less broken. HTML and CSS got repurposed from document markup languages to GUI markup languages. We allowed this awful language to escape the browser and infiltrate our servers in form of Node.js. Microsoft also came up with the clever idea to develop desktop applications and apps with JavaScript, HTML and CSS.

And even the largest selling point of the entire stack - develop once, run everywhere - is far less true then many like to admit. In the past a substantial part of development time has been spent on getting the thing to run consistently across browsers but I fear we are far from the end of the road. Now we have more or less consistent behavior across browser for all the basic things but you still regularly run into unusable web application because you happen to have an unexpected screen aspect ratio, an unsupported video codec or missing WebGL support.

Unfortunately I have no good suggestion how to escape from that situation (quickly) but it seems pretty obvious to me that we have a lot of problems to solve.




> And even the largest selling point of the entire stack - develop once, run everywhere - is far less true then many like to admit.

But it's more true than any platform in the history of mankind.

I've noticed a resounding chorus of seasoned developers railing against the web as application platform for over a decade now. But their complaints are always comparing an open standards based platform against some proprietary platform or GUI toolkit. Of course Microsoft or Apple are going to put together a more cohesive app SDK than the W3C. But neither of those behemoths has ever approached the ubiquity of the web, not by a long shot, because every single platform they target has to be developed by them. The web is available everywhere, and if a new corporate behemoth builds the next great platform, they must include web support because that is now considered baseline functionality. I'm surprised more old-school developers don't recognize what an amazing accomplishment this is.

So yeah, JavaScript is terrible, but it's standing on the most ubiquitous platform ever created. And you can't build that platform by thinking to yourself, "what would the ultimate cross-platform application platform look like?" It doesn't work that way. The web won because of it's braindead simplicity, that was the thin edge of the wedge. You see being document-based as a weakness, but that's its strength, because documents have a higher utility-to-complexity ratio than apps. Even today when all us software elites are thinking about javascript-based apps, the web is still dominated by a massive substrate of documents, and many apps exist only to manipulate documents, so being document-based and allowing anyone to edit documents was the killer feature of the web. How many network application protocols/platforms/toolkits have been invented since the birth of the internet? Certainly a lot more than anyone will ever be aware of because they didn't have the means to gain traction.

Systems on the scale of the web don't—can't—happen by design. Instead of complaining how terrible it is we need to look at what incremental improvements are possible. Over time this leads to real evolution, and yeah it's slower than we'd like, but there's no other way forward without chucking out all the users with the bathwater and becoming irrelevant.


Agreed about the utility of documents. But that's not the issue. The issue is contorting a document to make it into an application. Mobile app devs don't have to deal with this and the benefits are many. Let documents be documents and apps be apps. I'd like to see a webgl based app toolkit that works like a mobile app toolkit and performs as well as a mobile app. I don't think it will happen though because so many devs have now been raised on html, css and js. They like it.


Unfortunately I have to leave, but I agree with most of your comment. I just believe we should not give up because it seems very hard to come up with and get adoption for a better solution. Continuously patching and bending two decades old technology for another decade or two does not seem a sustainable solution to me. Not that old technology is necessarily bad, SQL is a great counterexample, but unfortunately not everything out there got created with so much thought put into it.


> Unfortunately I have no good suggestion how to escape from that situation (quickly)

Java apps! ducks But seriously folks, I'm curious what went wrong there. The JVM these days is very fast, runs everywhere and comes installed by default on most operating systems. I was still a student during the java hayday, but the only downsides I vaguely recall were poor UI, poor security and poor speed. The last two have been fixed and the first one seems very fixable. Furthermore, you don't have to write apps in java anymore. It just seems like there's a lot of untapped potential there these days.


One issue I had with Java was the aesthetics of UI elements.

Inheriting the DOM, especially its graphical elements was a boon to JS apps.

Technically Java can/could do all the same stuff, but in the DOM, input, output, graphics and text all flow together. They're too rigidly separated in Java layouts.

While I'm at it, upgrading the Java runtime was always an annoying process, taking time, confusing my sister, etc.


I'd argue that the world has moved on from desktop apps. Maybe that's reversible, but I'm not convinced.


Wow, I have rarely encountered a more ludditic comment on HN. The number of bare assertions alone is bemusing.


You might want to lookup the definition of the word ludditic. But I totally agree with the parent comment. JS and friends are too high level to be whipped into shape but too low level to be productive.


adj. of, related to, or characteristic of a Luddite.

Luddite: one who protests against modern labor-saving technology.


Right, so how is criticizing JS ludditic in any sense?


Feel free to point out where I am wrong.


Okay.

> JavaScript is an awful language

This is a bare assertion. The same thing can be (has been) said about every programming language, ever.

> the entire stack is more less broken.

This is another bare assertion.

> HTML and CSS got repurposed from document markup languages to GUI markup languages.

This is a red herring. There is nothing intrinsically wrong with the evolution of markup to encompass more layout capabilities.

> We allowed this awful language to escape the browser and infiltrate our servers in form of Node.js.

Another red herring. Node.js exists. Nobody is forcing you to use it. It's being used successfully by quite a few folks. Furthermore, it was Netscape (the originators of the language) who originally introduced server-side JavaScript. SSJS has been around in various forms almost ever since there was JS.

> Microsoft also came up with the clever idea to develop desktop applications and apps with JavaScript, HTML and CSS.

They were certainly not the first. The trend started, I believe, with Mozilla's XUL architecture, evolved through things like Lazslo, and is steadily moving towards web components. This trend has been going on for a decade; even in enterprise Java land things like Struts and JSF got on the application markup bandwagon. Quite simply, markup has proven to be a good way to lay out interfaces.

> develop once, run everywhere - is far less true then many like to admit.

There are inconsistencies, true, but there is really no other stack that has achieved as much cross compatibility as the web stack.

> In the past a substantial part of development time has been spent on getting the thing to run consistently across browsers but I fear we are far from the end of the road.

This is somewhat of a "slippery slope" fallacy: 'There were problems in the past, so I fear there will be problems in the future, therefore we shouldn't solve the problems and the whole thing is crap...'. It doesn't hold together.

> Now we have more or less consistent behavior across browser for all the basic things

Which is incredibly powerful and frankly unprecedented.

> but you still regularly run into unusable web application because you happen to have an unexpected screen aspect ratio, an unsupported video codec or missing WebGL support.

Very rarely. For experimental new apps yes. But when you look at what projects like Clara.io have accomplished, they have blown away the preconceptions that the web is not suitable for things like high-end 3D graphics development.

> Unfortunately I have no good suggestion how to escape from that situation (quickly) but it seems pretty obvious to me that we have a lot of problems to solve.

Let me make a suggestion then. Contribute to solving the remaining problems instead of berating the technology, or if you manage to find a better alternative, write about that instead.


"There are 2 types of programming languages, those everyone complains about and those nobody uses..."


> JavaScript is an awful language

This is a bare assertion. The same thing can be (has been) said about every programming language, ever.

This is just not true. You can always find someone not liking a language but if you asked people that have used many different languages they can of course rank them from worst to best. And although I am not ad hoc aware of any study demonstrating this I also never met any developer seriously suggesting that JavaScript would rank on top of that list.

> the entire stack is more less broken.

This is another bare assertion.

This is obviously my opinion and I assume everybody is able to mentally add IMO somewhere.

> HTML and CSS got repurposed from document markup languages to GUI markup languages.

This is a red herring. There is nothing intrinsically wrong with the evolution of markup to encompass more layout capabilities.

If table based layouts or hundreds of wrapper DIVs are not a sign that the underlying technology is not suitable for the task then I don't know what is.

> We allowed this awful language to escape the browser and infiltrate our servers in form of Node.js.

Another red herring. Node.js exists. Nobody is forcing you to use it. It's being used successfully by quite a few folks.

That somebody uses it successfully does not make it a wise decision to use one of the worser languages in a place where you are - unlike in a browsers - not forced to do it. And don't get me wrong, everybody is free to use whatever they like, I just want to point out that there are better options. You can use a screwdriver to drive a nail into a board, I won't stop you, I just want to suggest to at least consider getting a hammer.

> Microsoft also came up with the clever idea to develop desktop applications and apps with JavaScript, HTML and CSS.

The were certainly not the first. The trend started, I believe, with Mozilla's XUL architecture, evolved through things like Lazslo, and is steadily moving towards web components. This trend has been going on for a decade; even in enterprise Java land things like Struts and JSF got on the application markup bandwagon. Quite simply, markup has proven to be a good way to lay out interfaces.

I completely agree that using a markup language is a good way to build GUIs, the bad idea is using HTML and CSS for that because they were not intended for this and are not really up to the task.

> develop once, run everywhere - is far less true then many like to admit.

There are inconsistencies, true, but there is really no other stack that has achieved as much cross compatibility as the web stack.

I completely agree with that, but this should really not imply we should stick with JavaScript, HTML and CSS. We can do way better and we should do so.

> In the past a substantial part of development time has been spent on getting the thing to run consistently across browsers but I fear we are far from the end of the road.

This is somewhat of a "slipper slope" fallacy. There were problems in the past, so I fear there will be problems in the future, therefore we shouldn't solve the problems and the whole thing is crap.

No, we should of course fix the problems, but I believe we should at least think about fixing them at the fundamental level instead of keeping patching the holes. The obvious problem is of course the adoption of a better replacement and that is why I am not sure if and how this could happen.

> Now we have more or less consistent behavior across browser for all the basic things

Which is incredibly powerful and frankly unprecedented.

> but you still regularly run into unusable web application because you happen to have an unexpected screen aspect ratio, an unsupported video codec or missing WebGL support.

Very rarely. For experimental new apps yes. But when you look at what projects like Clara.io have accomplished, they have blown away the preconceptions that the web is not suitable for things like high-end 3D graphics development.

My point here is that people quite often try to suggest that portability is kind of a unique feature and essentially for free with the web stack which is not true. A simple program is really easy to write in a cross-platform manner in most languages. Then there is a range of applications where the web stack is exceptionally good for building cross-platform applications with very little overhead. At the upper end it again becomes hard and costs effort to get it working across platforms.

> Unfortunately I have no good suggestion how to escape from that situation (quickly) but it seems pretty obvious to me that we have a lot of problems to solve.

Let me make a suggestion then. Contribute to solving the remaining problems instead of berating the technology, or if you manage to find a better alternative, write about that instead.

As another commenter pointed out, we know how to build better solutions. What we don't really know is how to get adoption for it.


>This is just not true. You can always find someone not liking a language but if you asked people that have used many different languages they can of course rank them from worst to best. And although I am not ad hoc aware of any study demonstrating this I also never met any developer seriously suggesting that JavaScript would rank on top of that list.

So because it's not number one it's an "awful language"? That doesn't make any sense and I know plenty of people who enjoy working with javascript. In fact the few people I do know who hate JS are people who haven't done more than copy/paste code from stackoverflow.


If few people hate programming in Javascript then explain this to me:

https://github.com/jashkenas/coffeescript/wiki/list-of-langu...


Firstly, just because someone makes a compile-to-js language doesn't mean they ncesserily "hate" JS ... I mean, it may, but it could also very well mean that they prefer their own language instead of JS, but not hate JS per say.

Also, compare this to the number of people who are just using JS normally worldwide, then we'll have perspective of just how many more people are just fine with JS Vs the people who feel the need to make these.

My guess would be that the number of people who like JS and use just normal JS in their projects is far far greater in number than the people who use compile-to-js solutions. So in comparision to the former, the latter group could be called as 'few'.


You can not count people only knowing JavaScript because most of them are probably not even aware how bad JavaScript is because they never used anything else.


Ok.

> largest selling point of the entire stack - develop once, run everywhere

Rather than being the largest selling point, this is talked about by virtually nobody who actually works with Node.

Easy handling of concurrent I/O is the largest selling point.

See http://nodejs.org/ : "Node.js® is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices."


Develop once, run everywhere was obviously not meant to be applied to backend code but to the client part. But besides that asynchronous IO is (usually) an OS-level feature and there is really no need to surface these features with JavaScript, many other languages could and can do this as well.


"I have no good suggestion how to escape from that situation"

Everyone knows what the solution is; a sandboxable arch-independent batteries-included bytecode format for the web. The solution is obvious, the problem is in organising the detailed work necessary for such a format to emerge.


This is exactly what I meant - the technical solution is not the hard part, gaining widespread adoption is.


No, the technical solution is the hard part. Designing a bytecode format for the web would not be a trivial undertaking.

Assuming this work was completed, widespread adoption is mostly a matter of browser support and time. I suspect the Chrome team would be open to implementing it after it's been designed (there are parallels with the Native Client work), and other browser teams would be unlikely to resist if there are clear performance and workflow benefits (which there undoubtedly would be). Basically it's a "if you build it, they will come" situation.

To understand the scale of the task, consider the 'batteries-included' aspect. The core libraries for the bytecode format should be standardised (i.e. core library API set in stone for each major version of the bytecode). That's a huge amount of work. Then you'd also have the security testing needed (to ensure the bytecode was securely sandboxed). You'd also need to work on ensuring the bytecode was efficiently implemented for all processor architectures. I don't know about you, but I certainly don't feel qualified to do that.


Is "bytecode format for the web" not basically what Java applets were? Seems that adoption is the problem.


Except it wouldn't really be that hard. If Google and Mozilla were on board that would be enough. But neither has any interest it seems.


Yes, that thing was JVM, java.. It too escaped the browser and infiltrated the server..


No, it wasn't. It wasn't sandboxed and the libraries were not restricted enough to ensure a reliable target. Java applets were essentially running on the desktop, not in a website.


Write once, debug everywhere.


I know it's a Java joke, but it applies to everything cross-platform, all the more reason to make the core as uncomplicated as possible.


I strongly agree with "the entire stack is more less broken". Back in 1989 Sir Tim Berners-Lee put a lot of careful thought into the design of a protocol for sharing documents using IP/TCP. However, when Ajax and Web 2.0 got going circa 2004, the emphasis was on offering software over TCP, and for that the HTTP protocol was poorly suited. Rather than carefully rethink the entire stack, and ideally come up with a new stack, the industry invented WebSockets, which was then bolted into the existing system, even relying on HTTP to handle the initial "handshake" before the upgrade. WebSockets undercuts a lot of the original ideas that Sir Tim Berners-Lee put into the design of the Web. In particular, the idea of the URL is undercut when WebSockets are introduced. The old idea was:

1 URL = 1 resource

Right now, in every web browser that exists, there is still a so-called "address bar" into which you can type exactly 1 address. And yet, for a system that uses WebSockets, what would make more sense is a field into which you can type or paste a vector of URLs, since the page will end up binding to potentially many URLs. This is a fundamental change, that takes us to a new system which has not been thought through with nearly the soundness of the original HTTP.

Even worse is the extent to which the whole online industry is still relying on HTML/XML, which are fundamentally about documents. Just to give one example of how awful this is, as soon as you use HTML or XML, you end up with a hierarchical DOM. This makes sense for documents, but not for software. With software you often want either no DOM at all, or you want multiple DOMs. The old model was:

1 URL = 1 resource = 1 DOM

Much of the current madness with Javascript is that developers want to get away from HTTP and HTML and XML and DOMs and the url=page binding, but the stack fights against them every step of the way.

Perhaps the most extreme example of the brokenness are all the many JSON APIs that now exist. If you do an API call against many of these APIs, you get back multiple JSON documents, and yet, if you look at the HTTP headers, the HTTP protocol is under the misguided impression that it just sent you 1 document. At a minimum, it would be useful to have a protocol that was at least aware of how many documents it was sending to you, and had first-class support for counting and sorting and sending and re-sending each of the documents that you are suppose to receive. A protocol designed for software would at least offer as much first-class support for multiple documents as TCP allows for multiple packets. And even that would only be a small step down the road that we need to go.

A new stack, designed for software instead of documents, is needed.


Javascript is definitely a weird language in a lot of ways, particularly given the prototype system, assorted mixed paradigms, and the cultural focus on anonymous function callbacks, but I think it's a bit much to say it's "awful".

Coffeescript in particular makes me feel like Javascript has a Bizarro-world cousin of Ruby hiding under all the C-style syntax.


English is not my first language so awful may not be the word I was looking for. It was intended to mean ugly but not as bad as PHP.


English is my first language, and awful is precisely the word I would use for Javascript. True, not as bad as PHP ('appalling' is appropriate there, I think), but Javascript is not a good language.


Hm, I'm learning JS at a slow pace reading D. Flanagan's 6th edition book. I'm an intermediate level Ruby programmer. The funny thing is that this book is so well written, that makes my understanding of Ruby even better, because I make direct comparisons.

JS and Ruby are similar in a way, the syntax is not all too strange to me so it's easy to run any JS code in my mind, on the fly.

That said I find JS extremely cumbersome compared to Ruby... But if I could easily add JS functionality to my Sinatra/Rails it would be great! :-)


Take a look at Coffeescript (http://coffeescript.org) and you'll see what I mean about there being a Ruby-like language hiding underneath all the cruft.


As engineers, we should recognize very clearly that JavaScript is just another tool that has trade-offs as everything does. We build applications optimized for their use case. Does the bridge over the meandering creek need to be made a suspension bridge of concrete and steel? Of course not!

Time is the true currency of this universe, so we optimize for efficiency as best as we can without knowing the future.


> Does the bridge over the meandering creek need to be made a suspension bridge of concrete and steel

The problem being discussed here is more along the line of building the Golden Gate with wood and plaster.


"Messages" are the currency of the universe: the more and better messages you emit, the more successful you will be. Some messages take no time, some take a great deal of time; message rate and type varies substantially over a human's 30k days of life.


Can I pronounce this "Crockford Syndrome"?


If time is the true currency, then the whole `bower install whatever` approach is basically potential crushing credit card debt.


Yes, exactly. Developing a web application is basically the act of putting square pegs into round holes, over and over...


maybe one solution would be to use another interpreted language, like python, lua, ruby, dart... and make it use the DOM.

I wonder if rust or c might run in a vm, I guess yes. C compilers can be very small too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: