No hint that Internet Explorer 8 will be moving forward.
Man! Does that Silverlight site sure load slowly.
More people browse the w3schools with Internet Explorer 5 than Safari.
The w3schools is biased towards tech readers!
People don't upgrade their browsers...they buy new computers.
Today's computers will satisfy their owners for many years to come.
No viable runtime outside the browser to choose.
Prototype-based inhertance sucks.
The prototype-based inheritance experiment failed.
People don't get it.
Can't change it.
Can wrap it.
Prototype-based inheritance can do some class-ish things.
But can't wrap it and make it do everything.
Using the dot operator binds you to the built-in OOP.
Don't use dot and you can roll your own OOP.
Any OOP pattern is possible.
It's just really ugly
and slower than the built-in OOP
but if the built-in OOP can't do something....
Macros would clean the mess.
Learning about Lisp is a blessing.
And a curse.
Maybe we can rely on macros in the browser by 2020.
How patent are you?
But even Lisp is Not an Acceptable Lisp
- higher-order functions
- lexical closures
- garbage collection
- global variables
- familiar syntax
Better than most.
All this fuss over just the built-in OOP?
No (but it's a big deal.)
- array comprehensions
- destructuring assignments
- block scope
All the features that make code dense.
Browser applications continue to get heavier.
Working on huge source code files sucks.
Serving many small files is slow.
Identifying dependencies between development files necessary.
Want a better development language and tools now.
source code → manglers → served code
- macro expansion
- Template compilation
- Template compilation
If the mangler is complex enough it is usually called a compiler.
Takes very liberated thinking to embrace haXe and Links approach in general.
JSON and template compilation are like the haXe/Links approach.
Develop all in the language you know best.
DRY. Share source code on server and client.
source code → macro expansion → JS2.0 to JS1.8 → JS1.8 to JS1.7 → JS1.7 to JS1.6 → JS1.6 to JS1.5 → obfuscation → minification → file concatenation → gzip compression → served code
Assembly programmers argued against this logic.
A long time ago.
Developing solutions was less costly than the status quo.
I better not have run step 2 manually.
Not even type
People only adopt transparent tools.
That someone else wrote.
Debugging runtime errors in mangled code sucks.
It still might be a good compromise.
Development must be easy.
Deployment must be easy.
There's a difference.
Need a framework to do this.
On the server.
"You've had development tools for years, now why not me?"
Have something to write? Comment on this article.