When would one go for using Javascript MVC ? I mean why there was a
need for JS-MVC ?
Is it only because this design pattern was famous in other languages, for code maintenance,readability and many web apps are shipping client side ?
How does it helps a developer, tester and end-user easing their
tasks ?
Any use-case where JS-MVC is suited best and any case where it is
not at all required ?
Question 1,2,4
My view is that you should apply any kind of design pattern only and only if you really need it. Simply because design patterns aren't easy after all. They will add complexity to your solution, but they'll also provide you the benefit of (normally) being established and working solutions for specific kind of problems.
Whether to use or not use them really depends on what you are going to construct and how complex it is. That said, I'm probably not going to structure my 200 lines jQuery plugin using the MVC pattern, maybe...
But at work we create single page applications where we have 2-5 devs working on a project the same time, projects of the amount of 500 days. In such environments things can get complex very quickly and if you don't follow any kind of proper structuring you're lost.
I hope that should answer your question 1 and 2.
For question 3:
The end-user hopefully gets a better quality app with less bugs, but usually he shouldn't even notice (nor does he care) about the underlying architecture of an app.
MVC helps the developer
as an orientation when navigating in the app's source code. Consider an app of 3000 lines of code in a single source file and then when having 4 devs working on it at the same time. A mess, right? When having an MVC app which normally also use routings etc...you normally already know by looking at the route in the url where the corresponding controller lies in the source code and where you should put your hands on
for easier testing. Separation of concerns is always beneficial when applying unit testing practices because you can much easier test your controller because it isn't directly couple to data or presentational stuff (like HTML code etc). And just as a side note, you should definitely unit-test your JavaScript code, definitely!!
maintenance: which is the result of the previous points somehow
I'm not sure which kind of figure you intend by "tester". If he writes automated tests at the unit or acceptance level, then the benefits from before pretty much hold as well. If he's testing the app as a whole in the sense of navigating around, taking the app as a black box by testing its reaction to different kind of inputs, then MVC doesn't really play a big role for him. It's like for the end-user.
So I hope I was able to clarify some things for you. But as said, never just follow a pattern because people follow it but only 'cause it gives you any kind of benefits.
MVC is used to structure your code especially if you are working a lot with client side rendering. Without structure your code gets complex very fast.
User experience for end user is much better when you don't have to wait for the whole page refresh if you only need partial update.
It helps to navigate through the code much faster if you have well defined structure of your code.
JS MVC frameworks are best used where you have complex systems and you want to provide better user experience by using AJAX and partial page reloads or updates. Usually you would not use MVC for Personal website, blogs or stuff like that...
Related
I just start thinking about communication between two angular (or others framework) applications - what is the best way to do that.
For now, in my application, I used iframe to include the second app and then thanks to postMessage (docs) I can handle actions between apps.
But this solution is getting really hard to maintain because I didn't expect at the begging that I will have to handle soo much type of events.
Let's give you an example:
On Facebook when you go to someone profile you can click "Send message" and it will open a new window on chat application. In other way you can also click on some button in their chat and it will send some action to "main" application.
I just read few articles and start thinking about using WebSockets, using firebase etc but I want to make some more research and ask more expired developers (yes, you! :) ) what they thinking.
So, my question is:
What is the best approach to include two (or more) angular apps?
What is the best approach to handle communication between these apps?
It sounds like you have a really fun problem to solve. There are a number of different ways to go about this, and I'm not sure how your website architecture is setup and what constraint's you have, but I can at least provide some suggestions.
Possible Solutions
Look into separating separate functionality into lazy loaded Angular modules, and treat them as separate websites altogether.
I've done this for a few applications and it gives you some of the flexibility you're looking for. For this to work with your application communication constraints, there are a number of different ways to approach it.
If you can get away with a single application, then you're going to want to look into state management solutions like NgXS, NgRX, Akita, or roll your own statemanagement. I personally roll my own for these things because I rarely need to overhead of the bigger frameworkss, but to each their own.
If you can't get away with a single application, then you're going to want to separate your state into something like FireBase, or a custom websocket app. This would give you better persistence of state, and also allow you to connect completely independent web applications to one another.
Another promising solution to things like this is the tool SingleSpa.
Single spa is a meta web framework that can help navigate and orchestrate multiple SPA's written in different libraries/frameworks into a single application. This would allow you to re-use the existing website that you're using the <iframe> for, but have it bundled within the same parent application. I'm not too familiar with this framework in practice, but I have some coworkers and peers who use it, and it seems promising.
Take a step back and identify the core problem you're trying to solve
This one isn't trying to troll or anything, just helping to take a step back and look over your application from a 10,000 foot overview. Look over how the data is being passed in the solution, are you solving the problem directly? Or is this solution a hack to make due with the constraints that you had at the beginning. Don't be afraid to rebuild parts of the application, or service. Theres a reason people talk about the 10 to 1 rule of writing code.
I understand time and complexity constraints, you have deadlines and other things to deal with. Just make sure you're solving the right problem and thinking about the different edge cases you can leverage to your advantage.
I recognize after writing this out that its not a direct answer per say, but I hope it helped. Message me if you have any questions on this stuff.
I've mostly worked with Springboot framework only with JSP to cover the things I need for the website part. Now, I've got a project to do that mostly revolves, if not all, around the website and I have a couple of questions.
Just to be clear first, I don't have experience either with Thymeleaf or Angular so whichever I pick will be the first time (I think thymeleaf syntax would be easier for me to handle).
Ok so the main goal in my mind is not to render the whole page every time I load data from the backend, so I figure I would have like a header/content/footer parts where every time I click something only the content part would change. Also, I would like the possibility for a loader to show and go away when the content part is changing. This web application will need to be secure for users that register.
I've searched the web to investigate both frameworks, but can not seem to find the right answer so I can continue with my development
I do not mind creating separate REST services in later development if some other platform needs to hook up to the service if I decide to go with Thymeleaf.What do you guys think in what direction should I go, Thymeleaf or Angular? Any help and/or discussion would be much appreciated.
I am sorry if this seems like a general question, but I just need some basic guidelines to start with. Cheers!
I think transitioning to ThymeLeaf is probably going to be the easiest for you, but Angular is a great choice as well, and from there it is up to you. Would you rather use mostly expressions similar to JSTL expressions, but in Spring's SpEL language, then use ThymeLeaf, or would you rather use JavaScript, then use Angular. It just a user's preference for what you are doing.
The fragmenting portion (header, footer, body, etc..) is native to both frameworks. It just depends on which one you want to use. Whatever you go with, to load specific sections while not rendering the others, is going to require AJAX and for you to feel comfortable with how the template frameworks work.
I would suggest reading up on both of them to figure out which one you feel more comfortable with.
Angular
Thymeleaf
Both of them have great documentation for beginners and the Baeldung and Mkyong have good walkthrus for ThymeLeaf. Angular's documentation I found good enough on its own.
For a loader, you can do with simple CSS and JS. There is a ton of demos out there on how to do full screen loaders and how to turn them on or off with JS or CSS. IHateTomatoes has a good article about how to build a full screen loader, that has a No JS fallback option and should give you a good starting point.
Your point about it needing to be secure is a whole other monster. I would look into Spring Security. It's relatively straightforward, especially when using Spring Boot. If you want it can control the users session and assist in preventing session jacking, add CSRF to prevent cross site forgery, control permissions to urls and on down the line, or not. It all just depends.
Either way, don't randomly stab at security, it will end up in something that you feel is secure but it is not, which leaves you and your users in a very bad spot. Again, Baeldung has a great walkthru on the user registration and login process that can help get you started with Spring security and how to tie everything together.
Pretty high level answer, but hopefully gave you some good starting points and some resources.
Build apps decoupling frontend from the backend.
Always build apps following the "The API-first approach"
The API-first approach involves setting up the foundation of your app, which is the application programming interface
For me the differences between Thymeleaf and Angular:
Using Thymeleaf: You don't need to create Restful/web service endpoints on your frontend side because you just need to make calls to the backend from the frontend itself.
Using Angular: Besides of your Restful/ web service endpoints on your backend side, you have to build Restful/ web services endpoints on your frontend side because you don't want to expose direct access from Javascript code to the backend.
Hope this helps and happy coding time!
First, I would like to ask some very basic questions about MVC in general. Simple questions, but can't find any good answer for them.
Is MVC useful for a one man project, or is it only needed, when more people work on a project to make it easier to co-op?
How big a project needs to be, to make good use of MVC. I hear everywere that I should always use MVC, but even for big projects it looks like an overkill. I can't imagine how big something would need to be, for all this overcomplicating to pay off.
I have made a single player rpg that is pretty short, and I am trying to turn it into massive multiplayer. It is all for educational purpose only. So I was thinking to redo it with MVC, but even though it has a lot of functions and data to process it still looks way to simple and clear, to bother with MVC. Maybe if I am making so small projects that I can't see the benefits of using it, I just shouldn't use it?
Will using all the MVC additional code slow down my app in visible way?
Now about Javascript, there are some solutions for MVC avaliable. Are they worth using?
Thanks
MVC is just a pattern, guidelines to organize your project and decoupling your code, so the size of the team or the project is not relevant. I've made by myself a very simple website with a list and a couple of web forms using MVC and it was pretty faster to develop than other alternatives. If you have the opportunity to work with a powerful IDE like Visual Studio, you will find that most of the common things to do for building a web page/site are already automated. And I also have worked with 12 people in a bigger project using also an MVC approach without noticing differences.
One of the main advantages of using MVC is that you can change the whole front end in the future without having to make changes in your model or controller layer.
Also, using MVC doesn't have to slow down your code, it depends on your implementation. When using ASP.MVC instead of ASP.NET, for example, the code and download times are faster, in fact. With ASP.MVC you get rid of nonsense ViewState pieces of code and the html code generated is cleaner.
In my experience, MVC is an excellent pattern to chose for working in web projects, since the front end technologies are changing very fast and it gives the flexibility to evolve with them without having to annoy about the business logic.
I hope I have helped you.
You can find more info in:
http://www.asp.net/mvc
I've been asked at work to convert a popular mechanical engineering excel application to a single page web application. It requires no database so my idea is to put everything on the clientside in javascript.
First version is gonna be pretty small but more complexity will be added further along. Canvas graphics is gonna be drawn in realtime as user changes input. So performance is important. My question is: Should I use a MVC framework such as Angular JS? Or is it better to stick with Jquery? If I should use a MVC, which one is best suited for this app?
Everyone at my company uses IE9 so I dont need any support for older browsers.
Angular bills itself specifically as a way to build CRUD apps - basically database front ends. The app you're describing doesn't sound like it's doing a ton of that, so Angular would probably be more trouble than it's worth.
jQuery is a helper library - it makes dealing with the DOM easier, but doesn't do a thing to provide overall structure to your application. jQuery is a "necessary but not sufficient" in my book - you're going to want it, but it's not enough on its own.
Personally, I'd lean more towards Backbone, specifically because it's so minimal - it gives you some useful data binding stuff and some hints on how to organize your app, then gets out of your way to let you build the abstraction you want. Based on the fact that you mentioned the original is in Excel, some sort of data binding / change notification system is going to be important. This way you can emulate the spreadsheet's "change a cell and the chart redraws" system that everyone's already used to.
In the end it's hard to say without more detail on the app in question, and what kind of calculations / how often they have to happen are. Figure out what your app architecture should be, find (or build) a library that helps implement that architecture. It might be MVCish, it might not.
Well jQuery will get very messy as complexity increases. Angular JS is an amazing library but there are also a myriad of different ones out there. Depending on the Mechanical Engineering principles you are working with using AJAX may prove to be more perform-ant, due to the lack luster power of some older browsers.
It really depends on the complexity of the calculations, but in terms of dealing with events and managin the structure I would suggest using Jquery as well as Angular on top of it. then make the decision about whether or not to move some functions to the server or not, based on performance.
I have a few years' background with server-side MVC app development using CakePHP and a few more with vanilla PHP. Sadly I can't say the same about JS apps, although I do have experience in spicing up static pages with Mootools.
So now I'm trying to study client-side app building and my success so far hasn't been so great. Since the only MVC I've touched is CakePHP, every JS MV* framework seem incomprehensible at best. It doesn't help at all that I've grown so accustomed to writing neat CakePHP and Mootools Class code that big blocks of JS code feel just disorderly.
I've even tried to write my own simple MVC-like lib by imitating CakePHP for mostly academic use. I guess it's needless to say that I haven't really gotten anywhere with it.
Some things I realised while studying and writing my own MVC:
Js is asynchronous. CakePHP works the way it does because PHP is synchronous. In JS there's an endless list of things that need to be implemented differently and about just as long list of things that can be done differently thanks to async. What are the most important differences between server-side MVC(or CakePHP implementation of it) and client-side MV*?
I still don't quite get the concept of client-side models. In Cake they handle data validation and database connections. Client on the other hand is an unsafe environment, so client-side models can only do basic data filtering, pre-validation and default values. Am I completely wrong here?
Some apps require a server counterpart. Should Server also be MVC?
It seems that in client-side MV* you can have multiple controllers simultaneously. Although I kind of understand that it has its uses, my knowledge at this point is so little I can't even think of a better question than "What good does it do?"
I've also downloaded TodoMVC and tried to examine the different frameworks with little success. The main problems with it are that it's only single-page(actions happen at different urls but the layout stays the same) and the implementations are so different that I'm having hard time even comprehending the basics, let alone finding the best suited framework for me. Also, it doesn't communicate with the server in any way, which is a huge disappointment since I'd wanted to see how different frameworks do that.
So, the optimal answer to this question would be a link to a book called Client-side JavaScript MV* For Dummies (Who only have experience in server-side MVC), which would earn you somewhere around 500 internets in addition to the regular StackOverflow rewards.
I would be extremely thankful for any insight(ful links) on any of my ramblingly written question's topics. You will be rewarded with the standard +1s and as a further incentive I promise to write your nickname on a post-it note and keep it on my monitor for the next month. The person with the most helpful answer of course gets an Accepted and additionally may provide a picture to be printed along their nickname to be attached to my monitor.
I'm interested to know where you ended up on this one. PHP was my first love, and while I still enjoy the ease of the language, it's hard to really take it seriously when it so clearly is being phased out for faster, more scalable technologies.
You hit it on the head that javascript's asynchronousness complicates things, but it definitely opens the doors for performance increases. There are quite a few libraries (more for node.js than client side work) that aim to make javascript written as if it's synchronous - again I don't see it helping with your current ask, but it's good to know other's share your pain.
I think MVC in javascript can be thought of like this:
M: the models are simply an explanation of your data. So if you have a person, you can say that every person has a first name that's a string, an age that's an int and so on. Now whenever you create a new person, you can have validation. Models, client side, tend to be very simple, I've found.
V: views are another interesting thing. Some like to have a big set of render functions that contain strings of HTML (ew). Other's like to have the views just be a wrapper for a templating engine like handlebars.js (probably a better solution).
C: functions pretty much identically to a controller in PHP.
My advice for you would be to NOT write you own, but rather take Backbone.js (quicky becoming the industry standard), learn it inside and out, and perhaps build on top of it.
Good luck!