Develop Reference

Thymeleaf or Angular4 with Springboot

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!

jQuery alternatives for multiplayer games?

First off, I am not asking for any code or anything like that.
all I need is some advise.
I'm creating a roulette game and everything in my roulette game is based on jQuery.
however, as we all know, jQuery is client side so I was thinking about using AJAX to send some details back to server and from the server to the users browser so I can make this roulette game work in "multiplayer" fashion... But the issue is that I don't think its possible to send the roulette's wheel animation to the server and back to users browser so I am a bit confused about this!
In my research I came across some information (old ones) about using node.js and jquery together! I don't know if this is possible or how easy it would be to use my jquery code in node.js as I have never used node.js before..
so the question that i have is:
based on the information i provided above and my requirements, what are my options?
can I use AJAX to achieve what i am trying to do and if so, a bit
information would be great.
if AJAX is out of question, is it possible to use my jquery code in
node.js to achieve what I am trying to do?
ANY ADVISE WOULD BE APPRECIATED.
P.S. I don't want to use HTML5 as 1st I don't know much about HTML5 and also, some devices, browsers do not support it.
Thanks

The best way is to use websockets to ensure real time communication. One of the best alternatives for implementing that could be using a server under node.js. Have a look to this video from Code School node.js tutorials: https://www.youtube.com/watch?v=mtDK4jf4RS0 where is ilustrated how to implement a real time chat. Your problem is based on the same.

There are three parts to a multiplayer game displayed in a browser:
client-side display,
server-side data management,
client-server communication.
If you're already set on your display technology (jQuery), then you're probably going to use $.ajax() for client-server communication. However, technologies used for server-side data management are completely up to you and they don't necessarily have any connection to the technologies used for display and communication (meaning the traditional communication initiated by client).
Basically, use any kind of server technology stack you like. Node.js might do just fine but there are many other viable alternatives. They just need to support communication with the client.
So, to be absolutely clear, your question doesn't really make sense. You might use jQuery in the client and Node.js on the server, but they will never really "work together". They will manage completely separate parts of your application and connect through protocols not specific to either of them.
As for the animation, the animation itself is solely a client-side problem. If you want to "synchronize the animation" across multiple clients, you can let the clients communicate with the server, but they only ever need to send/receive plain data. Then you adjust the client-side animation based on the received data.
As another poster points out, websockets are a better fit for this than regular client-initiated HTTP requests. Not because of "the animation", but because you want all the clients to receive the information about the start of betting at the same time.

I am also developing a MMO game using javascript only. Firstly, there are two different types of javascript here. Usual client side javascript (the one you already know) and the server side javascript (i.e. Node.js).
You will need to develop both client and server before connecting them with jQuery's Ajax. So you need to study Node.js before designing overall architecture of your game.
I read many Node.js tutorials and watched many youtube tutorial videos but I was still confused, before I really sat down and read a good textbook that explained from basics, one like below. Try to get hold of it from your local library.
Express web application development learn how to develop web applications with the Express framework from scratch by Hage Yaapa
Express is the popular framework that runs on Node.js now. So it's worth getting familiar with Express Framework. Once you understand how express app works (not so difficult), you will see how you can frame your game structure like I did :)
In order for many clients to share same animation, there must a server that synchronizes the game state. Ajax can only link between server-client communication in my understanding. There is no mechanism that connects between clients. The clients ask server what number was the result of roulette roll and show the corresponding animations.

Yes, you can use NodeJS and jQuery together.
NodeJS is server-side, meaning that you set up a server (a lot of people use the Express module, which is easy to use), which serves content to clients asking for it. Your server-side code can be in any language supporting sockets, not just NodeJS. But NodeJS is easy to use if you know JS already.
jQuery is client-side, meaning that it's executed by the user's browser, and may or may not have a server-side component (if it doesn't need it), or it might have one where it sends requests to the server-side code. When it requests a page from the server, it can be static content (like when you request index.html) or dynamic via an AJAX request. Client-side browser code must be HTML/CSS/JS (you can't make Firefox or Chrome interpret C, for example).

How to integrate Golang backend and Javascript (three.js) frontend?

I would like to write a 3D application using Golang, my favorite programming language. However, I would prefer not to use native OpenGL directly as the graphical frontend as this would entail a larger learning curve than I'm willing to tolerate. Additionally, I don't really want to use a Golang game engine like go:ngine.
After doing some research I found out about the amazing WebGL Javascript library three.js and I was so intrigued that I completed an introductory Javascript course in a few hours. I'm not really a web developer at all, so I'm wondering how practical it would be for me to write my application primarily in Go but with a three.js frontend.
Some specific questions:
Is it worthwhile / practical to use Javascript/three.js as a frontend to a Golang server like this?
If it is worthwhile, where can I look to learn how to integrate the two cleanly?
If it isn't really worthwhile, which alternatives do I have?
Thanks, any response appreciated.
Edit:
Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets?
Yes, this is what I'm thinking now. I'm intending my (Golang) program to generate streams of vertices and triangles based on a few parameters from the user. Each "structure" is generated all at once after the users supply their parameters (which I see as slider bars + input boxes on a Javascript frontend).
Here's an example of something the Go program might generate, plotted in GNUPlot:
(source: alexozer.com)
If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.
I'd be fine with doing that, except for these reasons:
The core generating process fundamentally depends on Goroutines and channels
I know close to nothing about web development, including frontend and backend
So I suppose I'm asking about the implementation details of one of these three possibilities:
Writing most of the program, including the generator, in JS, and a minimal backend in Go
Writing most of the program in Go and using JS just as a graphical frontend
Something else?

