Basically, think of something as trivial as form validation. You need to do it both client and server-side regardless, but client side you might have additional complexity, like "if paying by credit card, show those fields, and if paying by PayPal, redirect." This means that your server might need to be aware of these branches of state that might happen, and it means complexity.
On the other hand, if you keep UI state to the UI layer on the client, the server side becomes super simple: you have an API that says something like "here are the shipping and billing details using a credit card. Charge it" or "shipping and billing details + PayPal token. Charge it." There is no "if we are rendering a PayPal processing error, re-render the entire state of the page, preserving all the checkboxes and showing the right bits of the DOM." It's just pure business logic.
Something like Vue is also much better geared at doing a UI than a server-side rendered template. It's dynamic by nature, and directly affects the DOM. The state is kept in such a way that it pertains to the UI. If you are processing something like a request to /orders?filter=recent&order=amount&page=3, you have to re-parse the state from the URL and then get the results every time. Vue/VueX will keep the state in a convenient fashion and the URL can be instructed to reflect it. No need to write custom code to interpret it.
Simple CRUD stuff is super easy with Vue + VueX + Bootstrap + Django. That's been my stack and I like it. Complicated stuff if much faster to develop using this than to try to use something like Django templates + jQuery.
Frontend developer used to be a designer who also knew HTML/CSS but the problem with that is that in order to do CSS well, you need to be a programmer. Especially if you're trying to achieve effects that work best as a mix of JS/CSS. Unfortunately, when it comes to design, UX and UI, most developers are lazy and refuse to learn the basics of it. So in order to prevent PMs from assigning them design-related tasks, the role of Frontend developer was born.
And once there was a separate role, it only made sense to isolate the Frontend developers' environment from the backend developers' so that they could stop stepping on each others toes.
Essentially, the whole Single Page Application architecture is because there is a class of developers who imagine that it's sensible to completely ignore design considerations and who built a moat around their responsibilities in the form of an unnecessary abstraction. Now rather than our views having direct access to our databases, we need a separate API endpoint for every single database call and since we can't trust client code, we need to authorize/authenticate every single little action rather than being able to blindly trust the code that's being run like we used to.
- Ease of creating complex user flows.
- Decentralization of application work: app runs on client, less CPU cycles for my server!
- Separation of concerns: API does one thing, client application does another, there is a bright red line between the two.
The server is rendering JSON anyway, more or less just as expensive to serve HTML. Besides, the bottleneck is usually database access.
It's a false separation and forces you to expose far more than necessary. It's nice to have my full database available on every page render without needing to define explicit endpoints.
I also like having forms generated from database models.
It will light up whenever you are navigating a page built w/ React. Plus, you can dig around and see how they structured it.
Some times you get funny surprises, like how the Microsoft node js page was using React, but they had deployed a Development build instead of a Production build.
Incidentally, Office 365 SharePoint is built on React.
Yep, been there. That type of jQuery gobbledygook has resulted in more bugs than I'd like to admit slipping past my team.
Vue has been an absolute life saver.
I'd love to see what work flows or examples you guys are using to progressively upgrade pieces of the application to use Vue.
For example, it would be really great to see a blog post with a before and after for a feature that you've converted from jQuery to Vue.
https://about.gitlab.com/2017/02/06/vue-big-plan/
I don't think it's exactly what you were asking for, but I'll pass this suggestion along to our front-end lead that wrote these two posts.
Disregard the extremely bootstrap-esque css. I threw it together in a matter of hours to just experiment with Vue.
Not popular at all, as far as I know, but then I don't even have analytics on it to even know if it is popular or not.
Tried it a bit and thought: "Hmm.. it's probably react that causes all these spinning "loaders" everytime I click somewhere. Wouldn't it be better without?". How do you see that?
EDIT: Ups, why the downvotes? With spinning "loaders" I mean the "loading" animation the website shows. The spinning circle. Anything bad about this question?
You didn't ask a question, you jumped to a (wildly inaccurate) conclusion.
Statistically speaking it's _probably_ jQuery or pure JavaScript. These loading spinners have been around to make site loading more attractive for a long time, predating React, Vue, Ember, even Backbone. I have tons of clients on Wordpress that love this kind of thing even if all it does is make their site load without a flash of unstyled content (FOUC).
> If the server would just send a rendered page
React is primarily a client-side framework, but it's possible to render it on the server using Node. However, a lot of sites still use React to enhance an existing frontend, and therefore do not port their entire server to Node to render with React.
> why would a loading animation be needed?
Alright so lets assume you've server-rendered with React, do you still need a loading animation? Maybe. All these sites you click on that have loading spinners are all server-rendered pages too, but that doesn't stop people from throwing jQuery plugins at it to make their sites look fancy and prevent a FOUC. It's more a question of how many images the site wants to display above the fold. If there's a bunch of images, your site will not load fast and you can choose between letting users see a gappy page gradually get filled in or sit and look at a spinner for 1.5s.
EDIT: not to mention all the advertising trackers these sites have enabled. This makes your image-loading all the more laggy.
Spinners make it look like the app is taking ages to load data, even if it's not. If you delay showing the spinner until around a second of loading, it makes things feel a lot faster.
The user doesn't need to always know when the app is loading data until there's a significant pause and they need to know stuff is happening.
Is the time the spinners run determined by the time the server needs to deliver the data? Would they go away when you put the site behind a CDN that delivers the data faster?
> Is the time the spinners run determined by the time the server needs to deliver the data?
Basically. But you can also render your react app or vue on the server and then have client side rendering take over once the page is loaded. This is perhaps the ideal case but it's more complicated and takes some work to set up (I haven't actually done it).
Client side rendering saved my bacon when it went mini-viral a few weeks ago. My little home server probably would have keeled over and died had it been rendering all the pages, but just serving static files is a piece of cake.
It uses webpack with alot of code splitting so instead of 1 big bundle its many small bundles which should help loading times alot.
Now it loaded. It says:
Connection timed out
The initial connection between Cloudflare's network and the origin web server timed out. As a result, the web page can not be displayed.
It may be slower for you if you're on the other side of the world, but you shouldn't be able to do much more than switch tabs during the load even if that is the case.
Everytime I search for sites that use frameworks like Vue or React, I came up with mostly empty hands. Except for example pages or pages by coders for coders. Or pages that "use" one of the frameworks but seem to make no use at all of the functionality.
When I ask around people usually tell me "Well, at my company we make a dashboard for another company and it's based on ..."
Any popular public sites (Aka no login needed to access it. So Facebook doesn't count.) for non-coders out there that use these frameworks?