5 ms·

I still don't see a reason why one would use Vue or React. I agree that templating of data is something you should use a library for. But there are great templ

• serial_dev 6y ago
  Which template engine? Then what if you realize you need a router? Then the developer who glued those together leaves, and all you can hire is juniors. There are benefits to using the industry standard (which today I consider Vue, React, Angular and slowly Svelte), you can learn it quickly, as it has ton of resources and you can hire easily, as you aren't forcing someone to use some obscure, home baked js framework. That's my take at least.
  • azangru 6y ago
    > all you can hire is juniors Then you are in trouble regardless of what you use :-)
• cjohnson318 6y ago
  One example is building an application like minesweeper. Would you really want to tackle that with jQuery and templating engine? I'd rather break everything into components, have them talk to each other through a state manger like vuex or redux, and only phone home to my API for important things, like the final game score.
  • TekMol 6y ago
    I would neither need jQuery nor a templating engine to write Minesweeper.
    • j-krieger 6y ago
      It's great you applied your vanilla JS skills to his totally metaphorical example. I still don't get why it's okay for every other programming language to use the STL or huge dependencies, but doing so with javascript is frowned upon for some people. You wouldn't write a JSON parser yourself in CPP, you'd install something from conan or use the STL or boost for that. Why is it so bad to do the same with js?
      • TekMol 6y ago
        The browser does supply a huge number of APIs. To set one of the Minesweeper tiles to bomb, you could do: tiles[x][y].className='bomb'; And you are done. The rendering will nicely take place according to what you defined in the CSS.
        • Exuma 6y ago
          What are you talking about? You're just talking about simple class manipulation which has nothing to do with actual reactivity, especially 2-way data binding. How would you support that with your "templating engines" you keep mentioning, which to me doesn't mean anything at all, in my understanding of what a templating engine is like handlebars.
          • TekMol 6y ago
            As I said, I would not use a template engine to write Minesweeper.
            • ric2b 6y ago
              So when I click a tile you have some code on the onclick handler to go update the counter at the top? Sounds messy if there are multiple things you need to update when some data changes.
      • mixmastamyk 6y ago
        Not the end of the world, but the client will have to download it.
  • 3131s 6y ago
    I made a minesweeper clone in JS and CSS, it's not as hard as you'd think and just a few hundred lines of code. I still want to attempt a multiplayer minesweeper, which might benefit more from something like Vue. A dashboard is usually for me the primary use case for one of these reactive frameworks.
• Exuma 6y ago
  It's almost a necessity for complicated apps. Right now I'm building an app which involves a reporting screen with all the following features on a single page: - 10+ breakdowns for report - 10+ filters for report - Each filter has an include/exclude dropdown list which then has multiple features within even a single filter (so some filters are EQUALS/NOT EQUALS) others are INCLUDES/DOESNT INCLUDE/EMPTY/NOT EMPTY and all the appropriate options for each filter, not to mention clearing filters, etc - column sorting - column hiding - filtering with search - pagination on both client and server side (50K rows batching into sub pagination groups which client side takes over on server batches) - a dropdown at the top which re-initializes EVERY piece of data with a different account and changes quite literally re-initializes 50+ "states" of the UI on the page Thinks of google analytics First of all, we can assume doing this on the front end is 100% required. Imagine using google analytics where every single option you change is a backend request. Impossible, so now that weve gotten past that... Imagine using something like jquery or custom JS where you try to manage the incredibly complicated input/output nature of each component of the page. Component based design is required because you can keep all your logic for the entire app for a single TINY piece of the app in its own file. So something like a dropdown menu can get its own component called `<DropdownMenu>`, and within that you define all "outer state" that component can use as a prop, or input state (so for example, you want the items that appear in the list to be defined OUTSIDE the component so the component can be re-used). However, that component also has its own internal state, such as whether its open or not, whether its animating or not, what item is selected etc, so if a component has internal state, then you store it IN the component itself. So now the 'state' of EVERY component on the page is defined in 2 places... the originator of the state (such as the component which holds your API calls), or in the component itself. When any change takes place in ANY of those states, all components related to that state "update" automatically to use that new state. This means by simply making a new API call, the outer component state changes, and every single component that relies on that state updates accordingly, even for the most complex UI imaginable its trivial to think about 95% of the logic because all the state is exactly where you expect it to be, and when there are infinite numbers of nuanced side effects, you usually program them IN the component and you dont have to clutter your actual logic (say for instance the api updates your base state, you want the dropdown to reset to zero, so you would code this into the component itself, so that everywhere on the page that uses this component it would all follow suit).
