So what is "cool" now? Javascript frameworks
like Angular, Ember, React and Oracle's own JET. These are great, and they have
their place, I'm sure. The argument is that since these frameworks use
the power of the user's browser, they can be more responsive. There is
less communication between the server and the client, which should also speed
things up. They can do exactly what the designer wants them to do - no
component framework getting in the way, wanting to do things its way.
They are open source for the most part, which frees us from Oracle's
tyranny. And working in HTML and CSS can let you use graphic designers
and their toolboxes, like DreamWeaver.
The first problem I have with Javascript frameworks is that
this is a return to code it yourself. The tooling builds some of the code
as sample files, where you take some prebuilt code and tweak it. For the
most part, however, you have to write the HTML, the CSS, the Javascript. Fortunately,
there is some help in the libraries, like JQueryUI, with some precoded
components, and lots of sample code. But I miss JDeveloper's ability to
drag a data control onto a page, say you want to drop it as a bar graph, do a
little configuration, and presto.
Tooling and IDEs
Of course, in some respects, this is a problem with tooling
rather than with the framework. I suppose that if I could point Eclipse
or Netbeans at a REST service and have it generate the code for say, an Angular
2 service module that accesses the service, I might feel differently. Or
if I could generate a first-cut form to do CRUD with that service, I'd feel
better about these frameworks. I also get the feeling that developers
WANT to code it, and hate handing over part of the job to someone else,
especially with something like ADF, where you can't easily see the source code.
The proponents say, "but you can make it look EXACTLY
the way you want." True, but at what cost? Can your users wait
while you do it? But you say "It's Agile, we'll do 80% now and get
it closer to 100% with each iteration." And I reply, "I can
give you 98% in the time it takes you to do 80%, and do the users care if I
can't get to 100%?" If they DO care, guess what, ADF 12.2.1 uses JSF
2.2 (and so do the latest versions of other Faces libraries), and you CAN code in HTML5/CSS/Javascript what you can't do with JSF, yet
still interact with the pure JSF parts. Someday, I'd love to do a contest - who
can meet the user's requirements fastest.
Responsiveness and Speed
Another advantage claimed for these environments is that
most of the processing takes place on the user's computer, and interacts
directly with the browser. Since the
application doesn't have to interact with the server as much, it runs faster. And on the server side, it isn't as
complicated and doesn't require as much server resources. All the server is doing is downloading files
to the client, and running REST services.
What's more, the browser usually caches files that it has already
downloaded, so if the file hasn't changed, it will use its local copy of the
file, and won't go to the server for a fresh copy. Please note that this can be a disadvantage
for mobile devices with slow connections and limited storage. There is a lot more code to be downloaded and
stored.
The honest truth is that in ADF Faces many of the Rich Faces
components are rendered using Oracle JET, so they have all the responsiveness
of this Javascript library, except that I didn't have to code it. Similarly, PrimeFaces renders with JQuery and
JQueryUI. Because PrimeFaces does this,
it can use JQuery tools to create themes.
ADF Faces uses skinning through CSS-like files and the basis for its
skins is in the open source Apache Trinidad Faces library. Of course, this means that JSF frameworks can
be subject to some of the same problems as the Javascript frameworks that they
use for rendering.
Testing and Security
One problem that I have with Javascript frameworks is that
all of the source code is delivered to the user's browser. Javascript is
interpreted code, which means that some bugs won't show themselves until
runtime. Compilers can catch some problems up front, which can speed
development. I should note that Angular 2 & 4 are usually written in
Typescript which compiles to Javascript - a little of the best of both
worlds. But the biggest problem I have with this is the advantage it
gives to hackers. When a hacker can see ALL of the source code, including
code that is intended to keep bad data out of the database, he/she can re-write
it to bypass your safeguards. If you are
going to write REST services for your Javascript framework to use, you need to
make sure that you have server-side protection.
Never accept data from a browser without validating it at the
server. Don't assume that the Javascript
code that you wrote will be executed unchanged.
So there I am – an old developer who found a great way to
develop and doesn't want to give it up.
I'm not against the Javascript frameworks, and if you want to build
applications that way, good for you.
I'll do my best to support you. I
know enough HTML and CSS to be useful, and even some Javascript. As a long-time database advocate, SQL and
PL/SQL expert and developer, I'll write good solid secure REST services for
you. Does that make me obsolete? I don't believe so. I'm not quite ready to leave you without my
help and advice yet.
No comments:
Post a Comment