I have an app that is mostly traditional static HTML pages linked via anchor tags, but lately I've been adding more and more dynamic behavior using JS.
I need to "juggle" between numerous UI states in the form of hiding/showing/creating different elements for every "screen". (Let's say homepage and fullpage blog post.)
If I have only 2 states it's pretty easy but complexity arises as more and more "screens" are added.
The question:
How would I organize the various UI states so that it is straightforward to switch between?
If you're running into a lot of complexity managing your UI state, it may well be a sign that app logic is too tightly coupled with UI handling. This is especially noticeable if there are places where you need to inspect the state of the UI to make decisions about how the app logic should react.
As it gets more complex you may want to consider decoupling the UI using some kind of MVC pattern. Or even better, using a pre-rolled framework such as Knockout.js.
Note: Other frameworks are available
I would use JavaScriptMVC it's a lightweight framework that has had a fair bit of work put into it the past year or so . By having a client side mvc you could set up two different views and alternate between them with ease .
You may also want to look into sproutcore
Related
I am new to React js and I have been trying to understand what real problem does js frameworks like React,Angular solve and why one need to learn them.
Of Course when i see advantages of framework everybody talk about "Shadow/Virtual DOM, Router, Reusable Components etc" , but then I stumbled upon below links which talk something different
https://medium.com/dailyjs/the-deepest-reason-why-modern-javascript-frameworks-exist-933b86ebc445
https://www.codementor.io/binarymuse/react-components-from-a-jquery-programmer-background-du107k2lz
but they were not clear to me
So i am meaning to understand how difficult it was to maintain js/jquery code before these framework came by.
Everybody is just asking to learn these frameworks because they are popular but none of them clearly explains why they are popular and what problem they solve and how they make our life easier when it comes to creating web-app from scratch.
Others have already mentioned the advantages and what these frameworks resolve.
I wanted to add what problems they can create:
I have seen many people that use a framework see it as a hammer and every website as a nail. In other words they either don't or can't figure out that in many cases a framework is not needed. I have seen web pages that are nearly 90% static data still download an entire framework just to provide drop menus or something else trivial.
Frameworks force you into a lifecycle and development style that, in some ways, make some things easier and other things much, much more complicated. AngularJS had a nasty digest cycle that often led to complications. Redux forces you to write much more code than needed just to handle state that on many pages is not needed. Vue, React, Angular all force you to either use their data creation functions, their way of rendering or their way of handling inter element communication. And none of these are faster than vanillaJS. Even virtual DOM has its issues.
The size of a framework is often much more than needed. I have several small libraries that do the majority of the work that a framework does but my code is in the sub 5K range if I load it all.
Some people that learn a framework first can not figure out how to write in raw JavaScript. They also tend to learn sloppy ways to write code. No, not everyone, but a large number people that did not start with vanilla JS write code that tends to be much larger and sloppier than needed.
It is best to avoid JavaScript except where really needed. Often I can use raw HTML and CSS to do everything I need to do. I find that it is rare that I need to use much JavaScript even in projects that exceed several thousand files. It is faster to allow the browser to process HTML and CSS, which all processes at compiled speeds and only use JavaScript for things you can not do in HTML and CSS.
You don't "need" to learn them, but many people and companies use them. The main advantage is being able to have your entire site on a single webpage, where you just modify the data and it handles changing the elements on the page for you. For instance, you can just think about "put the user's name here, and when they click the button, add another list field there", but you no longer have to think about "get this DOM element, set its innerHTML to the user's name, and when they click the button, create a new DOM element for input, another one for the label, get the container element, append the new children". It also allows you to more easily bind data to DOM elements, so you can just say "this field is for the variable 'numberOfItems'" instead of worrying about grabbing the DOM element and its value and storing it into numberOfItems when you need it; with React/Angular/etc. that variable will always be up to date with the user's input without you needing to update it.
TL;DR: The frameworks are not necessary, but they help automatically handle a lot of common, tedious DOM manipulation for you in a way more optimized than you'd likely end up implementing yourself, with less code for you, and all on a single page instead of having to reload the page every time you want to display new data or a new layout.
What is React JS?
ReactJS is an open-source JavaScript library that is used for building user interfaces specifically for single-page applications. It’s used for handling the view layer for web and mobile apps. React also allows us to create reusable UI components.
React allows developers to create large web applications that can change data, without reloading the page. The main purpose of React is to be fast, scalable, and simple. It works only on user interfaces in the application. This corresponds to view in the MVC template. It can be used with a combination of other JavaScript libraries or frameworks, such as Angular JS in MVC.
https://www.c-sharpcorner.com/article/what-and-why-reactjs/
This is a wide discussion about frameworks in general. Is easy to say React, Angular and so on makes easier to manipulate DOM elements and reuse components, but to apply frameworks usually are about if solve your problem.
in javascript we have load the webpage by using location.href but by using angular/react we the page updates automatically.
I'm currently building a frontend architecture for quite a big site (9 digit monthly pageviews). One of the requirements is ability to fast changes as the businessfield changes, so I'd want to keep everything as lean as possible and thus am pondering about forgoing full-on MCV framework and just using jQuery (plugins) instead.
Here's how it would work:
First pageview, server renders the full page (in order to support crawling) - Loads data, renders it into template (mustache) and that into layout.
If history API is enabled, then next pageviews will be rendered with Javascript (data+mustache template), no hashrouting here (due crawlers). If not, then everything will be rendered serverside.
So, as clientside routing basically won't be needed at all, full-on MVC framework seems like a overkill.
So, here's what I'm thinking - Just do the data-loading & rendering as jQuery plugin. I'm currently even thinking about forgoing databinding as well, as the site is more about content than complex functionality, which would simplify the structure even more. Data changes could just be handled with re-rendering the content.
What kind of pitfalls does this approach have in such scale?
There are two general approaches:
First one - If your main requirement is ability to fast changes as the businessfield changes using an MVC framework might spare you a lot of grief in as using one of those leads to much cleaner and easier to maintain and extend code, even if you don't use all of its features, i. e. routing. Backbone is a good choice, if you're looking for a simple lightweight framework. On the contrary, when things start to become more and more complex, managing a growing jQuery application becomes increasingly harder, in comparison to backbone, angular, etc.
Second one - is stated in a nice abbreviation of YAGNI - You Ain't Gonna Need It. If you're certain you won't be delving in some complex frontend features, that requires data bindings, event composition, routing etc. in the forseeable future - why even bother considering MVC frontend framework? They are designed mainly to simplify creation of complex frontend applications, not to make simple things more complex. If all you ever gonna need is load server-side data and pass it to a template - then you might not even need jQuery for this, and do just fine with pure JavaScript.
So after all it's up to you to decide, does the complexity of your project call for more advanced tools, or you'd be fine with simple ones.
I am currently developing an application where I need some richer elements. Some of these are searches live updating, adding checkboxes to arrays and the like.
I have successfully implemented this using AngularJS, but I am not really sure if it's good practice to use AngularJS on just a few pages.
Would it be better practice to use JQuery for this purpose, and does it go against the goal of AngularJS?
Yea the transition from AngularJS can be a difficult one. Of course, they can both be used side-by-side but it kinda defeats the purpose of Angular. I use to be big jQuery user but I've tried to stay as far away from it as I can when using Angular.
Sometimes I'll come across a problem and I'll think to myself "Wow this would be so simple to do in jQuery". But if I stick to Angular and use their philosophy, I find that the "Angular" solution is often the one that uses better coding practices.
TL;DR: AngularJS and jQuery work fine side-by-side but I recommend getting into the habit of using just Angular, as it will result in more organized, maintainable and understandable code.
They can be used together. The two libraries have different purposes. jQuery provides an alternate interface to the DOM that is more consistent across all the browsers, so you don't have to worry about various browser eccentricities. AngularJS is a framework that provides for such things like binding MVC-style objects on the client side.
I'm reading this:
http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
I'm using backbone.js. I love it, though it requires too much boilerplate. Anyway.
The author of the post seems to put great importance on UI-bindings and composed view.
I think I know the basic advantage of ui bindings, you can change small parts of the view as the model changes without re-rendering the entire view. I don't necessarily see the point though. If your view is huge maybe you should make smaller views? I've seen knockoutjs's code and it's littered with ugly data-bind stuff. How does emberjs handle it? Is there an example?
I have no idea what he means by composed views, could someone elucidate?
Composed Views - Like all software developers, I enjoy creating modular reusable code. For this reason, when programming UI, I would
like to be able to compose views (preferably at the template layer).
This should also entail the potential for a rich view component
hierarchy. An example of this would be a reusable pagination widget.
Is there an example?
Thanks
Edit:
Would this help make something like composed Views?
https://github.com/tbranyen/backbone.layoutmanager
Composed views are used to divide the view into small blocks which can be reused or adapted to different scenarios.
For example, in a form where you are editing a user, you could create a view for the address field and just call it from the main page/template. The author mentions pagination as an example too, in this case you could create a model that knows how to handle retrieving data as you switch between pages and just apply it to a table in your page.
Regarding the "ugly" data-binding code, backbone needs to know how to attach itself to the existing markup and how to modify it when an event occurs.
Maybe this example will help:
http://coenraets.org/blog/2011/12/backbone-js-wine-cellar-tutorial-part-1-getting-started/
Traditional web pages are monolithic. User calls a page and server constructs the page and browser renders it. Here author is referring to breaking down that kind of code in to a set of views. So your page is made up of multiple parts. And each part gets rendered and updated independently. Or one model change can trigger a series of updates on some or all parts.
Basically this allows you to create 'desktop' kind of applications on web. And you don't have to resort to iframe hacks to do this.
Gmail and Google Reader are good examples of web applications built with composed views.
I created LayoutManager for Backbone.js because I too wanted to composite views.
http://tbranyen.github.com/backbone.layoutmanager/
Let me know if you find this approach helpful.
It sounds to me like the author is talking about server-side code here. Building a system of reusable page templates, that generate pages from a common set of widgets, html snippets, etc...
Apache's Tiles is one way of doing this.
I'm searching for a simple architecture for my UI that will have some basic javascript functions in like: select all checkbox's, image crop, some pop-ups and some other plugins.
I found this article: Organizing Your Backbone.js Application With Modules
My application is not a SPA (Single Page Application). I want to know if Backbone.js with jQuery will help me even if my application is not a SPA.
The strength of Backbone is really in its ability to manage many models (even complex ones) and keep the rendered page in sync with their current values. It provides an interface to getter/setter functions so that the changing of a model value (there are many different flavors of "change") will call render on the corresponding view and the page will correctly reflect the underlying models. Furthermore, it provides interfaces to saving, paging, and routing actions on models.
I have used Backbone extensively for both SPA's (where it shines) as well as more traditional, multiple page applications. It has no special support for UI and DOM manipulation, but combined with jQuery/Prototype/Zepto it manages their rendering/manipulation.
Basically, backbone works best to untangle elaborate chains of rendering logic and model updating. If you feel that your application has a lot of view elements that need to stay in sync with models that the client will be updating on the page, Backbone is a wonderful solution. If you just need to select and manipulate DOM elements, it's overkill. jQuery alone can handle that.
Backbone is really not about the things you mentioned, but I wouldn't say it is strictly for single-age apps (SPA) either. I'd say it is for any case where you've got quite complicated pages and it would benefit you to break them up into multiple pieces (for example, several views that all pull data from one model).
However, I would say the strength of Backbone.js is in the SPA realm.
You could probably find some jQuery pieces that answer some of your needs if you're not already using jQuery as part of your app. However, jQuery is all about the parts you mentioned (easy DOM manipulation, popups if you use jQuery UI, etc.) and not about structure or organization.
I believe that the principal idea of backbone, is organize you JS code in complex app using the MVC concept.
This way your app becomes easier to mantain and add new features, It get easy to use frameworks tests like jasmine.
Backbone also make possible (and very good) work based on SPA approach, using ajax request to server. It is completely based on Restful concept, to get a code using backbone, is important to understand what is Restful.
Basically Backbone have a Router (that can work like a controller. but is not a controller).
Model that is where you can manage all the data logic of your application.
Collection that is like a list of models.
View that is where you will react accordingly the model changes.
There are other things, but basically, is this.
But as I said before, you can use it without have a SPA.
The most important thing to have in mind is that the concept of MVC must be followed when using backbone. If you don't do that, it doesn't make sense use backbone.