One should use what is necessary and no more. If server side templates work for you - great.

My rule of thumb: if I need to do more then a trivial amount of DOM manipulation then I will use a framework, because otherwise I will end up writing my own anyway (which I can easily do) which wastes development time.

For projects with several developers a framework can help maintain common coding style and reduce ramp up time for new hires.

Also, good frameworks come with nice tooling that make for more productive development. For example, Vue + Vuex and the Vue browser plugin are great for inspecting the state and observing state transitions.

An example of my use case: I have a non-SPA app that receives various data via Websocket and the view is immediately updated. Several components take this same data and render it in different ways. Vue is excellent for this. I still use templating on the server side for the basic page structure.

Could you add the lines needed to the above example to make the user list grow / shrink real time via websockets?

Would be interested to see how you would implement that.

Pseudo-ish code because I’m typing from my phone.

Vuex code as per docs to create state.stuff and mutations.update_suff() then in main Vue instance

    mounted () {
      this.$socket.subscribe(‘stuff’, data => {
        this.$store.commit(‘update_stuff’, data);
      });

where $socket is a subscriber client I wrote wrapped as a Vue plugin.

Then inside the components

    computed () {
      stuff () {
        return this.$store.state.stuff;
      }
    }

then use stuff as in your example.

So very simple, and nothing that I couldn’t do without Vue but it takes care of the boring DOM manipulations and using the browser extension during development I can watch state change (which becomes interesting when there are multiple subscriptions with data combined).

So the first step towards your solution would be to include vuex? Like this?

    <script src="/path/to/vuex.js"></script>

And then?

What are mounted() and computed()? They look like methods of a class?

If you're just rendering HTML, you might as well do it on the server with your choice of language/framework. The power of Vue and other Javascript frameworks is in their reactivity and the ability to create extremely powerful interfaces.

I only use Vue when I need to alter the data clientside before it gets rendered. For example mark some of the users in the list as friends depending on which friends the user has stored in localStorage.

If the data is ready to render while still on the sever, I do so.

I'm DevOps, with 20+ years background in Ops. So the Dev side of things often fascinates and confuses me.

Thank you for clearly talking about why you'd use Vue and when you wouldn't. It's this sort of experience-based knowledge that I often lack.

I'm currently writing basic (very basic!) node stuff intended to further my understanding of Kubernetes: accessing a database, talking to a redis instance, etc etc. It can be bewildering trying to navigate the "oh-so-easy" basic examples of different frameworks and compare their different features.

Hm, that sounds like I'm asking for help, which I'm not - I just want to give an example of why your comments were so helpful to me!

Sounds like you really have a firm grasp of everything.

Not sure if your use case includes automatic rendering (new/delete/mods) when the underlying data changes. If it can be done automagically (via unique id in the data) that is a big win (aka, code I do not have to write). Things like shadow DOM et al, are not something I want to implement or maintain.

When the user triggers a change of the underlying data, I do a roundtrip to the server and re-render the current page. I keep the time needed to do so under a second. My users regularely express how WOWed they are by the snappyness of my sites.

I guess what other sites save on re-rendering html, they lose multiple times on bloated code.

„Under a second“ might be ok for websites, but doesn’t cut the mustard for web applications. People expect highly dynamic user interfaces which react almost instantaneously.

If all websites would react within a second to user actions, this would be heaven. But the reality is different:

https://news.ycombinator.com/item?id=18476247

While 30s is off the chart, I see bloat that needs multiple seconds everywhere. The new Reddit, AirBnB, the various Google tools etc etc.

That literally means that you aren't doing SPAs. If you aren't doing SPA then yes using React or Vue is rather a waste.

However the majority of sites these days use some form of SPAs.

Also under a second is a very low bar to strive to. a fast round trip to the server is 100ms. A reasonable one is somewhere around 300ms. Displaying effects to changes is often under a millisecond in SPAs and is basically impossible to reach in Multi page applications.

> If you aren't doing SPA then yes using React or Vue is rather a waste.

I disagree, based on my experience of writing a reasonably complex non-SPA application which very much benefits from Vue.

I also think the fact that Vue Router ships as a separate app further suggests SPA is just one use case.

> However the majority of sites these days use some form of SPAs

Do you have a reference for that claim? I very much doubt you are correct, but I'd be interested in seeing some stats either way, if they exist.

The claim might be true among YC companies or even startups... but the majority of websites by far don't use React/Vue: https://w3techs.com/technologies/history_overview/javascript...

I'm not saying that React/Vue aren't important and drastically changing what's thought of as best-practices in web development... but just because everyone on HN uses a front-end framework for their websites doesn't mean "all websites" do it.

Thanks, these are exactly the kind of numbers I was looking for!

as a React developer, SPAs in general are overused. Most LOB apps could (and should) still be written in a backend templated language. SPAs should be reserved for applications (or even individual components) with advanced interactive features, ie a proper web app.

That's also my conclusion after toying a bit with those frameworks. You want to use them for specific pages ressembling applications, but you still want the main structure of your frontend to be defined server-side, using the most standard technology.

This lets you split your interface into more isolated components, and makes you free to use different framework depending on the type of interaction your page needs, as well as be able to update your site progressively.

yeah, for most web apps that are primarily regular CRUD+routing interfaces, you can/should use SPA tech to progressively enhance your more advanced controls. There are cases where it makes sense to build a whole SPA (I'm working on an in-browser editor that wouldn't work very well as a backend app, for example) but the vast majority of cases where React is used, it just adds complexity and challenge.

React/Redux hasn't been around long enough for its best practices to solidify in the general industry so you'll often find that companies that picked up React have a hodge-podge of incorrectly used technologies included because they didn't know the use case for Thunks vs Sagas, how to use Reselect correctly, whether to store any given state in Redux or a Container, and so on.

Enterprise apps are also a suitable venue for SPAs. You've got some developers coming from e.g. Swing, MFC++ or even Tcl/Tk, and for those doing every frontend bit in JS is closer to standard UI toolkits, instead of the constricting request/response cycle of old webapps (except those few that did some hacks with server-side continuations).

Also, in those cases a few extra seconds for the initial load or the general size of the application don't matter. It's all better than your average Swing application ("Challenge accepted", said the Electron developer).

Although this isn't something contemporary frameworks seem to aim for (ExtJS is dying, and that's good), you get close enough to desktop UI development with Vue/Vuex/Ant Design, Angular/AngularMaterial or React/Material-UI/Redux-boilerplate-reducer-of-the-week.

yeah that's basically the TL;DR of it - the more "desktop app" type functionality you need in your web application, the more SPA technology you're liable to need.

Just to confirm: SPA = Single Page Application. What does LOB mean?

line of business. It's basic internal apps most software devs are working on. Usually 90%+ CRUD forms and tables.

If a template engine is all you need here's the simplest: https://github.com/wisercoder/uibuilder used by apps such as https://circles.app

Some people maybe, but I doubt it's "most" people.

The point of using Vue is data-binding with reactive models and components.

For your use case I agree Vue is overkill. A templating engine should be enough.

You could use string tags. The only thing that is really needed is a DOM diff library to make UI updates bearable. The rest can be completely handled with a basic MVC architecture.