CRUD JavaScript

[Quin]

There was a time when I would have said that I hated JavaScript.
There were two primary reaons for this. One it was impossible to
debug... enter Firebug and problem #1 mitigated. The second thing I
hated about JavaScript really has nothing to do with the language
itself. It is really a critique on HTML and web development. That
is, there is so much boilerplate JavaScript required to do basic HTML
stuff that should really be declaratively defined rather than
programmatically (DOM manipulation, event handling, Ajax, widgets).
This reminds me of the repetitive code required when building CRUD
(create,read,update,delete) applications. It creates unnecessary
JavaScript bloat.

It turns out, I didn't really hate JavaScript itself at all... I just
hated some of the peripheral issues I experienced when using it. I'm
happy to say I'm a reformed JS hater ;)

[Chris Brown]

Too true, almost everything I dislike about developing with JavaScript
is nothing to do with the language and everything to do with the
environment, i.e. the web browser and one family of browsers
especially.
Very sad news yesterday that the ECMA4 camp (Adobe, Google, Mozilla)
has backed down and reconciled with axis of evil (Microsoft + Douglas
'I always complain that it's broken but do not want to fix it'
Crockford). The ECMA4 looked like it could really turn a corner for
JavaScript with the kind of functionality that could really take
JavaScript from the client to the server (packages, namespaces,
classes, private vars etc etc).

[Justin Bozonier]

I actually like the fact that they're taking it down a different path. I am very happy with javascript as it is and the addition of forcing everything into packages and namespaces, and classes, etc. It was unnecessary cruft.

I think that they could add just a couple of the things they had and call it a day. Optional strong typing would be nice as well as optional classes and namespaces. Threading would have been a huge win as well.

I didn't like how it was starting to look like Java.

[Chris Brown]

As I understood it all of it was optional and you could carry one
using JavaScript just the way you have been if you so wished. I think
a lot of the example code that was coming were a little contrived,
trying to show every new piece of syntactical sugar in a few lines of
code which made it start to look a bit 'busy'. The biggest thing for
me was that the language was clearly being lined up to make a break
out of the confines of the browser, if there was a none browser based
implementation it would gain a community and a life of its own, which
would stop the current situation where a small handful of powerful
'special interest' groups get to sit behind often closed doors and
decide the future of the web with their own 'unique' interpretations
of the standard. When it was announced which parts were being taken
off the table for good, it were the parts which would make it a
potentially attractive language to use outside of a web browser.

Let's pretend EMCA4 had of made it and a non-browser implementation
followed shortly after, I and many other people I think would use it
for both their client and server code. Most web developers work on
both client and server code, and lately as the clients are getting
fatter and the servers are getting thinner the balance can now be a
50/50 split or more even, I for one get a bit tired of having to
constantly flick between two languages on a day by day basis, and I
also work with dynamic languages on the server, I see from my
colleagues who work with .Net that it's even more of a pain as the
shift in thinking is that much greater and as a result I see lots of
value objects with loads of getter/setters and other static style code
creeping into our JavaScript code base.

Microsoft is not going to change its stripes, they are in my opinion
deluded and actually believe SL has a shot, they are going to do
everything they can to drag their feet in order to slow down EMCA3.1
and HTML5 while SL gains traction. They will pay just enough lip
service to make the other key player believe they are half serious
about standards cooperation, then we'll see the next n-versions of IE
still shipping with the same broken version of JScript and no doubt
some 'unique' interpretation of the HTML5 API's.

On Aug 15, 10:16 am, "Justin Bozonier" <darkxant...@gmail.com> wrote:
> I actually like the fact that they're taking it down a different path. I am
> very happy with javascript as it is and the addition of forcing everything
> into packages and namespaces, and classes, etc. It was unnecessary cruft.
> I think that they could add just a couple of the things they had and call it
> a day. Optional strong typing would be nice as well as optional classes and
> namespaces. Threading would have been a huge win as well.
>
> I didn't like how it was starting to look like Java.
>

[Quin]

Interesting comment about how web developers are forced to be both
client-side developers and server-side developers. This has certainly
been the case for a long time. But I do think that some of the
JavaScript frameworks out there are starting to change this.
Especially those which make the effort to truly <a href="http://
www.appcelerant.com/lipstick-on-cgi.html">decouple the client from the
server</a>. My clients are actually looking for people with just
HTML, CSS, and JavaScript skills and leaving the Java,Ruby,C# stuff to
another set of serverside developers. Not a bad thing in my mind.

[Quin]

apparently hyperlinking in posts isn't enabled :(