I recommend leaving out the whole Websocket aspect because it's only a possible optimization (and maybe not even that).
If you need to depend on Go's concurrency model then go for it, write your component in Go, then a Webserver in Go that takes parameters coming from an HTML request, uses them to compute the result and sends back the data in a JSON format.
On the frontend you will then only focus on sending this request when the user changed a parameter and for displaying of the JSON data you can use ThreeJS right away.
You'll still have to learn a bit of web development and Javascript though. But hey, they say the web is the future ;-)
I think it's the way to go for your case because your application operates in a quite strict request-result way.

The answer to your question depends a lot on where exactly you plan to draw the line between your Go component and the Javascript component. From the way you describe the problem I get the feeling that you want to write most of your application in Go and use JS only as a display layer? I wouldn't recommend doing that.
To rephrase my question: Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets? If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.
I might be able to give a more specific answer if I know what exactly you plan to do.

Understanding what AJAX is capable of and its limitations

I have heard about AJAX for years but I never felt the need or the intrest on learning it, I knew it was a mix of Javascript and XML but I never took the time to actully try to understand it, until now.
This is what I currently understand about AJAX. Ajax is not a language, it is just a combination of existing technologies, basically JavaScript and XML (and possibly HTML and CSS) and uses the XMLHttpRequest to comunicate with the server in the background to update/load only parts of a page instead of reloading the whole page.
Things I don't fully understand.
1- Is there any AJAX documentation or API that I can refer to to see what functions/options AJAX offers?
2- Why every book in Amazon seem to be old? Is this because AJAX this is not a language and doesn't change?
3- I read the tutorial at www.w3schools.com and I was wondering if what is shown in this tutorial is basically all AJAX can do, basically, Request and respoind to a server?
Again, all I'm trying to understand here is basically how much of a learning I still need to go through in order to have a better understanding about AJAX.
Thanks a lot

Long story short: AJAX lets you make calls to the server without submitting a form or navigating the page. That is all it does.
Originally it stood for "Asynchronous Javascript And XML" because the XMLHttpRequest object was designed to receive updates in XML format. Microsoft added the object so that the Outlook Web interface could pop up new mail alerts by polling the server.
Since then, most programmers have eschewed the use of XML as the data exchange protocol and rely on JSON instead. JSON is far easier to parse and work with.
While I could go through some examples of the low level XMLHttpRequest interactions, other sources have that well covered.
Instead, I'm going to give you a bit of advice. Study Javascript and consider learning the jQuery API. JQuery forces functional programming and makes common activities like AJAX calls super-simple to accomplish. You'll learn to be a better Javascript programmer because of it and will hopefully learn to make your sites more interactive thanks to the power that background server requests bring to the table.

Although the 'X' in AJAX stands for XML, applications today are more likely to use JSON encoding over XML as the return data can be evaluated directly by the browsers JavaScript interpreter. The core enabling JavaScript object is XMLHttpRequest which was originally developed as an ActiveX component for IE 5. It has since become a standard object in all web browser implementations. You can read about the core functionality here: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest.
Your best bet would be to research modern JavaScript frameworks such as jQuery. http://www.jquery.com/ for information on how to use AJAX technology within your web applications.

This is a bit of a vague question, and likely to get some down votes, but I think it's specific enough that it does warrant some information.
In a nutshell, AJAX is a why for JavaScript to request information asynchronously. The XML portion is a bit of a misnomer, since you don't have to explicitly deal with XML at all. Frequently, you'll use AJAX requests to read in JSON information (since it's so easy to parse and use).
AJAX isn't really a language, or even a framework. It's a technique. It is made possible by the XMLHttpRequest class, along with some related technologies. Since it isn't 100% consistent across all browsers, it is usually best to use a third-party library. jQuery and most other larger frameworks usually have it built in. You can also find some small AJAX-only libraries, like this XMLHttpRequest project on Github.
Every book on the technique is probably old because nothing has really changed substantially since the technique starting becoming popular. I've been using it for at least the past 3-5 years, and not much has changed (other than a bit more standardization in modern browsers).
The respond and request is basically all AJAX can do. However, that enables a whole world of possibilities. Long story short, it's a way to communicate with the server without having to refresh the page, allowing for much smoother UI and UX.

The simplest way to think about it is that it lets you fetch data without a page reload.
Think about how Google Maps loads in bits of the map as you drag around - it clearly doesn't load the map for the whole world.
In older map sites you clicked a left, right, up or down arrow, the page reloaded and the new data was shown.
AJAX lets you make pages feel much faster and smoother.
Technically JSON is usually used instead of XML as it's more Javascripty than XML.
Most sites likely use it somewhere or other, ranging from loading sidebar widgets after the main content, to the whole app, like Gmail.

CakePHP developer tries out JavaScript MV*. Gets confused

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!