Elbowing JavaScript out

It's pointless to be a contrarian on JavaScript. It's here to stay, but it does appear there's a big push to be able to write something other than plain JavaScript (that produces JavaScript) to bring more sanity to the development process.

That Microsoft is pushing a superset that produces JavaScript (https://www.typescriptlang.org/) and Google is also behind Dart (https://www.dartlang.org/) that produces JavaScript, should say a lot about JavaScript's stickiness.

I actually find it amazing all the effort that has gone into TypeScript and Dart, which just produces more JavaScript, instead of creating a new language from scratch. It really looks like even Microsoft and Google prefer to deal with JavaScript 'as is' going with language supersets and languages that output more JavaScript than launching a new language.

In a few years JavaScript will most likely be the 'bytecode' of the web, you won't have to use directly, but it will just be there, produced by higher level stuff like TypeScript or Dart that produces JavaScript.

Her name is Amy. It's right there on every paragraph.

more people complaining about a language they don't understand, js should be more like y language is something I've been hearing for years. it's inane and shows a deep lack of understanding of programming languages specifically, and how computers work in general.

I have been writing apps in all js for years now, there are issues with the language as there are with all languages. over all if you spend the time to learn it, don't use pre processors, and stick to the known patterns for js development you will have zero issues with the language.

the bugs I run into nowadays are usually related to parsing incoming data that is not formatted logically for best use in js. it is best to get your js objects as flat as you can on the server side before sending them up to be iterated over in your frontend app.

most of the applications I build are data heavy with charts and such. I routinely get 100ms or better load times on huge amounts of data because if you do it right, JS is really fast and flexible.

my wife is a designer and I've learned that CSS used correctly with js is all you need. if you can't do the graphics with CSS then js is fine, but do all the work on your Dom object before injecting it into the Dom.

read JavaScript the good parts by Douglas Crockford

NOTE: I do a LOT of JS development. Just check my profile.

This is how the vast majority of web apps were built for the vast majority of the life of the internet, and likely probably still are, considering the vast, invisible depths of internal enterprise development. It's not surprising that it can be made to work well. It's what HTTP is built for.

This, minus the CDN - using compression and static file caching headers, only - is how we are handling a major app upgrade (pretty much a rewrite) at work.

Of course, I flip flopped from hating Javascript to really liking it about 10 years ago. Now after having done most of my work in JS (plus Angular 1) the last year, I can't stand working in Java any more. So much blah blah blah to do anything on the server (since Java is mandated). I'll save the Java rant for another day.

Personally, I find that maintaining state about "workflow" in an actual data entry app is MUCH easier in a fat client than trying to preserve state while entire pages bounce back and forth between client and server. Webflows (Spring/JSF)? Therein lies madness...

And it is pretty cool that our server app has simply became a pile of REST services with default client app resources bundled in. We already prototyped an integration with another system a few months ago that demoed very well.