I need to make a webApp with a good framework.
Actually i have been working with angular and i think that it can be not enought to my app because it is going to have a lot of work in the part of the client so i have thought in react.js or meteor.js.
Finally, i think that i am going to use meteor.js because it can make in the server and make the client to be with less work, but i want more opinions about it to decide what framework use.
In my app i will need to create a scenary with objects where the user is going to be able to move that objects in the scenary, so it can be a lot of work for the client.
Their all good frameworks and will have their ups and downs whatever you're building. I would suggest to use the framework you're most comfortable with.
This may help to choose: http://todomvc.com/
Related
I'm a big fan of koa.js, and previously I have worked on projects where we combined koa with angular and they played nicely together, so I was wondering how about using koa with vue.js (as a more lightweight framework) and see how they perform together, because I didn't see many implementations of these two.
I'm thinking to use Koa.js for the server and route handling, and Vuejs only for front-end (view rendering, data binding etc.), so I wanted to know what are your best practices to design the web-app and how to configure the project build (if that necessary, how to integrate webpack?).
Also, any feedback you can give for these two playing together would be a great help for me.
I will start to develop a new Project and i want use Asp .NET core and angular.js but i have a question what is the better way, use asp.net and angular together or separately?
I defined my architecture in this form
Cliente1(Angular)->RestApi->BussinessLogic->DataAccess->DB
yes, i see that my architecture says me that i need manage asp .NET and angular js separately, but I'd like to hear any suggestions.
UPDATE:
thank you for your answers, in the end both they have their pros and cons, i would like to share with you this articles:
Together: http://proudmonkey.azurewebsites.net/asp-net-core-getting-started-with-angularjs-2/
separately:
Part one: https://chsakell.com/2016/06/23/rest-apis-using-asp-net-core-and-entity-framework-core/
Part two: chsakell.com/2016/06/27/angular-2-crud-modals-animations-pagination-datetimepicker/
In general in programming you should separate your logic the most you can.
You will want to separate both projects for so many reasons :
You have a web app right now (angular) but maybe in a near futur you will need to have a mobile app (hybrid or native)
You can be more than one person working on the project, for example you will maybe need some designer/integrator to work on the app, and you dont want to share with him your back end, same applies if you have a back end guy.
two projects means maybe two source control repositories, means more control on branches, versions, rolling back ...
etc ...
I hope this can help.
If I see other benefits, ill update this answer.
Keep them separate, your MVC Part will be mainly REST APIs which has nothing to do with the JavaScript, HTML and CSS in the Angular Project, besides, if you want to build another client, EX: Mobile, then it will have its own project as well, this way you will have a clean structure for your solution.
So, you should have the following:
YourProject.REST
YourProject.Angular
YourProject.MobileClient
Also, the separation will make it easier for the teams working on the project, the one who will work on the front end doesn't have to worry about any other code not related to his tasks, the same for the developer working on the APIs, and each project can be structured as per the best practices for its technology.
You question is opinion based more than facts, so here is my opinion.
I have done few projects with ASP.Net MVC, Web API and AngularJS. They all stay in a single Web Application Project. Note: I have few class libraries for strongly typed Angular Helpers, Business Logic and Data Access.
Here are the advantages
I authenticate user using Owin Middleware, then redirect to Angular. The main advantage is I do not have to maintain Bearer Token or Authentication Cookie explicit inside Angular.
Second, I use csthml as strongly typed Angular view rather than plain html. It is the best of both world.
Last but not least, you can debug it easily rather than starting two projects at the same time, so that I can save resources on development machine. Everyone know Visual Studio is a memory hungry IDE.
I've been learning Angular 2 recently, and I must say that this is a great framework if I wanted to build a single-page application.
However, I was wondering how one would integrate angular with a normal, old style websites (say, built on codeigniter) if they only wanted the two way binding functionality?
Of course, I could use angular 2 for that, but with all the routing machinery of angular, it seems rather... out of place. It just seems like I'm trying to use an axe as a hammer.
So, my question is: what would you suggest to someone who wants to build a non single-page website, with old school loading pages, but for the page itself to be very interactive and utilize two way binding? For example, a users list which is a page in itself, but pagination is done via ajax... etc Should I just go with angular2, or maybe another library that's simply more suited for this purpose? Some suggested that ReactJS may just be what I'm looking for.
What do you think?
Although it's true that
client-side routing is just a small piece
of a very large framework, the fact that the structure of a Angular (2) project has exactly 1 index.html file with no server side code, at least implicitly tells us that there's a lot of framework intended for SPAs which a multi-page application may not need.
If what makes Angular 2 a great framework for you is data binding and productivity then have a look at Ember.js. Ember makes it easy to follow best practices rather than spending time on trivial choices.
According to this article from AirBnB
it says
A Hybrid Approach
At the end of the day, we really want a hybrid of the new and old
approaches: we want to serve fully-formed HTML from the server for
performance and SEO, but we want the speed and flexibility of
client-side application logic.
To this end, we’ve been experimenting at Airbnb with “Isomorphic
JavaScript” apps, which are JavaScript applications that can run both
on the client-side and the server-side.
So, I am a bit confused as to whether full-stack JavaScript frameworks render HTML files on the server or on the client. My most current educated guess is that some frameworks create HTML files exclusively on the client, some exclusively on the server and some are mixed. But which are which?
To be honest, it can get a little confusing. Especially if you just read about it and don't actually try it out.
I try to clarify it very quickly but if anything is unclear let me know :)
First thing first: What is Isomorphic JavaScript? Simplified it means that you use the very same code on front-end and back-end which is usually possible thanks Node.js (or the new fork iojs).
Now, until recently it was normal to deliver a more or less static html page to the client. Doesn't matter if the html is actually static on the server or the server creates it dynamically - the client just renders the HTML it gets.
With the new frameworks like Angular or React the approach is differently: You basically create the HTML dynamically on the client side and ask the server just for data. This means your server is in general just an (json) API!
However, some of the frameworks have an option to "pre-render" the html serverside which basically just means the initial request returns the proper html as we know it already and from there the clients takes over to manipulate the DOM again.
Usually you do that because you want a "single-page" Application that has more than one page. Single-Page just means you don't need to reload.
And the main reason you want that is because your webapp looks nicer on smartphones/tablets.
The aim is to get a "native" feeling even though it's "just" a website.
It has a few more advantages and obviously also quite a few disadvantages but if you're interested in them try to learn one of those frameworks and take it from there.
Angular.js is currently the "standard" framework that most people use - so can't really go wrong there.
I personally like React.js quite a bit but it's not as popular as Angular (yet?).
Some people even combine the two of them but you really need to know what you do to make that work in a way that makes sense so just go with one ->they both provide everything you need.
You can also have a look at Ember or Backbone but the concept is pretty similar to Angular and probably a little less complex but not as widely used.
Hope it's a little clearer now and I didn't make it even worse :)
I am facing a decision about the web application architecture I am going to work on.
We are a small team and actually I will work on it alone (everybody work on something else).
This application will consist of front-end build on the ExtJS library
and it will use the model "load page, build GUI and never refresh".
On the web "desktop" there will be a lot of data windows, map views (using openlayers + GeoExt) and other stuff.
GUI should be flexible and allow every user to modify (and persist) the layout to fit his/her needs.
It should be possible to divide the application into modules / parts / ... and then let users in specific groups use only the specific modules. In other words, each group of users
can have different GUI available on the web "desktop".
Questions are:
First of all, is this approach good?
There will be a lot of AJAX calls from clients,
may be this could be a problem.
How to handle code complexity on client side?
So far I have decided to use dojo.require / dojo.provide feature and divide the client side code into modules
(for production they will be put together using dojo build system)
I am thinking about to use kind of IoC container on client side, but not sure which one yet.
It is very likely that I will write one for myself, it should not be difficult in dynamic language like JavaScript.
How to handle AJAX calls on server ?
Should I use WCF on server side ? Or just ordinary ashx handler ?
How to handle code complexity on server side ?
I want to use Spring.NET. May be this approach could help with modularity problem.
Data access - here I am pretty sure what to use:
For DAL classes I will use nHibernate. Then I compose them with business classes using Spring.NET.
I would really appreciate some advice about which way to go.
I know about a lot of technologies, but I have used only little part of it.
I don't have time to explore all of them and be fine with the decision.
We do this type of single page interface where I work on a pretty large scale for our clients. (Our site is not an internet site)
This seems to work pretty well for us. The more js you have the more difficult it gets to maintain, so have as many automated js tests as you can and try to break up your js logic in an mvc fashion. 4.0 is supposed to make this much easier.
Ext 4.0 has this built in if you are trying to limit the code you bring down. If you have the same users day after day, then I think it would be best to just bring all the source down (compressed and minified) and cache it.
We've found asmx to work really well. I have nothing against wcf, but last I looked it seemed like more trouble than it was worth. I know they have made many improvements recently. asmx just works though (with a few request header changes and managing the "d." on the client side).
Our Server side data access layer is pretty complex, but the interface for the ajax calls is pretty simple. You have not really given enough info to answer this part. I would start as simple as possible and refactor often.
We are also using nHibernate. Works fine for us. We have built a DDD model around it. It can take a lot of work to get that right though (not sure if we have it right after months of working at it).
If I were you I'd start with just extjs, your web service technology, and nHibernte.
I would recommend ASP.NET MVC 3 with Razor instead of a lot Javascript and calls to Service you can just do ajax calls to an Action in a Controller and that will let you have more maintainable code and use a IoC like Ninject. EF instead of NHibernate.
But it's your decision.
I would look into using a tool like Google Closure Compiler, especially if you're dealing with a very large project. I don't have too much experience with ExtJS, but large projects in JavaScript are hard and something like Closure Compiler tends to make it easier.