Related
If the framework manages the HTML/ CSS/ javascript, does a programmer still need to know the javascript language? Or is that taken care of in the abstraction of the framework?
I wanted to make a graphical game/ application using the html5 canvas/ webgl/ whatever other libraries are available to do so. Would it be more effective for me to go through a web framework such as django? I'm not really sure what advantages it offers. I think that if I wanted to create a well designed dynamic site in an effective way, I would use a framework. But if I didn't care about appearance, or if I'm just learning, then am I better off just playing with javascript and html5 first?
In my opinion, you could easily use a framework to simplify your development but remember this: With every framework or tool that simplifies development, you lose a bit of control.
Eventually, you will come to the point where you need to understand css/JavaScript, or whatever the underlying technology is, in order to accomplish some task. In that situation you'll be at a point where you need to learn the "hard" stuff.
Even before you get to that point, however, I'd strongly recommend learning the basics of the underlying technology so that you can see what the tools do. There are many reasons for this, but the most important ones are:
As mentioned previously, sooner or later you'll need to anyway.
If you don't know the underlying technology, you'll struggle and waste a lot of time trying to understand why the pages/apps generated by the framework don't behave the way you want them to.
Troubleshooting is harder
It's really easy for a novice developer to pick up a framework and start doing really stupid things with it. Things that can lead to security holes, leaking sensitive data, exposing yourself and customers to risk.
Some frameworks, of course, protect novice developers from things like SQL Injection, etc, but not all. It takes someone who understands what the tools are doing "under the hood" to tell the difference.
Of course, there is a limit to how much you need to know.
As an analogy, it would be foolish to drive a car without taking the time to learn the basics of how it operates, and how to be safe with it. But to drive a car, you don't need to know how to take apart the engine. If you're one of the guys who wants to be able to take apart the engine (and put it back together), great! You'll be one of the experts in at least one area of the automotive field.
The same goes with development. Different people need/want different depths of knowledge...
But for the web, at least knowing the basics of HTML, css, and JavaScript is a must. It's like learning the difference between Diesel and Gasoline before filling up your tank. It's basic knowledge every web developer needs.
A framework is often developed for the purpose of making larger tasks easier by taking several steps and making them user-friendly. In addition to this, you'll often find that they include configuration files and auto-installers to ease the setup of server components (databases, for instance) so that non-technical users have an ease of use.
The largest issue with this, however, is when users run into errors or warnings that they are unable to debug because the basis for the problem can only be acknowledged with (often) small amounts of expertise in the core languages that the framework was based on.
Quite simply put, you may not need to learn Javascript to use your said library, but it is highly suggested that you understand the inner workings so that you may easily debug and solve problems you have in the near future.
Enjoy and good luck!
For web applications I've developed I tend to build up a library of functions, and for some sites I end up encapsulating them all into a single object, so say FooBar and then all the things I end up doing are within that object. My understanding is that this is part-of-the-way to "Enterprise JavaScript" - encapsulating the functionality in ways that are logical, avoid polluting the JavaScript with lots of global variables.
How do I distinguish good coding practice from what's considered "Enterprise JavaScript"?
A simpler way to ask this might be in terms of scale -- as a web application or site grows it will include more JavaScript and organizing it gets harder, and there are patterns for doing this well and they're Enterprise? What are resources for learning about approaches to handling large libraries of functionality.
Or are people just making it up, as in this joke site?
UPDATE: I am not kidding, really, though I wonder if what I'm seeking is more along the lines of Pro JavaScript Design Patterns. Perhaps "Enterprise" encompasses some of this?
Enterprise JavaScript Is:
Ensuring lines are terminated with multiple semicolons so the JavaSript parser Really Knows when a line is ending.
var helloWorld = function (message) {
if (!message) {
message = "Hello World";;;;;;
}
alert(message);;;;;;;;;;;;;;;;;;;
};;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(By bentruyman)
I love the term enterprise javascript and enterprise coding. I doubt that it's a well defined term but it has a strong appeal.
As I have come to understand it; Enterprises deal with a lot of developers working on different aspects of projects. So there is a lot of communication required to make things work. Enterprise coding is a term to describe the techniques used to aid the communication of developers and modules in code but have gone wrong.
As the site shows, it's easy to over do it!
So enterprise coding results in harder to understand code that seems more robust than it needs. Quite ironic as enterprise coding is intended to ease production.
Examples of enterprise code could easily be found in
Generated websites using robust CMS.
Large library APIs (especially proprietary as the source can not be adjusted)
Cross browser/platform projects. With a lot of dynamic corrections.
Old projects that have been maintained by many people.
Writing clean good code is something that will be debated forever. As there is no perfect approach to all problems.
In a way enterprise coding is coining good practice techniques that have gone bad.
An antonym to enterprise coding might be Cowboy Coding
Indeed, there seem to be patterns and best practices when using JavaScript. For example, there is the site "Enterprise jQuery" that deals with these patterns in jQuery.
Also, there are common patterns (eg the module pattern) to encapsulate private information. Don't know if you should call them "Enterpise" though.
I've been reading about node.js lately. I've seen many articles about how it's really great and all from some prominent people. Given the inertia that this project seems to have, and that I am currently learning javascript and jQuery, the project has gotten my attention. I get that many people are excited about it, but I don't quite understand what the implications are.
I understand that it is event driven and non-blocking and all of that, but where I'm confused is in regards to its intent.
Does node.js mean that we now have a foundation to run Javascript on the server-side, so that later maybe someone will create the Ruby on Rails or ASP.NET MVC equivalent for node.js/Javascript? Perhaps there already are web frameworks out there, but if so I haven't heard the hype machine yet.
I hope my question is clear.
I think the major implications are two-fold: huge performance and scalability gains, and the possibility of creating web applications where two or more people may work on the same web application at the same time, watching what the others are doing, in real-time. This latter one not only has big implications for web-based gaming, but also collaboration tools, etc.
It would appear that node.js is exactly what the real-time web needs. For that kind of thing, be sure to also checkout Socket.IO, which achieves cross-browser HTML5 web sockets. Combined with node.js, this makes for an incredible platform.
Check out what was made at the node.js knockout for some examples of what can be done.
I think what you can hope for is going to be more like twisted for Python, rather than e.g. rails for Ruby -- a rich, powerful framework, but still one requiring skill and care to use properly, because asynchronous programming is always like that... it's the price you pay for its absolutely awesome performance potential.
There are and have been Javascript server-side frameworks, but with server-side Javascript never being a really popular option, such frameworks never got the "critical mass" of support and enthusiasm that, say, jQuery has, or rails for ruby on the server side of things.
I doubt async programming (with its subtleness and difficulty) will be the defining trigger for a "mass movement" (hey, I hope I'm wrong, but I see e.g. the relative popularity for Python of Django, with none of the awesome performance, compared with Twisted, with _all_ the awesome performance... but the intrinsic difficulty too!-).
OTOH other developments (such as, simply, the wide availability of powerful, high performing, solid Javascript engines like V8) are more likely to eventually result in wide availability of (non-async;-) server-side Javascript choices, and as a consequence the possibility of the development (or porting -- e.g., a framework like dojo could already offer a lot to a JS server-side app, only parts of it are actually client-side) of powerful, simple, and therefore eventually popular framework. Nevertheless, I wouldn't hold my breath waiting for that either...
Node.js is an application server, not yet another webapp server. As the article says, it saves you the trouble of writing the event loop and using two languages to write apps (python/java/ruby/php backend, js frontend). As it is based in the V8 Engine by Google it's really fast and has a low memory footprint.
There's a web service framework called GeddyJS, and Node.js comes with a set of libraries for IO, database and math. It's also possible to extend it with addons, though last time I checked documentation was still a little rough on that.
There is a node framework called bogart which you can easily use the MVC pattern and mustache or common-ejs for templating.
http://github.com/nrstott/bogart
Assuming a team of developers are equally comfortable with writing Javascript on the server side as they are with Python & Twisted, when is Node.js going to be more appropriate than Twisted (and vice versa)?
Twisted is more mature -- it's been around for a long, long time, and has so many bells and whistles as to make your head spin (implementations of the fanciest protocols, integration of the reactor with a large variety of other event loops, and so forth).
Node.js is said to be faster (I have not measured it myself) and might perhaps be simpler to use (if you need none of the extra bells and whistles) exactly because those extras aren't there (kind of like Tornado in the Python world -- again, I have never measured relative performance).
So, I'd absolutely use Twisted if I needed any of its extra features or wanted to feel on a more solid ground by using a more mature package. If these considerations don't apply, but top performance is a key goal of the project, then I'd write a simple benchmark (but still representative of at least one or two key performance-need situations for my actual project) in Twisted, Node.js, and Tornado, and do a lot of careful measurement before I decide which way to go overall. "Extra features" (third party extensions and standard library) for Python vs server-side Javascript are also much more abundant, and that might be a key factor if any such extras are needed for the project.
Finally, if none of these issues matter to a specific application scenario, have the development team vote on relative simplicity of the three candidates (Twisted, Node.js, Tornado) in terms of simplicity and familiarity -- any of them will probably be just fine, might as well pick whatever most of the team is most comfortable with!
As of 2012, Node.js has proved to be a fast, scalable, mature, and widely used platform. Ryan Dahl, creator of Node.js quotes:
These days, Node is being used by a large number of startups and established companies
around the world, from Voxer and Uber to Walmart and Microsoft. It’s safe to say that
billions of requests are passing through Node every day. As more and more people
come to the project, the available third-party modules and extensions grow and increase
in quality. Although I was once reserved about recommending it for mission-critical
applications, I now heartily recommend Node for even the most demanding server
systems.
More formally, the advantages of Node can be classified as:
Great community: It can be said that no other platform gained such community appeal in such a short period of time, it has hundreds of contributors and thousands of watchers in GitHub, and is being used by giants like Yahoo! (Manhattan project), e-bay, LinkedIn, Microsoft, and Voxer.
NPM: Although having a relatively small core, Node has lots of packages available to extends its functionality to anything you may consider! Its all automated and being developed and extended actively, think of PyPI (pip).
Scalability and Speed: Node's architecture and single threaded nature allows high scalability and speed. Specially after 0.8 release, its speed got really faster (benchmarks), which can be confirmed by a lot of large businesses using Node. The V8 core of it is also constantly getting better thanks to the current browser war.
JavaScript: The core language of Node (JS) fits better for such server side usages, specially lambda functions, dynamic objects, and easy JSON serialization are JS highlights which really fits well in cases that speed and scalability counts. (Python has all of them but these are really better and more powerful in JS).
Deployment: Because of its wide usage, a lot of really good sites provide tools for easy and powerful Node deployment, including: Heroku, Joyent, Cloud9 and a lot more.
Therefore, Node seem more powerful and with a lighter future, so if there isn't any constraint to use it (like existing code, servers, team capability), it is recommended for any new collaborative network project aiming high speed and scalability.
We currently have a quite complex business application that contains a huge lot of JavaScript code for making the user interface & interaction feel as close to working with a traditional desktop application as possible (since that's what our users want). Over the years, this Javascript code has grown and grown, making it hard to manage & maintain and making it ever more likely that adding new functionallity will break some existing one. Needless to say, lots of this code also isn't state of the art anymore.
Thus, we have some ongoing discussion whether the client-side part of the application should be written anew in either Flex or Silverlight, or written anew with some state of the art JavaScript framework like jQuery, or whether we should simply carry on with what we have and gradually try to replace the worst bits of the existing code. What makes this even harder to decide is that writing the UI anew will probable cost us 6-12 person months.
I'd like to hear your thoughts on that issue (maybe some of you have already had to make a similar decission).
EDIT: To answer some of the questions that came up with the answers: The back-end code is written in C#, the target audience are (usually) non-technical users from the companies we sell the software to (not the general public, but not strictly internal users either), the software 'only' has to run in desktop browsers but not necessarily on mobile devices, and the client app is a full-blown UI.
In all honesty, I would refactor the old JavaScript code and not rewrite the application. Since you are asking about which platform to put it in, I would guess that your team isn't an expert in any of them (not slamming the team, it's just a simple fact that you have to consider when making a decision). This will work against you as you'll have double duty rewriting and learning how to do things on the new platform.
By keeping it in JavaScript, you can slowly introduce a framework if you choose and do it iteratively (Replace on section of code, test it, release it, and fix any bugs). This will allow you to do it at a slower pace and get feedback along the way. That way too, if the project is canceled part way through, you aren't out all the work, because the updated code is being used by the end users. Remember the waterfall model, which is essentially what a full swap out of will be almost never works.
As much as I hate to admit this, as it is always the most fun for developers, shifting platforms, and replacing an entire system at once rarely works. There are countless examples of this, Netscape for one. Here is the post from Spolsky on it. (I would also recommend the book Dreaming in Code. It is an excellent example of a software project that failed and how and why). Remember to rewrite a system from scratch you are essentially going to have to go through every line of code and figure what it does and why. At first you think you can skip it, but eventually it comes down to this. Like you said, your code is old, and that means there are most likely hacks in it to get something done. Some of these you can ignore, and others will be, "I didn't know the system needed it to do that."
These things spring to mind:
As you have a .Net backend and you have some ability to force your customers onto a specific platform, Silverlight is an option;
Since your client is a full-blown UI you want widgets and possibly other features like Drag and Drop;
I haven't seen any requirements that to me would justify starting over (which often doesn't work out) in Flex/Silverlight (eg streaming video, SVG support. Added to your team's familiarity with Javascript, I think you can't make a compelling case for doing it in anything other than Javascript.
But of course Javascript is lots of things and there are [lots of Javascript frameworks1. The most important divider is whether your intent is to "decorate" a set of Web pages or you need a full set of Widgets to create a desktop-like application on the Web. Your question indicate it is the latter.
As such--and I may get downvoted for saying this--I don't think jQuery is the answer and I say this as someone who loves jQuery. jQuery (imho) is great to enhance Webpages and abstract cross-browser low-level functionality but the most important factor for complex UI developer is this:
It's all about the widgets.
And yes I'm aware of jQuery UI but it's a lot sparser than the others when it comes to widgets. I suggest you take a look at the samples and widget galleries of some frameworks:
YUI Examples Gallery;
ExtJS demo; and
SmartClient feature explorer.
The others (jQuery, Dojo, Mootools, Prototype) are more "compact" frameworks arguably less suited to your purpose.
Also consider the license of each framework when making your decision.
My thoughts on the above three are:
ExtJS has somewhat angered the community in that it started out as LGPL but had a controversial license change (that thread is at 76 pages!) to GPL/commercial at version 2.1. The problem with that the community no longer has an active participation in the framework's development. Not the mainline version anyway. This means it's being developed and supported by a small team (possibly one person) rather than the community. IMHO it's not worth paying a commercial license for that and GPL is probably prohibitive in your situation;
YUI is supported by Yahoo and available under a far more permissive and far less invasive BSD license. It's mature, well-used and well worth serious consideration; and
SmartClient impresses me a lot. It has perhaps the most permissive license of all (LGPL), is roughly seven years old, has an incredibly impressive array of widgets available. Check out their feature explorer.
Your decision should be based on how you get as much of your application "for free" as possible. You don't want to spending valuable developer time doing things like:
Coding UI widgets like trees and accordions;
Testing and fixing cross-browser Javascript and CSS issues;
Creating homegrown frameworks that greatly duplicate what existing frameworks do and do well.
I would seriously look at one of the above three as your path forward.
This decision is usually less about the technology, and more about your skill sets and comfort zones.
If you have guys that eat and breathe Javascript, but know nothing about .net or Flash/Flex then there's nothing wrong with sticking with Javascript and leaning on a library like jQuery or Prototype.
If you have skills in either of the others then you might get a quicker result using Silverlight or Flex, as you get quite a lot of functionality "for free" with both of them.
My opinion on this one's pretty simple: unless the app needs to be accessible publicly, unless it needs to be search-engine optimized and findable, and/or there's an otherwise compelling case for its having to remain strictly text-based, then the chips are stacked in favor of rich-client runtimes like Flash or Silverlight right out of the gate.
A big reason, if not the biggest, is that they eliminate the complexities of developing for multiple browsers and platforms. Again: they eliminate the runtime-environment variable. No more debugging old versions of Netscape and IE, no more object detection and consequent branching, no more wacky CSS hacks -- one codebase, and you're done. Offloading the runtime environment to Adobe or Microsoft will save you time, money and headaches, all else equal. (Sure, there's YUI, JQuery, etc., but they don't eliminate that variable -- they just abstract it. And they don't abstract all of it, either -- only some of it; ultimately, it's still up to you to test, debug, retest, debug, repeat.)
Of course, your situation's a bit more complicated by the existing-codebase problem, and it's difficult to say definitively which way you should go, because only you've got the code, and we're just geeks with opinions. But assuming, just by your asking the question, that a refactoring of your existing codebase would involve a significant-enough undertaking as to warrant even considering an alternative (and probably comparatively foreign) technology in the first place, which it sounds like it would, then my response is that your curiosity is well-placed, and that you should give them both a serious look before making a decision.
For my part, I'm a longtime server-side guy, ASP.NET/C# for the past several years, and I've written many a text-based line-of-business app in my time, the last few with strong emphasis on delivering rich soverign UIs with JavaScript. I've also spent the last couple of years almost exclusively with Flex. I've got experience in both worlds. And I can tell you without hesitation that right now, it's everyone else's job to beat Flex: it's just an amazingly versatile and productive product, and for line-of-business apps, it remains leaps and bounds ahead of Silverlight. I just can't recommend it highly enough; the data-binding and event-handling features alone are incredible time-savers, to say nothing of the complete freedom you'll have over layout, animation, etc. The list goes on.
So, my advice: take a long, careful look at Flex. In the end, you might find a ground-up rewrite is just too massive an undertaking to justify, and that's fine -- only you can make that determination. (And to be fair, you've just as much ability to make a mess of a Flex project as you do with a JavaScript project -- I know. I've done it.) But all told, Flex is probably the least-limiting, most flexible, most feature-rich and productive option out there right now, so it's certainly worth considering. Good luck!
Any javascript you have that has been developed 'Over the years' probably doesn't look anything like what's possible today. You undoubtedly have a lot of useful code there. nonetheless. So my recommendation would be re-write in javascript using jQuery and make use of one of the available GUI add-ons, perhaps look at Yahoos stuff. You will also be targeting the widest audience this way.
The GUI technology should be first and foremost determined by your target audience. For instance, if you target englobes iPhone users, I would not recommend Flex, because iPhone doesn't have a flash player at the moment.
Bear in mind that if you switch to a full fledged GUI toolkit like Silverlight, your users may find the L&F unnatural, since the usual request-reply cycle is not so evident with client-side frameworks.
After that, it is your developers that should have a word to say. Every toolkit needs maintenance, and if you are switching to a whole new toolkit the developers will have to familiarize with the new toolkit, which can be costly.
My suggestion is that you stick to javascript, since your devs are familiar with it, and gradually replace the old javascript with a new toolkit like prototype, jQuery or any other. You will probably redo some of the old stuff faster using a state-of-the-art toolkit. Remember that you can build beautiful apps with any tookit.
We have developed an extremely rich application using EXTJS with C# and a some C++ on the server. Not only do we have clients who are happy with the interface in their desktop browsers but with very little tweaking to the Javascript we were able to provide web browser support. Also, we have clients in third-world countries who cannot use Flash or Silverlight apps due to their field personnel using kiosks in internet cafes (many of which don't have Flash installed - forget Silverlight!). I think these issues and others make up for the difficulty of coding a complex app in javascript...
Check this comparison table for Flex vs Javascript: