I'm working on the first production release of a large site developed in PHP (Phalcon), MySQL & JQuery. It's not API based although there will be an API available for some things. The slightly dated stack is due to the fact that the project was first prototyped years ago and for reasons I won't bore you with, it's taken years to get to the production development stage.
I realise that hard page reloads are so last year, but they also make sense in an application of this scale when navigating to a different section that serves a different purpose. As it works at the moment, once you get to a section, it pretty much behaves like a single page app using hashed URLs and ajax to change the content in one or more containers etc. especially where SEO is not an issue. This is all currently done with JQuery which is starting to get a bit messy and unmaintainable. There's also features such as notifications in the nav bar etc that appear on every page on the site, again updated and displayed via ajax.
My expertise is in PHP. The same can not be said for Javascript! But it's clear that JQuery alone is not enough. I need a JS framework to handle templating/binding, local routing to a reasonable depth and http etc. with an MV..? structure to better organise the JS side of things and keep it maintainable. I greatly disliked Angular 1 and quit learning it as soon as I found out that Angular 2 was about to come along with major breaking changes. I tried Angular 2 beta and although better, it just doesn't float my boat. I had previously stumbled upon Aurelia alpha and although I didn't have a chance to play with it, watching the vids and reading about it, it seemed like a very nice bit of gear - nice syntax, designed for the present and the future and so on. Now at version 1 beta there's more documentation and resources available to learn it, and I feel fairly comfortable jumping aboard early and using it in this project.
I'm pretty much aware of what Aurelia can do, and I have a lot to learn. However, my big stumbling block at the moment is figuring out how to structure it and incorporate it into this project.
Integration
Each section of the site will need different Aurelia apps
Multiple Aurelia apps may be needed per page
Some Aurelia apps will be required on all pages
I found an article by Patrick Walters which seemed to explain how this could be done by naming the app when you call it on the element;
<body aurelia-app="main" start="app">
Then setting up a shared main.js with;
aurelia.start().then(a => {
let start = a.host.attributes.start.value;
a.setRoot(start);
});
That seemed to make sense so I tried it, but placing the call in a div instead of the body. That doesn't work as host can not be resolved to anything (my IDE told me that before I even ran it). We don't need hostname/port info here, so I presume the author means to replace host with the element? But how exactly?
Any further advice on integration like this would be much appreciated.
I have seen answers to similar questions on SO, but they do not seem to reuse main.js but duplicate it instead which doesn't seem right.
Structure
I played around with moving files with src to subdirectories to split things up into some clear structure. The only way I could get that to work was to add a named path for each in the config e.g. "welcome*": "dist/welcome/welcome*",. Is that the best/only way?
I don't think there is a right answer for your question. Only you are capable to decide which strategy fits better in your situation. As far as I can see, you can achieve this strategy with Aurelia. However, I'm not sure about the reusage of main.js.
You can load an aurelia app inside an specific tag using:
aurelia.start().then(() => aurelia.setRoot('my-root', document.getElementById('some-element'));
If you want to load more than one app in the same page, you'd need 2 main.js files. This thread Multiple Aurelia apps on one page has a very useful example of two apps in the same page.
In my understanding, apps that share the same page should have one project structure, it means only one config.js, src folder, dist folder, etc. Apps that do not share the same page should have a different project structure, with a different config.js, src folder, dist folder (a different Aurelia version if necessary). That guarantees the independence of one app to another, preventing breaking changes.
Of course, that is only my opinion. You can wait for the aurelia guys for further instructions, they are always around.
Hope this helps!
Related
Imagine you are developing a big-scale nuxt app that has 100 routes. what is the best solution for managing routes (not micro-frontend) in this app?
What do you mean by this?
or should add all of them in pages directory?`
Here, we're talking about pages only, right? So /user/id, /post/id and so on?
If it's the case, you could have a /_entity/id or even a /_entity/_slug for more flexibility (with _entity being either user or post etc...).
If you have a lot of various pages like /about, /our-team, /careers and so on, I guess that those will need their own SEO, content and are totally legit.
I don't really see why this would be an issue at all. It will be properly organized, scalable and will not have too much abstraction neither (which is important IMO).
You could also export some of those pages into .md files thanks to nuxt/content and import them into the pages. Like the Nuxt documentation is doing.
If you really need to simplify those, yeah you could make the whole templates dynamic and generate the markup on fly. This could introduce some huge complexity that may not be needed IMO.
Also, layouts, slots and render functions can be a solution too I guess.
I'm not sure if micro-frontends (sounds like a buzz word for me) are actually several instances on Nuxt one next to another (sounds like a terrible idea if hosted under the same domain) or just "component-ization" of your non monolithic fullstack app (pretty much how we build websites for few years already).
But for me, if a project do have 100 pages, it is totally fine.
Of course, having some hardcoded /blog/post/1, /blog/post/2 is bad (lol) but a large app could be totally fine. It may create some issues regarding the build time and so on, but this is another subject and relies more of the way you do generate the project.
So yeah, if your interviewer wanted to go deeper than those approaches, you would need more details from him to exactly know what are the challenges and what could be used.
TLDR: as far as I know, no frameworks aim to reduce the number of pages because this is not an issue by itself. 10k Nuxt pages will not make your /about one slower by any means (if it does, the issue is elsewhere).
This question already has answers here:
How to get Django and ReactJS to work together?
(8 answers)
Closed 1 year ago.
I am making a full stack website using react and django. I came across various ways to integrate them both. Having them both as two separate projects and interacting using API, or putting react in the django folder and calling the backend. Which method would be better and much easier? And can you also mention the pros and cons of each method.
Well, it's actually quite easy, you just have to wrap your head around which part of your project handles which concern.
The "project management" part of the question
Having them in the same repo
This is a good idea for deployment, as you won't have problems of synchronization between the 2 code-bases, however, with increasing number of developers it can potentially lead to management problems, as you're have branches based on both backend and frontend things.
So to summarize:
Easier to deploy, since it's a single code base
Could lead to potential problematic management with scaling the development team
Makes task that are "full-stack" easier to manage, as you have it in a single code-base
Not so easy to split if you're aiming to scale separate "frontend" and "backend" teams
Having them in different repos
In contrast, this makes it harder to deploy, but easier to separate the tasks. You have 2 separate projects to maintain, an "API" and a "front-end". Depending on the way you set this up, you can even serve your front-end project using a CDN, and this opens doors to some modern stacks, like serverless, or you can deploy on Vercel, which has a free plan. All-in-all this is usually a safer option for larger teams.
So to summarize:
A bit harder to deploy, manage staging
Easier task sub-splitting between the teams
The "engineering" part of the question
In regards to the engineering part, React has to be "transpiled", which means that the browsers don't know how to "interpret" it. That means you'll have to pick one of various bundlers, but I can suggest a few popular ones:
Webpack custom made config
Create React App (comes with webpack)
Parcel (0 config)
Snowpack ( I've heard great things about this one, since it's node_modules "free"
Once you have this, you'll have a way to get "production" ready compiled javascript/css assets which you need to serve to your user. Depending on what you went with on the "project management" side of things, you can either serve the assets with one-click solutions, or a CDN, or in fact, merge your front-end project with the backend, and build your assets, and serve them with Django itself.
The choice depends on what you want to achieve, but to summarize:
Serving with django - You'll only have a single server to handle everything, but that means if you plan your site to be globally available, you'll have think about the infrastructure
Serving with one-click solutions or CDNs, and a separate API - Pick this if you plan to have a fast loading site everywhere in the world, makes it a bit easier to scale
All-in-all this is kinda a complex topic, but if you're just making a startup or a small project for yourself to play with, I suggest you go with simply serving everything with Django, and keeping everything in a single codebase!
I am helping to design a HTML client for a game that I am collaborating with others on.
This client is going to need to have multiple scenes/pages like the login, the lobby, the actual game page, etc.
Normally, I would be just fine with navigating in and out of pages. However, the client needs to have a constant connection with the server via a Websocket, so therefore it cannot navigate away from the page.
Option 1: Put everything in one file
Rather than having each scene in its own separate page, just cram all the HTML together.
Then, when one scene is needed, simply hide all the other scenes.
I do not think that this way is the way to go: from what I know about HTML and web practices, this is not a very smart practice.
Option 2: jQuery's .load()
Using jQuery's handy-dandy .load method, an external HTML file can be easily loaded into the current HTML file.
To me, this seems that this might be the best way. However, I am not very familiar with how this method acts, so I do not know if this will cause bumps in the road ahead.
Option 3: ???
This is where I need help. Unless one of the two above options is the best way, what is the best option for my situation?
Notes
I am not looking for speed here; it's okay if there is some delay between loads.
Not sure about your backend but it seems like you are looking for a single page app solution.
I recommend AngularJS, currently maintained by Google.
Others have mentioned Angular, but I'll just throw out the recommendation of KnockoutJS as well. Knockout has a less steep learning curve than AngularJS, and though it doesn't have as many features as Angular does, the latest version does have better browser support.
Both Knockout and Angular have excellent documentation and tutorials available via their websites.
I would recommend Angular 2. Since you seem like a beginner in front-end (correct me if I am wrong), starting with Angular 2 would be great over 1 because then you can learn this really good JS framework only once. It will help you keep everything organized and will prevent you from making your markup messy.
I have been using JavaScript and jQuery for quite a while now and want to extend my skill set further, during my search I came across two popular names Angular and Backbone and while reading about them I found one line common in both them which somehow also seems to be their USP i.e.
It is designed for developing single-page web applications
This makes my confused.
What is that I cannot do with JS or jQuery and I would require these?
I have created web application on single page, where users can perform CRUD operations on single page through asynchronous calls so why so much importance of for these others libraries?
And as a middle level web developer who has have good hands on JS is it right path to move to these two or here is something else I should look into before these?
Please help?
Structure.
In an ongoing project that started about 4 years ago we built the front end with jQuery. We were able to do just about everything that we needed creating several single page applications that were quite functional.
As the project progressed and the code base grew we started experiencing some major problems with maintainability of the code. We ended up with hundreds or thousands of lines of JavaScript code per page in a tangle that was almost impossible to navigate. This could have been avoided if we were more careful of course but at the time we focused on making sure the back end architecture was robust.
Many years ago the community learned that code needs structure to be maintainable. We developed MVC patterns, multi-tiered applications etc. But JavaScript was never a big player in the field and we largely ignored it.
Over the last 6 months or so we introduced Angular into the project and started sorting out some of the mess in the project. The results are remarkable. Not only is the code simpler and easier to create, the structure makes it easier to implement tests, easier to maintain and generally a huge improvement over what we had before. We still use jQuery but now we have been burnt by the lack of structure and know a thing or two about the architecture of a JavaScript application. Angular and its like provide you with the tools to architect a good application.
When you are creating larger scale web applications it is wise to check out Backbone, Angular or perhaps Meteor. jQuery supports neat tricks, but it does not help you structure your code in a maintainable way. Larger scale web apps build on jQuery need their own vision on how to separate the code into layers with their own responsibility.
The other frameworks give more support.
I would suggest checking out at least one of the libraries. Perhaps you eventually won't use them, but it will benefit how you work in jQuery.
Well Now a days there has been quite a hype about Angular.js and especially SPAs (Single Page Applications). Well to be honest, I had the same question in my mind about a month ago when my team decided to shift from Jquery to Angular.
Whenever it comes to Jquery, one of the first thing that comes in our mind is the DOM manipulation. While using Jquery we always think of manipulating the DOM. Show/hide elements, animating elements, getting data from tags you name it. But Angular offers something more than that. It offers you an architecture, a way to structure your applications at the front end.
So whenever you go for Angular.js, change the way you think about creating web applications (and believe me its worth it). Most of Angular's structure uses the concept of Dependency Injection which is a neat way to maintain your code.
Backbone is only a library whereas Angular.js is a complete framework to create and manage Single Page Applications
Talking about the fact that Angular.js should be used when we are creating large scalable apps, it is true. In my case the team I work with is full of Jquery Ninjas. We have been creating a great app for the last 3 years and believe me it became difficult for us to maintain and debug thousands of lines of Jquery. This is the main reason we have decided to revamp this app into Angular.
Kindly see some of these Helpful links. You will get a better idea.
http://net.tutsplus.com/tutorials/javascript-ajax/3-reasons-to-choose-angularjs-for-your-next-project/
"Thinking in AngularJS" if I have a jQuery background?
which of following cases is strongest with regard to client side (JavaScript) library referencing and loading.
Please note that I assume the web solution is well designed so that the components are well encapsulated
Also, just to be clear, the master page I am talking about could be a user control or anything that holds all library references and loaded at the site-load regardless of the content of the site at the moment
1 - include references (link href) for all custom (e.g. 3rd party) libraries in the master page.
it's arguable this is easy to maintain because all references are in one place.
it's also arguable that it's easy to perform library upgrades so you don't need to hunt within the solution where the library is referred to update it's reference.
2 - include reference to libraries in their specific user controls
shouldn't this improve performance as the website only loads libraries when required.
e.g. one can refer to the JavaScript libraries that works for maps within the user control that deals with maps with contrast to loading maps libraries even when there's no map on the current view.
This encapsulates components well. for example, a developer who tries to fix a bug in the map component will see all the libraries it refers to when he opens the map user control. This stops the need to go through the master page and see which libraries are used.
I don't think this is the right way to think about it.
The only reason not to load all libraries is performance. The debug reason you give is too minor to consider.
You can increase performance in many different ways. By far the easiest, most straightforward and attainable is to minify all your JavaScript into one file. You can additionally use a compiler like Google's Closure Compiler or Yahoo YUI Compressor to get a smaller filesize and faster execution.
If at this point you still have performance issues (that can be attributed to network latency) then maybe look into lazy loading your libraries.
This doesn't mean you should forgo the guidelines of dependency injection. Any good framework will offer you a mechanism for dependency injection. This should make switching to solution 2 at a later point fairly trivial.