I'm considering to try out an idea, mostly for fun, and my question is if this is reasonable and if there are any libraries or frameworks that could make this experiment a little easier.
So, the idea: Basically it is to write a new UI for a website I've developed, but doing it with client-side code only. I can read/write data using ajax, since my existing website has an API that allows me to perform all kinds of queries. This allows me to use JavaScript for the whole thing and theoretically put all of the code in a single file.
Obviously there are limitations to circumvent; bookmarking, page refreshing, the back-button etc. But these limitations are what makes it interesting, right? :) I'm not so worried about search engine indexing, since one has to be logged in to use the site anyway.
The site itself is not overly complex, but it is not simple either. There are four different levels of users, multiple languages and quite a lot of data to be presented.
Is this a bad idea? If so, why would you advice against it? And do you know of any JavaScript frameworks or libraries that could make this easier? (And no, I'm not looking for an abstraction like Google Web Toolkit; I would like something purely JavaScript)
One of my coworkers did this. A nice feature of this concept was that you don't have a ton of POSTS whenever the user 'changes pages', since they are actually not ever changing a page until they submit their data for the final time. He did this for product registration software, which was nice. Our servers were only taking a hit when the user initially requested the page, and then when they submitted it.
The major, MAJOR downside to this concept is that most web developers are not expecting this. My coworker (and you) have a cool idea - but unless it is well implemented, with comments, 100% valid HTML, and a host of other good design principles in place, it can be confusing since most web developers have basically never seen this done before. His site was a nightmare to work with, as he did not actually know what engineering web software meant, and it was all slapped together. My organization never pursued this (potentially useful) idea because his implementation was so poor.
So, when I looked at this idea here were the trade-off I came up with:
1.) You cannot require any server-side interaction during intermediate pages.
2.) The initial page loading is longer, but there are no intermediate page requests (better optimization).
3.) This is vastly different than anything anyone usually does, which means you need to be especially careful with documentation.
4.) This design concept facilitates totally stand-alone web software to be easily deployed without the web.
5.) You might be increasing complexity for avoiding page loads, but maybe not. I'm not sure.
All together, I think it just depends on what you want to accomplish. My coworker really just wanted to see if he could do it, which he could. However, how he did it was really pretty bad, to the point where everyone else connected his poor implementation with a poor idea it was fairly sad.
Mostly, I think if you follow good web design practices this wouldn't be too bad of a thing to pursue. What are your goals though?
I'm sorry I couldn't directly answer all of your questions. I hope my experiences are still helpful in answering if I think it is a bad idea or not.
-Brian J. Stinar-
SproutCore is one of the best out there when it comes to really being built from the ground up for single-page, potentially complex applications. Unlike some others like GWT or Cappucino, SproutCore is really about using JavaScript directly. They aren't the only one though. You might also want to look at JavaScriptMVC and qooxdoo.
Personally, I've built an extremely large and complex single-page application using JavaScript. It is currently around 100,000 lines (including comments/whitespace). To give a sense of scale, jQuery is around 6,000. To reach that size, I built my own framework, build tools etc. and it is extremely maintainable. You're asking if it can work, and I can tell you that it does, but you do need a little infrastructure if you're looking at doing something big. (BTW, there's a lot of lazy loading - its not 100,000 lines all at once!)
I also wouldn't really recommend this method for anything other than a web application. As pointed out, its still difficult for SEO, and may be strange for some users.
You're looking for ExtJS
I did my site like that in jquery, backed by spring mvc 3. For me it works fine and you have a lightweight, flashy feling while on it.
If you have time to dig in javascript seriously... it is really good exercise.
The only thing I really need to add is SEO, since spiders see only intial html. If it is important for you, i think backend static files and sitemap would be good enough solution.
I found something very light-weight that provides the basic needed functionally without forcing you into a whole framework. It's called Sammy and is inspired by Ruby's Sinatra: http://code.quirkey.com/sammy/
Very recommended!
Alternative: code the same in Java. Take a look to ItsNat
Think in JavaScript but code the same in Java in server with the same DOM APIs, in server is way easier to manage your application without custom client/bridges because UI and data are together.
Regarding SEO, bookmarking etc in single page there are solutions, take a look to the Single Page Interface Manifesto
Related
For the past six months or so I've been teaching myself Javascript by building a single page application that uses Raphael to create all of the elements the user sees and interacts with (see the landing page for the project for a small-scale example of what the tool will do). As I've been learning more about the language I've been coming across a lot of talk about using something like Backbone to structure the code such that it will be easier to read and maintain. While I'm not in love with the idea of taking what I've written and shoehorning it into an MVP paradigm (which would also require me to learn the paradigm), I am in favor of writing quality code that won't cause me headaches later. However, in the course of doing some google research, I've discovered that backbone doesn't seem to play nicely with SVG elements. True, there are some workarounds posted, but it seems to me that if I have to implement a kludgey work-around in order to get everything to work, the value of implementing Backbone in this case is lost as my code is still wonky, albeit in a different way. (ego compels me to point out that as it stands, the code is reasonably un-spagettified)
Given that I'm relatively new to Javascript, and to serious web programming in general, I'm posting this question here in the hopes of soliciting advice from persons more learned than I in matters such as these. If you were in my position, would you implement Backbone (or some equivalent) or would you proceed without it?
I would suggest you keep doing what you are doing. The website looks good and responsive. Do not change anything as long as you think the code is easily maintainable and readable. When you see heavy loading and spaghetti code, then you might consider about using some JS structure.
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!
I have learned and can read/write code in JavaScript. I am a backend engineer by profession and want to learn how to build websites. I have gone to the point where I can build wireframes and start writing basic HTML. I've never succeeded in creating a complete webpage, because they always looked awful midway through.
I've seen many JavaScript frameworks (like Bootstrap, Backbone.js, and others) that one can use to create websites.
Which framework(s), if any, should I use? Which would you recommend I use to start building websites (and why, if applicable)?
I wouldn't recommend you using a JavaScript-framework to build your entire website. I would only recommend JavaScript to enhance your website with cool features.
I'm not sure what type of website we're talking about, but if you're planning on getting traffic from search engines — think twice.
Google aren't that good at reading content embedded in JavaScript. Meaning: your SEO will be terrible if you choose to build the website entirely in JavaScript.
HTML/CSS is easy, man. I'm sure you'll be able to learn that in a one day — tops! You're a backend engineer by profession for gods sake, HTML can't possibly be that hard to get a grasp of :)
I was in your exact shoes not so long ago - I'm a programmer and had no issues picking up the backend programming that is required of websites, but when designing the web page is something I just could not do. I would end up with terrible looking web pages which was very discouraging.
One great way to get around this is use HTML/CSS templates - there are plenty free ones available. Download one you like, then go through the CSS and change as much of it as you need to personalise your site. This process will also give you a great understanding of how CSS works, and how it should be used to design a page.
After doing this a couple of times, you will be confident/able enough to design a webpage from scratch. If not, continue using the templates. No harm in that.
As others have already mentioned, for a powerful, dynamic website you will need a server side language as well. Javascript frameworks like jQuery are nice for the front-end for the website. For the back-end you can try CakePHP, CodeIgniter etc., or just code the back-end from scratch. Doesn't seem that would be a problem for you.
Some sites that provide free HTML/CSS templates:
CSS Creme
FreeTemplatesOnline
Most of them are optimized for 1024x768 which might seem a little outdated for a few. Try tweaking the CSS code to make the template suitable for your purposes - change images, width etc.
You can't exactly build a website using JavaScript. You could, but that would be very inefficient...I recommend going through some HTML tutorials, as you (and the websites you build in the future) will benefit a lot from the fact that you use HTML primarily, and enhance it with JavaScript. After all, JavaScript can't do much in comparison to HTML (since in order to build a site with JavaScript (or my interpretation of what that is), you need to have a basic understanding of HTML).
Unless I misunderstood your question, then that's about it. Frameworks like jQuery can really enhance a page and make it beautiful and, fortunately, much more user-friendly.
You can't create a website (at least a dynamic one) without a server side language. There you can pull from a number of languages.
If you are just a JavaScript fan, then you can use server-side JavaScript code as Node.js. On the client side you can use jQuery and you can have a supporting database like MySQL.
I have been a user of jQuery (and some of its minor plugins) for a while. The Javascript code I've developed over the years could be described best as... messy. It used a ton of global variables and functions here and there, didn't use standard ways of organizing the code, nor any design patterns whatsoever.
I am currently building the new version of a website, and I have completed doing the backend with PEAR::MDB2 and Smarty templates. The rest is just homebrew PHP with some classes.
Now I am at the point where I'll add the Javascript layer on top of the website to improve the user-friendliness of some features. (while making sure everything degrades gracefully) I want to write better, cleaner, more organized Javascript than I used to, so I did a little research. I read Stefanov's Object-Oriented Javascript to have a better grasp on some concepts I knew only loosely about (prototypes, constructors, etc.) as well. Now I'm stuck at a point where I wonder which Javascript frameworks I should use, and how to organize it all.
After conducting my research, I understood Cappuccino & Objective-J, and Sproutcore were not what I was looking for. To quote Cappucino's about page:
Cappuccino is not designed for building web sites, or making existing sites more "dynamic". We think these goals are too far removed from those of application development to be served well by a single framework. Projects like Prototype and jQuery are excellent at those tasks
So there's that. Then I found out about Coffee Script, which is more of a one-to-one "compiler" and wouldn't help me with the actual organization of my code.
I also stumbled on some articles that give guidelines:
Using Inheritance Patterns to Organize Large jQuery Applications
A JavaScript Module Pattern
I also found out about Backbone.js, Shoestring, JavaScriptMVC, Google Loader, jQuery Tools, jQuery UI. I don't really know what to do of all this... The things I know:
I don't want to invest too much time in learning something too complex, I want to keep things simple and flexible as much as possible (that is why I don't use Symfony on the backend, for example), yet clean and organized.
I want to use jQuery, the question is, what should I use with it? (that is compatible too)
Right now, I'd use jQuery and jQuery Tools and "organize" all that in a simple namespace/object literal with simple properties and methods and also, since the site is localized, I just plan on using the simple vsprintf (as I do on the backend) with key:value pairs loaded from an object literal provided by the backend. JavaScriptMVC seems interesting, but I fear it would bring way too much complexity for a project that is fairly small sized. That is where I need your advice! Thank you very much in advance.
Ok, my attempt at an answer:
There is no 'best' to way to do it. You now know what's there and I think you might have a preference for yourself for what you want. In that case, pick a framework and learn it inside-out. (sorry to burst your bubble, but each framework has a learning curve, some steep, some very easy, but in the end to use it well you have to invest in it. Just do it, you won't be sorry).
You of course have an preference for clean code, so you might take some considerations into account. You also say you have a preference for jQuery, which is fine, but there are some limitations (as also pointed out in the link provided by eskimoblood).
There are some nice lectures / and tutorials with advice on how to structure your code in jQuery:
How to manage large jquery apps
On Large jQuery apps
Essential Javascript and jQuery patterns (free ebook)
Some style guides:
Jquery core UI Styleguide
Google Closure Javascript Style Guide
Tools for checking your code
JSLint
JSHint (a more forgiving/practical fork)
Closure Linter (haven't tried it yet, but intend to)
Standard works (javascript)
Everything by Douglas Crockford
Quirksmode
There might be more.. perhaps more people can contribute, but I also think that you've almost reached the end of what you can learn before getting your hands dirty. Many of these guides are written in a very generic way, but the interesting thing is that javascript is called upon in many specific situations. It might be useful to just post some of the code that you regard as "messy" and we can help you figure out how to do it better. Good luck!
You should watch the video and read the links in this article and then you should ask yourself again if jquery is the right tool. Maybe you will use dojo, that is much better for larger projects or you take a look at backbone and where you can stay with jquery. After all both of them are more "javascriptish" then something like sproutcore, cappuciono or even GWT. And also much easier to understand when you come from jquery.
One framework that is to consider is definitely ReactJS from Facebook. This framework is pretty slick in many ways.
First thing you have to know is that it is a view framework. It can be used server-side to do the pre-rendering of pages, but it really shines on client side. Since it's a view framework, it can be used with backbone or any other "back-front"-end framework.
One of the main point of React is its rapidity. It keeps a virtual DOM in memory and virtualize all the webpages events. So the virtuals event are used to keep events browser agnostics.
The virtual DOM kind of make programming a dynamic site as if you were programming an old static website. You can just shoot the whole HTML to render to the view engine (as if you were "re-rendering" the whole page) and it will manage the DOM operations. It does a diff between the new virtual DOM and the current virtual DOM and only inserts nodes that needs to be inserted. This way you reduce the number of DOM ops and thus increase your render speed by a lot.
A good place to start is this tutorial which shows how to use "Flux" (the web flow designed by Facebook for its site) in order to realize a Todo application!
The previous programmer left the website in pretty unusable state, and I am having difficulty modifying anything. I am new to web design so I don't know whether my skills are a mismatch to this kind of job or is it normal in the real industry to have websites like these
The Home page includes three frames
Each of these frames have their own javascript functions ( between <head>, and also call other common javascript functions (using <script src=..>
Excessive usage of document.all - in fact the elements are referred or accessed by document.all only.
Excessive usage of XSLT and Web Services - Though I know that using Web Services is generally considered a good design choice - is there any other way I can consume these services other than using xslt. For example, the menu is created using the data returned by a web method.
Every <div>, <td> and every other element has an id, and these id's are manipulated by the javascript functions, and then some appropriate web service and the xslt files are loaded based on these..
From the security perspective, he used T-SQL's for xml auto for most of the data that is returned by the web service - is it a good choice from the security standpoint to expose the table names and column names to the end user??
I am a lot confused about the state of the application itself. Should I learn about the intricacies that he has developed and continue working on it, or should I start rewriting everything? What I am perplexed a lot is the lack of alternatives - and whether this is the common way web projects are handled in the real world or was it an exception?
Any suggestions, any pointers are welcome. Thanks
No, it is not acceptable in this industry that people keep writing un-maintainable code.
My advice to you is to go up the chain and convince everyone that this needs to be rewritten. If they question you, find an external consultant with relevant web development skills to review the application (for 1 day).
Keeping this website as-is, because it 'works' is like keeping a working model Ford-T car on today's highways, very dangerous. Security and maintenance costs are likely the most persuading topics to convince anyone against keeping this site 'as-is'.
Next, get yourself trained, it will pay off if you can rewrite this application knowing the basics. Todays technology (asp.net MVC) allows you to implement core business value faster than trying to maintain this unconventionally written app.
Tough spot for an inexperienced developer (or any) to be left in. I think you have a few hard weeks a head of you where you really need to read up on the technologies involved to get a better understanding of them and what is best practice. You will also need to really dig down into the existing code to understand how it all hangs together.
When you done all that you really need to think about your options. Usually re-writing something from scratch (especially if it actually works) is a bad idea. This obviously depend on the size of the project, for a smaller projects with only a couple of thousand lines of code it might be OK. When looking at someone elses code it is also easy to overlook that all that weird shit going on could actually be fixes for valid requirements. Things often start out looking neat, but then the real words comes visiting.
You will need to present the business with time estimates for re-writing to see if that is an option at all, but I'm guessing you will need to accept the way things are and do your best with what you have. Maybe you could gradually improves things.
I would recommend moving the project to MVC3 and rewriting the XSLT portions to function using views and/or partial views with MVC. The Razor model binding syntax is very clean and should be able to quickly cleave out the dirty XSLT code and be left with just the model properties you would need.
I would then have those web services invoked from MVC serverside and for you to deserialize the object results into real objects (or even just use straight XQuery or Json traversing to directly pull stuff out for your model) and bind those to your views.
This could be a rather gargantuan leap for technology at your company though. Some places have aversion to change.
I'd guess this was written 6-7 years ago, and hacked on since then. Every project accumulates a certain amount of bubble gum and duct tape. Sounds like this one's got it bad. I suggest breaking this up into bite size chunks. I assume that the site is actually working right now? So you don't want to break anything, the "business" often thinks "it was working just fine when the last guy was here."
Get a feel for your biggest pain points for maintaining the project, and what you'll get the biggest wins from fixing. a rewrite is great, if you have the time and support. But if it's a complex site, there's a lot to be said for a mature application. Mature in the sense that it fulfills the business needs, not that it's good code.
Also, working on small parts will get you better acquainted with the project and the business needs, so when you start the rewrite you'll have a better perspective.