[skyhook_mockups]

The last slide was interesting: http://brendaneich.github.com/Strange-Loop-2012/#/50

  - First they said JS couldn't be useful for building 'rich internet apps'
  - Then they said it couldn't be fast
  - Then they said it couldn't be fixed
  - Then it couldn't do multicore/GPU
  - Wrong every time
  - My advise: always bet on JS

It turns out that JS might soon be a mature language which can be used to build real apps. That future has arrived (or at least you can see the train).

es6/7+hardware accelerated graphics+ continued broadband adoption and speed increases (gigabit internet) make the 'web as a platform' dream a reality. I'd love to peek at Microsoft's medium term plan to deal with this.

Also: I wonder how long until we see a full replacement for something like eg:3DSMAX with GUI on the client and rendering done in the 'cloud'?

[InclinedPlane]

It's disingenuous to claim that javascript is not a "real" language already. This is like claiming that PHP or VB aren't "real" languages. You may not like it, you may think it's missing crucial, key features, but there is a lot of JS code out there in the wild producing value for businesses and customers and generating billions of dollars in revenue.

Edit: looks like I misread the parent post, my apologies.

[skyhook_mockups]

Looks like I didn't communicate too well. I wholeheartedly agree that JS is a real language. It's my main language and I've written tens of thousands of lines of the stuff. It has it's quirks but I like coding in it. My "JS as a 'real' language" was a tongue-in-cheek go at those who constantly criticise it for being a toy language. I've edited my original comment.

[laughinghan]

I'm honestly surprised he didn't mention Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript. http://www.codinghorror.com/blog/2009/08/all-programming-is-...

The crux of the argument is, "As a software developer, I am happiest writing software that gets used. What's the point of all this craftsmanship if your software ends up locked away in a binary executable, which has to be purchased and licensed and shipped and downloaded and installed and maintained and upgraded? With all those old, traditional barriers between programmers and users, it's a wonder the software industry managed to exist at all. But in the brave new world of web applications, those limitations fall away. There are no boundaries. Software can be everywhere."

[anil_mamede]

But without an ecosystem of frameworks like OSX or .NET, it will be difficult to develop apps with good and consistent experience.

[skyhook_mockups]

Thats another Then... you could add

  - Then they said it didn't have an ecosystem of frameworks like OSX or .NET

the frameworks will come. It's undeniable that the web, and tooling surrounding it is reaching critical mass.

[WayneDB]

Yeah and we'll probably only have to wait another 5 years!

It's funny how .NET languages can have a consistent, predictable and precision framework built up around them and yet somehow we're supposed to believe that JS is better than bytecode.

[grayrest]

Any toolkit that attempts to shoehorn a consistent experience on the web is doomed to failure. People have made efforts, earnest efforts, at solving the problem (dojo, ext, closure, capuccino). None have caught on and at the moment I'm assuming none will.

Bakground paragraph: I've been thinking about the issue since 2004 or so and always assumed that a widget toolkit would develop like it did for desktop environemnts and one or two would eventually win. The launch of mobile app development changed things. The kinds of apps being delivered were outright better than what equivalent web apps were delivering. Not the perf, I assume perf is going to be solved by better hardware and engine improvements, but what the apps accomplish. My conclusion is that every project has a semi-fixed budget of resources and that web developers burn roughly 50% of that budget on building a custom one-off interface solution for every project they work on. The obvious answer is components but component frameworks had not been catching on so the question is why.

The normally cited problem is the composition problem. It's incredibly difficult to achieve component isolation in the DOM and the Web Components effort is attempting to address. I approve the effort but I do not believe it will solve the problem. It's possible(ref yui3) to write components that will cleanly drop into pages that keep their CSS tweaks class based and that restriction isn't unreasonable in an app. Component use happens more frequently in apps but is not the default like it needs to be to escape the one-off tar pit. The issue is social.

The web's roots in documents mean that pretty much everybody wants a custom UI. All existing component libraries, following desktop toolit precedents, come as a packaged markup/CSS/behavior combo. These two requirements are opposed and that opposition is the core problem. I have never used a component library and not had to customize a signfiicant number of components. When doing so, I either have to maintain a private fork of the component or suffer in download/perf as the framework is super heavy and caters to all possibilities. The yui3 (and looks like current dojo) approach of core+plugin composition with auto dependency resolution is the best solution I know of but overriding is still non-trivial. Tweaking the CSS usually means having to build a complete theme and using generated markup is hit and miss.

My current thinking is that Web Components are a start but there needs to be a good solution for selectively overriding a part of the markup and for overriding style. CSS preprocessor features are also required to achieve styling goals efficiently. The rise of Bootstrap might prove me wrong by starting as an incomplete system, getting buy in (multiple themes, adoption for simple uses), and growing to a more complete one but we'll see.