• mattwad 6y ago
  If you use Typescript, it means type-safe templates. That's a game-changer right there.
• mmczaplinski 6y ago
  A short example, no, because if all you need is a simple website, then you don't need Vue either :) If you're building complex user interfaces or a large-scale web app, then hell yeah, you want to use React or Vue.
  • j-krieger 6y ago
    You can use vue, because for most web-applications with vue3 you will only add an additional 15kb to it. I'd wager kilobyte counts that low are worth it when you consider how much easier it is to add on additional functionality when you need it. A well-built build system can do so much automatically for you, including but not limited to automatically minifying your code, cleaning up dead code, html and styles or compressing your images in the build step. For reference: I recently built a really large scale website with react, including a content-management-system, custom fonts, around 50 pictures and a ton of tracking. It weighs 1,1MB total. The first request without lazy-loaded resources only uses around 200KB. Can't really argue against that.
• j-krieger 6y ago
  Any code involving a mid- to large sized web application that needs reactivity. Templating engines like handlebars are used on the server side, react and vue belong on the frontend (most of the time, but not exclusively). That's the reason people use them: If you want to, you can have your logic executed on the client-side only, and host whatever else you need on a cloud-provider. Client-Side computing doesn't scale particulary well when your userbase grows fast enough.
  • TekMol 6y ago
    Handlebars works nicely clientside.
• pier25 6y ago
  Sure, you can use HBS (or even vanilla) to render a piece of dynamic HTML. That's not really the problem these libraries are solving. You could also create your own components with HBS templates and figure out how compose them to render a tree of components. That's not too hard to figure out either. The problem is really in updating the DOM when state changes somewhere in your application. In the jQuery days we had tons of micro DOM managing code so that when some variable changed then we would update some piece of the DOM by "hand". But as your project grows this becomes a mess pretty quickly. Another solution could be to simply re-render everything and update all the DOM on every frame with a state change. That would simplify your code but it would probably be extremely inefficient. The point of libraries like Vue, React, Svelte, etc, is about simplifying the production of sophisticated UIs, as efficiently as possible, so you can focus on the right abstraction instead of the implementation details (eg: managing the DOM). Every library takes a very different approach. If you're coming from the vanilla/jQuery world the learning curve can be pretty steep. But, as someone who has been doing web frontend for 20 years, I think the price of admission is worth it. IMO Vue is probably the easiest one to get into. You can get started by simply including it in a script tag as if you were using jQuery.
  • TekMol 6y ago
    You say updating the DOM becomes messy but give no arguments why that would be the case. Say a function changes the cars array. All it has to do to update the DOM is: document.querySelector('#cars').innerHTML=carsTemplate(cars); Where carsTemplate is a HandleBars template that on page load has been initialized with the html to render the list of cars.
    • cercatrova 6y ago
      That's an imperative approach, rather than a declarative one. You can't track where the state is being changed if #cars is being changed in many places. Templates are fine for smaller apps but in larger apps it's more difficult, and there'll be more spaghetti code and bugs due to that.
    • orthecreedence 6y ago
      Ok, now show the cars list in three places, and one of them is a subset of only BLUE cars. Now you have to update the DOM 3x and remember that the filter you set in that one place over there means you need to only show BLUE cars in this one place over here. When you start to build things where one piece of data is not just shown in multiple places, but is dependent on other pieces of data, managing your state starts to become more difficult than the methodology you're describing.
• deleted 6y ago
  [deleted]
• mmcnl 6y ago
  Vue and React are more than templating engines. They decouple the state and view of your application. This means your view becomes a function of state, and you only need to worry about state. This solves the problem of trying to keep your view in sync with the application state, which probably everyone who has done some webdev for more than 5 years still has nightmares about.
• ncr100 6y ago
  https://academind.com/learn/angular/angular-vs-react-vs-vue-my-thoughts/ https://academind.com/learn/angular/angular-vs-react-vs-vue-... This link might contribute to your evaluation. It's a seemingly reasonable overview of the top three frameworks. Author recommends using all three, spoiler?