This is really vague question but I am in the process of inheriting a rough-on-the-edges piece of jQuery for handling requests / responses to an API over JSON. Basically, each 'page' has a separate set of ajax calls and there is tremendous duplication.
I'm looking for a good blog post or maybe a jQuery plugin that separates out different dependancies for doing these requests. I'd like to keep it in jQuery. Like bundle up arguments, post, wait for response, and then delegate to a view. Something like Sammy looks interesting but might be too much.
thx
One way to tackle this is to use Selenium to write a series of tests (essentially documenting how the code currently functions) such that all the tests pass. Then, start refactoring it, and cleaning it up so it's easier to read, but the tests still pass. This way you still know that the code words the same way, but it's much easier to read.
Rewriting it from scratch might work if it's truly a mess, but it's likely that if you take that approach (rather that working to put a test suite around it incrementally, as you're refactoring it) that you'll wind up re-introducing bugs into the code that have already been fixed.
This doesn't sound like it's on the scale of the Netscape mistake, but it's a good story nonetheless.
Related
I completed a tutorial on how to make a Tetris game in-browser using JS and HTML/CSS, but I'm having trouble understanding if the author's coding practices for the JS portion are good, and if not, how they can be improved. For clarity, the code in question can be found here: https://github.com/kubowania/Tetris-Basic/blob/master/app.js
What I understand from reading this is that the author creates an arrow function that is run when all DOM content is loaded and all of the functionality for the game exists there. What I don't understand is why they just throw all of the variables, functions, and event listeners into that one function seemingly haphazardly. I think it's hard to follow and would like to learn how to improve it - what would be the best practice for something like this? Is there a way to declare the functions and variables elsewhere in the file or other JS files? Or am I incorrect and this is acceptable for JS?
I assume you're talking about how the file starts with this:
document.addEventListener('DOMContentLoaded', () => {
It works fine, but is probably one of those things that grew over time. (At least, often times I write this exact line of code with 2 or 3 lines in the event handler, and then a couple days later there's 100 things in it and its time to clean up a bit.)
Or am I incorrect and this is totally acceptable for JS?
The language doesn't care. Whether or not it's acceptable is up to you and the folks working on the same code.
what would be the best-practice for something like this?
Breaking things up into modules is commonly done. It seems to me that this code example is just that... an example. Working with bundlers to handle modules is probably out of scope for a simple tutorial. It's probably easier for folks taking this Udemy class to have this all in one place.
I am trying to follow Ilya Grigoric's performance best practices by inlining critical css & js and loading all the rest async later.
My problem is when my page needs 3rd party libs in order to render its critical path. I guess when using MVC libs like Angularjs this is not reall an option, but what if I want to use 3rd party templating library? Is there a small enough templating library that I can inline?
I am really trying to follow those best practices ang build a super fast mobile web-app, bit this seams to be really difficult using today's modern front-end development tools (Angularjs/Polymer etc.)
The question is broad and vague so it's hard to answer.
You've got a couple of issues here. First, the idea of 'small enough' is relative. You can inline any amount of javascript, so you can technically inline any template library you find.
I don't know what Grigoric's specific guidance is, but if you need the template library to render anything for the user then it IS part of your critical path and should be loaded asap. That said, if you're trying to create a fast experience for your user, it seems like you'd be better off rendering the html server side so the mobile device can react quicker to the response. If your entire document is created with javascript templates on the device you're going to have to wait for the entire DOM to load, wait for the javascript to parse, and finally wait for your templates to be processed before anything is shown to the user.
EDIT:
Don't optimize for a performance problem until you HAVE a performance problem
The goal is not to make the 'fastest possible page'. Instead your goal should be to make a page that 'works well'. Your questions don't really have 'correct' answers - it really depends on your specific situation and goals.
Regarding 'what if js is in head, will it be an issue': the answer is simply yes. Sure you can make tweaks to speed things up, but the basic architecture still has the same limitations - when you render templates on the client you're doing a ton more processing on the client. Further, you have to wait significant amount of time to download resources on first request, more than you would if it were plain html coming down the line.
Either way, in both cases your app may function perfectly well. You should just implement something and come back if you have a more specific issue.
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.
For example if you write a plugin you could do this $('#myDiv').doAction() instead of doAction($('#myDiv')). and you have to admit, the first one looks more intuitive. Are there any clear drawbacks of this like performance hits?
You won't see any noticeable performance hit from this, but there is one potential drawback: namespacing your code is very valuable, and makes it easier to maintain (as you probably know). Throwing everything into jQuery.fn may not be the best way to do this.
Personally, I shy away from extending jQuery with very specific things (like app-specific logic or something) but whole-heartedly recommend it for general, DOM-level things (.hasAttr() and .scrollHeight() are two I use a lot). The reason is that there are better places to put app-specific logic (in the module in charge of that area of the app, for example).
A simple heuristic: would it be useful to other people if I made this a public extension? Or is this only relevant to this particular project?
That said, there is no concrete problem with doing this in your code. It's more a semantic issue: is that the best place for it?
Write a jQuery plugin so that you do not need to repeat this over and over again.
There are literally minimal performance issue with this, and mindful that this is at client side, it does not attribute to your server resources.
There aren't any performance hits choosing one approach over the other. It's more of a question of, do you need it as a jquery plugin? I create regular functions if it's a utility function and doesn't need to act upon a jquery object. If it does, then it should be a plugin (no need to pass in the jquery object as a parameter, and you can chain)
You seem to be using jQuery as a framework. It is not one.
Please use a client-side MVC style library like backbone/knockout/sammy/eyeballs for seperations of concerns and structure
Please use an AMD loader like curl/requirejs for modularisation of your code.
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