5 ms·
My feeling is that most people who use Vue or React only need a template engine. Typical use case: You have an array of objects and a template how each object s
by TekMol 8y ago
My feeling is that most people who use Vue or React only need a template engine. Typical use case: You have an array of objects and a template how each object should look like.
So you do...
<div id=users>
<a v-for="user in users" :href="'user/'+user.id">
{{ user.name }}
</a>
</div>
<script>
let userList = new Vue({
el : '#users',
data: { users: users }
})
</script>
...to make Vue render the list of objects.
This is the only thing I ever use these frameworks for. Everything else I think I can implement in a better, leaner way myself. So I wonder if I should switch to a template engine instead.
What is the next most basic/common usecase for Vue?
- beaconstudios 8y agoas 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.
- bloopernova 8y agoJust to confirm: SPA = Single Page Application. What does LOB mean?
- beaconstudios 8y agoline of business. It's basic internal apps most software devs are working on. Usually 90%+ CRUD forms and tables.
- bsaul 8y agoThat'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.
- beaconstudios 8y agoyeah, 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.
- mhd 8y agoEnterprise 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.
- beaconstudios 8y agoyeah 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.
- deskamess 8y agoNot 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.
- TekMol 8y agoWhen 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.
- j_jochem 8y ago„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.
- TekMol 8y agoIf 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 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.
- Illniyar 8y agoThat 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.
- dpau 8y agoIf 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.
- TekMol 8y agoI 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.
- DJBunnies 8y agoSounds like you really have a firm grasp of everything.
- bloopernova 8y agoI'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!
- gbuk2013 8y agoOne 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.
- TekMol 8y agoCould 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.
- gbuk2013 8y agoPseudo-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).
- TekMol 8y agoSo 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?
- petilon 8y agoIf a template engine is all you need here's the simplest: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder used by apps such as https://circles.app https://circles.app
- pier25 8y agoSome 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.
- aikah 8y agoYou 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.