There are a whole lot of new tutorials and examples popping up about this Isomorphic thing with react.js and how good it is.
For beginners like me, it is quite difficult to decide if this is needed or not.
Short example:
My application will be most of the time offline. The user will be able to create a questionnaire/survey and interview people who will answer this. After the questionnaire/survey is completed, he will need to call the node.js backend to download a Word document based on the answers.
So basically im asking if there is any reason creating an Isomorphic web application when it is a small simple and offline based?
Is there any simple node.js (express.js) + react.js + redux.js tutorial/exmplae out there which is not over complicated like the Isomorphic ones?
My true story, the suggestion is, the choice always follows the need.
when to use isomorphic infrastructure :
heavily SEO requirement, especially when u have to render same value in front-end & back-end.
global state management and business logic, relatively maintainable.
However, if you have an existed API or backend server (no matter nodejs or not) , the isomorphic could not be a better solution. BTW, You can just emit the backend codes in these isomorphic boilerplate (what I exactly do).
I recommend este
Related
I have a Back-end web application that provides me with custom API endpoints (Java - Spring). I like to keep everything separate. one API application that provides everything else remotely. My question is: What is the best practice to start a new Front-end project that connects to my API?
Requirements:
The Front-end project should be on a different server
The Front-end project should support routing, meaning I will have full control regarding the /paths. so no .extensions at the end.
SEO is very important in this specific case.
My preference is to go with React.js but I have doubts regarding SEO because the project I want to migrate from is WordPress (up and running with a good SEO performance).
I wish that I can find a simple solution with pure HTML, CSS and some kind of JavaScript.
Thank you.
React isn't actually bad for SEO. So long as you're taking the proper steps to ensure that the page load time isn't bad. If the site that you're migrating is massive, make sure you're lazy loading.
If you have doubts that Google or other search engines will render the js, then I suggest going with Nextjs like Rakesh K mentioned.
There's also nothing wrong with recreating the site with a templating language like Handlebars, then rendering it on an Express server, or whatever suits you. Just including this option in case you don't know React, and don't want to have to learn it.
My partner and I are building a project for a class this semester. I am currently doing research on what technologies we want to use. So far Springboot for the server side and MySQL or Postgres for the database are strong contenders. I wanted to ask if we should use React or even Angular for our frontend or should we just develop multiple JSP pages for our frontend? So far in my research I have not seen many people combine React and Springboot for projects and it makes me think perhaps I am combining two things not really meant to be combined. Can anybody assist us in deciding the tech stack?
Don't ever write server-side rendered user interfaces. Create a REST api for your backend so that you can have multiple clients querying such api: today, a web app written in angular or react, tomorrow maybe a mobile version.
It depends on so many factors. Some of them are the speed at which you want to finish the project and the quality of the project.
It is a good idea to learn at least one framework and Spring is a good fit.
Regarding the front end, JSP is not a good idea. Both Angular and React are fine as long as you want to learn and develop yourselves. Something in the middle, which may be a bit easier to digest would be Vue.js. Any of these would require a lot of time investment. Since you are already planning to learn Spring and Java then you may use a template engine to make your life easier, something like Thymeleaf. This is a bit old school but it may help you achieve faster results with what you already have.
You also have the option to go on the Javascript or Python directions.
There is no really good answer here, it all depends on what you know, what you want to learn, what you hope to achieve and, of course, the end result.
We are looking at options to build the front end of an application we are creating and are trying to evaluate a tool that will work for us and give us the best platform to move forward.
This is a Node.js project. Our initial plan was to use Express and go down that route, but we decided that before we kick off this stage it might be best to review what is out there. Our application has several areas which we don't believe fit the single-page model in that they are related from an application perspective, but not from a view one.
We have seen a few of the frameworks we could use to build out the client like Backbone.js, Meteor, etc. and also AngularJS.
This may be a fairly obvious question, but we cannot seem to decipher if AngularJS is purely for single-page application or it can be used for multi-page applications like Express for instance.
UPDATE 17 July 2013
Just to keep people in the loop, I will be updating this question as we go through the process. We are going to build everything together for now, and we will see how well that performs. We have reached out to a few people who are more qualified with AngularJS than us and posed the question regarding splitting up larger applications that share context, but may be too large working on a single page.
The consensus was that we could serve multiple static pages and create AngularJS applications that work with only those pages, effectively creating a collection of SPA and linking those applications together using standard linking. Now our use case is very specific as our solution has several applications, and as I said we are going to try the single code base first and optimise from there.
UPDATE 18 June 2016 The project fell of a cliff, so we never got round to getting too much done. We have picked it up again recently, but are no longer using angular and are using React instead. We are still using the architecture outlined in the previous update, where we use express and self contain apps, so for example, we have a /chat route in express that serves up our React chat app, we have another route /projects that serves up the projects app and so on. The way we are kinda looking at it is each app is an aggregate root in terms of its feature set, it needs to be able to standalone for it to be considered an app in itself. Technically, all the information is out there, its just basic express and whatever flavour of client side app building goodness you want to use.
Not at all. You can use Angular to build a variety of apps. Client-side routing is just a small piece of that.
You have a large list of features that will benefit you outside of client-side routing:
two-way binding
templating
currency formatting
pluralization
reusable controls
RESTful api handling
AJAX handling
modularization
dependency injection
It's crazy to think that all of that "could only be used in a single page app". Of course not.. that's like saying "Jquery is only for projects with animations".
If it fits your project, use it.
I struggled with the "how" at first with Angular as well. Then one day it dawned on me: "It is STILL javascript". There are a bunch of examples on the ins-and-outs of Angular (one of my favorites along with the book https://github.com/angular-app/angular-app). The biggest thing to remember is to load in the js files just like you would in any other project. All you have to do is make sure the different pages reference the correct Angular object (controller, view, etc.) and you are off and running. I hope this makes sense, but the answer was so simple I overlooked it.
Maybe my experience will be useful to someone. We split our project logically. One SPA we use for feed, another one to work with the map, another one for editing a user profile and etc. For example we have three apps: feed, user and map. I use it in the separated urls, like this:
https://host/feed/#/top/
https://host/user/#/edit/1/
https://host/map/favorites/#/add/
Each of these applications has it's own local routing mappings between states in the application.
I think it is a good practice because each application work only with its own context and load dependencies that it really need. Also, it's practice very good for debug and integration processes.
Indeed, you can very easily make a mix of SPA apps, for example the feed will be url with the angularjs application, the user app with the reactjs and map to the backbone.js application.
In response to your question:
Angular not just for SPAs, Angular play good and fast for SPA applications, but no one bothers to build MPA application of a variety of SPA applications. But thinking about your url architecture don`t forget about SEO availability of your applications.
I also support the idea:
What’s the difference between a project and an app? An app is a Web
application that does something – e.g., a Weblog system, a database of
public records or a simple poll app. A project is a collection of
configuration and apps for a particular website. A project can contain
multiple apps. An app can be in multiple projects.
If all you need is a few pages with client databinding, I'd go with Knockout and Javascript Namespacing.
Knockout is great, especially if you need uncomplicated backward compatibility and have fairly straight forward pages. If you're using 3rd party components, Knockout's custom bindings are straightforward and easy to work with.
Javascript namespacing allows you to keep your code separate and manageable.
var myCo = myCo || {};
myCo.page = {
init: function(){ ... },
...
}
And in a script tag after your other scripts are loaded
<script>
myCo.init();
</script>
The key is, you use whatever tool you want for when you need it. Need databinding? Knockout (or whatever you like). Need routing? sammy.js (or whatever you like).
Client code can be as simple or complicated as you want it. I tried integrating Angular into a very complicated site with an existing proprietary framework, and it was a nightmare. Angular is great if you're starting fresh, but it has a learning curve and locks you into a very tight workflow. If you don't follow it, your code can get really tangled really fast.
I'd say Angular is overkill if you're just looking to develop a SPA. Sure, if you're already comfortable developing with it, go ahead. But if you're new to the framework and only need to develop a SPA, I'd go with something more simple with a number of its own perks. I recommend looking into Vue.js or Aurelia.io.
Vue.js uses two-way data binding, MVVM, reusable components, simple and quick to pickup, less code to write, etc. It combines some of the best features of Angular and React.
Aurelia.io, in all honesty, I don't know much about. But I've peeked around and it seems an alternative worth looking into, similar to the above.
Links:
https://vuejs.org/
http://aurelia.io/
We are looking at options to build the front end of an application we are creating and are trying to evaluate a tool that will work for us and give us the best platform to move forward.
This is a Node.js project. Our initial plan was to use Express and go down that route, but we decided that before we kick off this stage it might be best to review what is out there. Our application has several areas which we don't believe fit the single-page model in that they are related from an application perspective, but not from a view one.
We have seen a few of the frameworks we could use to build out the client like Backbone.js, Meteor, etc. and also AngularJS.
This may be a fairly obvious question, but we cannot seem to decipher if AngularJS is purely for single-page application or it can be used for multi-page applications like Express for instance.
UPDATE 17 July 2013
Just to keep people in the loop, I will be updating this question as we go through the process. We are going to build everything together for now, and we will see how well that performs. We have reached out to a few people who are more qualified with AngularJS than us and posed the question regarding splitting up larger applications that share context, but may be too large working on a single page.
The consensus was that we could serve multiple static pages and create AngularJS applications that work with only those pages, effectively creating a collection of SPA and linking those applications together using standard linking. Now our use case is very specific as our solution has several applications, and as I said we are going to try the single code base first and optimise from there.
UPDATE 18 June 2016 The project fell of a cliff, so we never got round to getting too much done. We have picked it up again recently, but are no longer using angular and are using React instead. We are still using the architecture outlined in the previous update, where we use express and self contain apps, so for example, we have a /chat route in express that serves up our React chat app, we have another route /projects that serves up the projects app and so on. The way we are kinda looking at it is each app is an aggregate root in terms of its feature set, it needs to be able to standalone for it to be considered an app in itself. Technically, all the information is out there, its just basic express and whatever flavour of client side app building goodness you want to use.
Not at all. You can use Angular to build a variety of apps. Client-side routing is just a small piece of that.
You have a large list of features that will benefit you outside of client-side routing:
two-way binding
templating
currency formatting
pluralization
reusable controls
RESTful api handling
AJAX handling
modularization
dependency injection
It's crazy to think that all of that "could only be used in a single page app". Of course not.. that's like saying "Jquery is only for projects with animations".
If it fits your project, use it.
I struggled with the "how" at first with Angular as well. Then one day it dawned on me: "It is STILL javascript". There are a bunch of examples on the ins-and-outs of Angular (one of my favorites along with the book https://github.com/angular-app/angular-app). The biggest thing to remember is to load in the js files just like you would in any other project. All you have to do is make sure the different pages reference the correct Angular object (controller, view, etc.) and you are off and running. I hope this makes sense, but the answer was so simple I overlooked it.
Maybe my experience will be useful to someone. We split our project logically. One SPA we use for feed, another one to work with the map, another one for editing a user profile and etc. For example we have three apps: feed, user and map. I use it in the separated urls, like this:
https://host/feed/#/top/
https://host/user/#/edit/1/
https://host/map/favorites/#/add/
Each of these applications has it's own local routing mappings between states in the application.
I think it is a good practice because each application work only with its own context and load dependencies that it really need. Also, it's practice very good for debug and integration processes.
Indeed, you can very easily make a mix of SPA apps, for example the feed will be url with the angularjs application, the user app with the reactjs and map to the backbone.js application.
In response to your question:
Angular not just for SPAs, Angular play good and fast for SPA applications, but no one bothers to build MPA application of a variety of SPA applications. But thinking about your url architecture don`t forget about SEO availability of your applications.
I also support the idea:
What’s the difference between a project and an app? An app is a Web
application that does something – e.g., a Weblog system, a database of
public records or a simple poll app. A project is a collection of
configuration and apps for a particular website. A project can contain
multiple apps. An app can be in multiple projects.
If all you need is a few pages with client databinding, I'd go with Knockout and Javascript Namespacing.
Knockout is great, especially if you need uncomplicated backward compatibility and have fairly straight forward pages. If you're using 3rd party components, Knockout's custom bindings are straightforward and easy to work with.
Javascript namespacing allows you to keep your code separate and manageable.
var myCo = myCo || {};
myCo.page = {
init: function(){ ... },
...
}
And in a script tag after your other scripts are loaded
<script>
myCo.init();
</script>
The key is, you use whatever tool you want for when you need it. Need databinding? Knockout (or whatever you like). Need routing? sammy.js (or whatever you like).
Client code can be as simple or complicated as you want it. I tried integrating Angular into a very complicated site with an existing proprietary framework, and it was a nightmare. Angular is great if you're starting fresh, but it has a learning curve and locks you into a very tight workflow. If you don't follow it, your code can get really tangled really fast.
I'd say Angular is overkill if you're just looking to develop a SPA. Sure, if you're already comfortable developing with it, go ahead. But if you're new to the framework and only need to develop a SPA, I'd go with something more simple with a number of its own perks. I recommend looking into Vue.js or Aurelia.io.
Vue.js uses two-way data binding, MVVM, reusable components, simple and quick to pickup, less code to write, etc. It combines some of the best features of Angular and React.
Aurelia.io, in all honesty, I don't know much about. But I've peeked around and it seems an alternative worth looking into, similar to the above.
Links:
https://vuejs.org/
http://aurelia.io/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm building a large scale web application. It will grow in the future so I need a good back-end and front-end architecture for my application. at the back of the site, I use Zend Framework so the architecture is OK for me. But at the front, working with javascript and ajax without having a good architecture makes later changes hard and confusing.
For now, I'm using my own architecture. I have a big object for the whole application say BigObject. I extend it when modules are added to the site. say I have an upload module. I use this:
BigObject.upload={
//initialization
init:function(){
},
//I tried to use what I named semi-MVC architecture!!!
controllers:{
//index is a controller
someController:{
init:function(){
//initialization
},
someAction:function(){
//Code goes here
//call a model if necessary
//call view script
BigObject.upload.views.someController.someAction();
}
}
},
models:{
//models required for this module like loading contents with ajax.
loadContent:function(part,callback){
}
}
views:{
init:function(){
//initialize view
},
someController:{
someAction:function(){
}
}
}
}
What do you think? Is there any better solution to this problem? anyone thought about a good structure for front-end part of web applications ( like what we have at back-end,good file structure and object-oriented methods )?
The most up to date answer to this question in 2020, would be to use React + GraphQL + Styled-Components. The best place to start with React is the official Create React App tool. Their are a few different implementations of GraphQL; on the client side the clear leader is Apollo. On the server you have a lot more choice and it is reasonably easy to even roll your own server implementation, so go with what work best with your current backend. Styled-Components gives you CSS in JS, in the same way that React gives you HTML in JS.
For a more complete and opinionated experience, take a look at Gatsby, which brings all of the above into a single framework.
Over the last couple of years a more functional style to writing JavaScript has become popular. If your not used to functional programming then it can be a bit of a steep learning curve to start with, but start by leaning about a library called Ramda.
Here are few links to get you started on functional JS
An introduction to functional programming in JavaScript
Thinking in Ramda
Indentation is the enemy: Writing less complex JavaScript
Mostly Adéquate guide to functional programming
When it comes to testing, then Jest combined with Enzyme is by far the best current option.
Finally for a much deeper answer, checkout this talk from Cheng Lou on the Spectrum of Abstraction.
Most of the answers are proposing stuff like jQuery, React, Angular, Vue.js... which are not frameworks, neither architectures. All of these libraries are layers on top of JavaScript. I just remind you that JavaScript is already a high level language!
Since the question is about a good client-side architecture and structure for large scale web applications, I would say that none of the previous answer solve the problem, and there is a reason for that :
There is currently no emerging or commonly accepted architecture for front-end JavaScript source code organization.
I already read dozen of blog posts, Stackoverflow questions, Youtube videos... I never found someone who detailed a generic, general and scalable architecture. The main reasons are:
front-end JS code is quite small regarding back-end source code, most of the developers do not need a scalable architecture.
execution is ephemeral, lifetime of JS is the same as web pages lifetime.
the problem for many developers is more about manipulating the DOM than structuring large JS code. This is why people answers are about libraries rather than frameworks.
I really expect that some day, someone will propose the first real JS architecture (like MVC for example). But in my opinion, this architecture will be more about event-callback than MVC. Before concluding, I'll suggest you the following ressources:
Imperative or procedural programming.
Functionnal programming (probably the best lead with modules)
Awesome videos of Fun Fun Function
JavaScript modules
To conclude, I'll strongly recommend to consider JS modules that have a great underestimated potential. This is not exactly an architecture, but:
JS modules organise your code
JS modules are scalable
maintanability is easy
JS module are reusable
Previous list isn't the main reasons why you need to organize your code?
Word to the wise!
A lot of people push for either Dojo or YUI for large applications. They are honest frameworks where most everything else you'll find is a library.
Personally, I tend to stick with jQuery. I create jQuery plugins or jQueryUI Widgets as needed. I've managed to push jQueryUI pretty far.
Everything falls in either $.fn.myPlugin or $.ui.myWidget. To me, this has the added benefit of pushing you to keep code very modular and portable (assuming you abide by jQuery/jQueryUI conventions).
$(element).myWidget({
color:'eggplant',
someValue:42
});
$.upload(args);
I was actually struggling with the same question for sometime.. after doing few large-scale projects, I thought of sharing my learnings as a reference architecture incase someone else finds it useful.
Have a look at http://boilerplatejs.org. It is not a library, but a framework that integrates some industry leading libraries with architectural patterns for large scale javascript development.
According to my understanding on the frontend i will ask you to use web-components that uses only HTML,CSS and JS.
No need to spend much time on understanding the other languages. If you take the latest UI frameworks or libraries like Angular, React they have built on web components.
You can customize your own components and use cases which you want to use in your project.When you are using frameworks it will take some time to load and follow up for few libs that are using.
JS you can use it any way you want. You can re-use these components in any number of projects once you have created.
Just look into webcomponents https://www.webcomponents.org/introduction you will get a clear idea. I hope this helps.
With the experience of scaling some of my content for million viewers in my application. But then I had to close the application for less profit and more stress in managing it (not the cost though, but the profit was not high enough to keep up motivation)
My architecture was:
Mithril.js.org library - Checkout mithril here for front-end
Twitter bootstrap front-end framework
Backend with "Laravel and started migrating some of the heavy write data to nodejs"
Redis as in-memory storage.
I was almost in a situation to move my storage to s3 before I shut down the app.
No jQuery - I kept my app jQuery-free ( I heard and read somewhere big app avoid jQuery, so without further investigation myself, I planned to remain jQuery-free as well, though I have no solid or bullet proof reason to avoid jquery)
I found mithril more interesting then react or angular, it was so easy to start and I was building while I was learning, it was damn easy and they claim, they are better than react, vue and angular in terms of size and performance.
My response would be to ask why you need this? I've worked on plenty of applications which make use of javascript, but one thing that I've learnt is that the best thing to do is to minimise javascript and most especially object orientated javascript to an absolute minimum. Web pages with large and complicated javascript tend to be slow, memory hungry and a pain to debug with all the browser variations.