I stumbled upon google's material design web components ("https://material.io/") and would like to implement it in my projects. The only problem is that I've never used a javascript frontend before.
Note: Google's Material Design is the successor of Material Design Lite.
I received a recommendation to learn angular and implement Google's material design components through angular and have my frontend (angular) communicate with my backend (django) through an API.
1- Is this really the best way to proceed if only the web components are needed? Can we not just import the CSS and JS like we did with bootstrap and use Django/jinja to render views?
2- It seems like node.js / NPM is required to use angular and Google's material design, however, is that just during development? Or will we face complications when trying to deploy a django backend and javascript front end?
You can certainly separate your frontend and backend, but I don't think that's necessary in this case. You can definitely import your needed JS and CSS without separating the two, (just make sure that you have them in your base template so that they're accessible to all pages). All you need is a CDN. If you want to use raw SCSS as mentioned in the webpage you linked, you can always use Django scss https://github.com/jrief/django-sass-processor
Onto your second question. Node.js is essentially a platform so that Javascript can run on a server as a backend , as opposed to in a browser. Angular is a frontend framework (just like Django is for python). You don't need node.js to use angular.
NPM (node package manager) is a javascript package manager for node.js, just like pip is a package manager for python. It's not necessary if you're not using node.js.
I don't see anything that would suggest that splitting frontend and backend is necessary for using material design, so you should definitely be either to do so either way. Entirely up to you.
Related
In the last few years, I’ve been working with an old fashioned stack, but pretty effective for my use case. The stack was Node + Express.js + Angular.js 1.x.
Basically, the backend made the rendering of the view (via dot.js or Handlebars, any template engine) and then, in the Frontend side, the Angular app was mounted.
The use case needed to be SEO friendly, so the content must be generated at the backend and served directly. Also, the UI has its functionality, forms, etc. It’s not just dummy text.
Currently for a new project with the same use case, I want to update my stack (using SSR aka server side rendering) where the app does not need to be a SPA (single web app). The base stack is still the same (Node + Express.js) and the only thing I want to update is the frontend library / framework.
I am looking for a framework / library with a big community and an easy way to share component and codebase across project. That’s why my first thought was React.
The first thing I found was Next.js and while I was reading and investigating, it goes beyond what I need. It is a quite big framework that has too much stuff I don’t need and I do not want to add overhead to my application and I cannot customize it as I desire.
I continue researching and I found an express package called "express-react-views" that is a template engine for express but it does not allow to mount the React application at the client side.
Browsing through the Github issues of the package, I found many people asking for these and they all end up being answered that Next.js was the way to go.
My doubts / concerns are the following:
Is React the right tool / library for this use case?
In case of not being, what do you recommend?
Being the right one, is there any package / tool on top of React and Express that helps me out with SSR that allows me the customization I need?
I don’t want to rely again in old or antique tools like jQuery or Angular.js 1.x because the maintenance and code sharing across projects is complex and annoying.
The easiest solution, without going deeply into Next.js, is using the native React feature ReactDOMServer:
https://reactjs.org/docs/react-dom-server.html#reference
It's actually pretty easy to use, you just serve the HTML as a string and mount your React App Client Side if you want then to handle requests with React Router.
As the title says I'm dealing with Spring Boot and react JavaScript at the moment. I would really appreciate it if someone would be able to answer me on a few small questions.
I created a separate react project using vscode IDE. Now I need to add it to my Spring Boot application. I have used Eclipse to code my Spring Boot application.Can I just transfer the react JavaScript files to the Eclipse IDE? Will it work like that?
Also, to configure these two together I read that I should use thymeleaf. What are you thoughts on this and do you think its better to use this.
You may not require to transfer any code from one IDE to another. I assume both this front-end(react) and middle layer(spring boot) are two separate project.
You can still run the boot project in eclipse pointing to same localhost(for development) with a different port and front-end in a different port.
I found this example is quite useful
The modern way to think about your React and Spring apps as of two completely separate applications. The React app is the "front end" application that is displayed to the user and holds the logic for all the user interactions. Spring boot is the "back end" service that holds the state of your application and helps you to save and fetch data.
To get started try building and running your React app from something like Create React App. It is easy to set up a local development server. You should also understand that the React app that you get after building is just some static files - so you can host them very easily and cheaply without need for an actual server. I personally use S3.
Now to your Spring application. This is your 'API' layer and you should read about using APIs for example here: Official Spring Docs .
You still theoretically CAN bundle both together and serve the React bundle out of the Spring static files directory but you will likely find this will get awkward fast. Here is an example of someone doing exactly this
As for Thymeleaf - in the React world you will likely end up using JSX for your templating needs. It is a wonderful way of closely integrating your js and html code and creating highly reusable components.
You can build an automated container deployment. This allows you to test, build and deploy your backend and frontend with every git push to your server.
For example google some keywords: Kubernetes, Docker, Gitlab CI.
There are much more solutions and platforms to build a system for automating deployment.
Stumbled accross NextJS in npm and tried it out. Look pretty good and relatively easy to use. However, one thing about it is still not clear to me:
Suppose I want to have also have a NodeJS (or whatever) api server in complement with the server side rendering that NextJS offers. Do I need 2 server then? For example:
Also is NextJS just a rendering server (which can render React components and creates HTML) or something else/more?
You can definitely use the same server to implement your api.
On official documentation page about Custom server and routing there are examples of integrating with popular node frameworks like express or koa - so you can use them for regular purposes.
What about nextjs itself - like it's said on official documentation page:
Next.js is a minimalistic framework for server-rendered React
applications.
So it has not only capabilities of server side rendering, but also routing (including client one), css-in-js setup and so on.
Our entire codebase is built on just express, we want to build it out and in the process convert it to a single page application. As of now I am opposed to rewriting the code to work with a framework like Angular, or React, to accomplish this.
Thanks for reading.
Are you sure a SPA web application is what you really want to achieve?
If you are, then the answer is Yes: you don't need a framework for any SPA or any other frontend purposes.
A SPA usually consists of following parts:
Client side routing (eg HTML history mode)
Client side templating (see Smashing Magazine article for some examples)
Retrieving the data (eg via Fetch API or Axios
So, using these technologies, regardless of your backend technology, you can create a SPA with Vanilla JS. Actually, what you use at your backend has little to no affect on your SPA.
However, depending on how big your application is or how much features you need, you might end up using one. Frontend frameworks are designed to make your life easier.
If you are looking for a framework with an easy learning curve, I strongly suggest Vue.js. You can even get started without installing or transpiling anything locally.
yes, you can - depending on the complexity of your application you may end up transitioning to React, Angular, or another frontend framework in the future depending on your needs.
here are some resources:
https://tutorialzine.com/2015/02/single-page-app-without-a-framework
Todo in different frameworks (for comparison):
http://todomvc.com/
Angular vs Vue vs React:
https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176
If you're going for a real single page application you should be able to continue to use express. You'll find yourself jumping through some hoops though and using React/Angular would be a better approach because of how you could move forward with it in the future with no limitations.
I am a Ruby on Rails developer. Now I've just started with Reactjs. I am really new to this front-end framework. I wonder that should I write all my .html file to .js.jsx file?
I see in rails there are many view helpers such as form, nested form, pagination, .... But if I move to Reactjs, do I have to rewrite these in javascript?
Paginate is too simple in rails with gem will_paginate, but maybe too complex to rewrite in Reactjs.
These all what I wonder should I use reactjs? what are the advantages?
How to use Reactjs in suitable way?
I really like to separate front-end and back-end projects:
Two developers with different skills can work together (you don't need full-stack developers)
You can change your front-end/back-end framework easily
Your code will be really clean
You can have same back-end for all front-ends (web, android, iOS, ...)
You can develop them as separate project and you don't need to wait for rials development. You can go with API dummy sever.
With integration of react and rails maybe you will be fast at first but you won't be scalable as much as separate one.