Earlier quoted context omitted.
That's my point. You don't have to in react either.
You don't have to, but nobody would. It's not practical. While it's very practical to do so in Vue. Like you can write Java without IDE. Nobody would. But plenty do with Python.
How we do Vue at GitLab: one year later
191–200 of 208 posts
Re: How we do Vue at GitLab: one year later
#192Earlier quoted context omitted.
I've been learning React lately, and many tutorials, even those targeted at beginners, include Redux. Many seem to be a sort-of cargo cult without any understanding of why they're using Redux, and in many cases, there's no reason to introduce Redux into the mix. I've also noticed a lot of tutorials are content marketing from companies wanting to sell bolt-on services and tools, which is pretty weird; I've never used…
There is a big problem with the commercialisation of React. More and more companies are using learning resources as marketing material. And now one popular JS developer has started beginning his GitHub readmes with advertisements for a paid JS course. It's a far cry from the open, guileless sharing culture of webdev 10 years ago.
But, the learning materials and marketing are the ones that bug me...especially the ones that neglect to mention that the materials cover React+product, and only mention React in the title. You might not even know it's marketing until you've read half the darned thing and the crux of the thing turns out to be "now create an account here and use this service to outsource the specific thing you googled to learn how to implement yourself". GraphQL has a lot of the same thing going on. It's like "how to draw an owl", only instead of "now draw the rest of the fucking owl", it's "now send us money every month for the rest of your app's life and we'll draw an owl for you".
Re: How we do Vue at GitLab: one year later
#193So I've used Vue for personal projects before, it's really nice. I lead the dev on a small team within a large corporate company, we focus on React & Angular(io). The primary reason why I would not adopt Vue is because Vue is still driven by Evan You - which is great, but if something had to happen to the guy (and I hope nothing does), I'm unsure Vue would have the long term support & drive it does right now.
While Evan is currently the main force behind Vue, there are many large companies with stake in it, as well as a reasonable number of contributors. Personally I prefer the current state of operations over the dense bureaucracy surrounding some other libraries, but you’re obviously free to disagree.
Re: How we do Vue at GitLab: one year later
#194Earlier quoted context omitted.
So, pretty soon we should see youdonotneedreact.com websites popping up?
Once web components become standardized. So...2030.
https://html.spec.whatwg.org/multipage/scripting.html#custom... https://dom.spec.whatwg.org/#shadow-trees
Re: How we do Vue at GitLab: one year later
#195Earlier quoted context omitted.
Funny thing is, Vue wihtout extras is more complex than React without extras.
Nope. Nope. Nope. Trainer here. I train in React and in Vue. My students do 3 times the work with raw vue than in raw react. Every one of them. All the time. It's not even on the same map.
I haven’t found anything nice for a guide in building a real world application like this. Maybe it would involve multiple things vue + ? + Postgres or Mongo or some other option. But I want love something that would hold my hand start to finish connecting the dots.
Re: How we do Vue at GitLab: one year later
#196Earlier quoted context omitted.
Nope. Nope. Nope. Trainer here. I train in React and in Vue. My students do 3 times the work with raw vue than in raw react. Every one of them. All the time. It's not even on the same map.
This might be a dumb question, but what’s the best way to actually use this to make a real application? I’m talking speak to a database and hook up a backend. I’ve enjoyed using vue from a “this is a neat way to make components” but I’ve never successfully been able to do anything with it. I understand it’s just the “view” and not a full MVC like rails but I want that to exist. I want it super opinionated and favor c…
Re: How we do Vue at GitLab: one year later
#197I hope one day more web developers will realise all the major JS frameworks are just a band aid to plug the gaps in vanilla JS. It should be easy to build web apps using vanilla JS. No frameworks pushing a certain way of working, just a reliable batteries-included language that you're free to extend with your own application-specific extensions and mix-and-match external libraries, just like desktop app developers ha…
Re: How we do Vue at GitLab: one year later
#198I hope one day more web developers will realise all the major JS frameworks are just a band aid to plug the gaps in vanilla JS. It should be easy to build web apps using vanilla JS. No frameworks pushing a certain way of working, just a reliable batteries-included language that you're free to extend with your own application-specific extensions and mix-and-match external libraries, just like desktop app developers ha…
Easiest way to solve this would be to simply bundle a precompiled Vue into the browser and call it a day.
Re: How we do Vue at GitLab: one year later
#199https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
Re: How we do Vue at GitLab: one year later
#200Earlier quoted context omitted.
Is it bad to write without all these JS tools? We just use Visual Studio and include the standalone Vue.js file. We write plain css (no sass etc) and js with some occasional JQuery. We don't use Nodejs and its build tools (Kinda don't like the complexity all those tools bring. You are more worried about the tooling than the actual problem at hand). We use Ajaxmin and Httpcombiner. That's it for Frontend. Vuejs is gre…
It's not bad at all. You just have different requirements. I prefer React, but if the apps I was working on came to change in requirements, I'd be very happy to have Vue as an option. I don't think having 16 different major frameworks that overlap in functionality is healthy, but having a handful of fairly distinct ones that overlap on some points is just a good thing. We have hundreds of full sized frontend applicat…