Recent comments

  • Why we chose Vue.js over React   1 year 16 weeks ago

    Are you honestly saying that a company that has thousands of developers can present a more clear vision and work-flow than one of a single developer or maybe a 10 person team?

  • Why we chose Vue.js over React   1 year 16 weeks ago

    I am not saying that TypeScript is bad, but I don’t think it will make my life dramatically better: https://medium.com/javascript-scene/angular-2-vs-react-the-ultimate-danc…

    I am not saying that 75mb of npm libraries is a huge thing to consider. It’s just a sign of bloat.

    I tend to respect and use “groups of people” work pretty much like I use projects from giant corporations. I’ve seen a lot of times how giant corporations fail to provide a great product that gets traction from community (this is not related to React, which is a great product).

  • Why we chose Vue.js over React   1 year 16 weeks ago

    you can use rml to replace jsx: https://github.com/yiminghe/rml

  • Why we chose Vue.js over React   1 year 17 weeks ago

    Really? You really tell that you won't use Angular 2 because of Typescript and big amount of files? You really tell that Hello world project on React requires 75MB of npm libraries? Dude, if these are problems for you.. I don't even know what to say. You should understand that Vue is developed by a group of people and React is developed by a giant corporation and it will have appropriate quality of support. Imho.

  • Why we chose Vue.js over React   1 year 17 weeks ago

    Reviews about Aurelia are pretty positive. I haven’t tried it yet though.
    It looks really similar to Vue.js in terms of syntax and approach, which is nice.

  • Why we chose Vue.js over React   1 year 17 weeks ago

    Thank you! Yes, I’ve heard a lot of good things about Aurelia, and it looks really similar to Vue.js, haven’t tried it yet though.

  • Why we chose Vue.js over React   1 year 17 weeks ago

    Really good point. I love react and using in production for over an year. But forms are the biggest pain in react. But i think considering it shines in every other aspect, you should conder switching to a templating engine is better than going with a powerful rendering engine like react

  • Why we chose Vue.js over React   1 year 17 weeks ago

    Have you checked Aurelia yet? It's a great framework! I'm having great fun using it. Simple, productive and doesn't get in the way.

  • Why we chose Vue.js over React   1 year 17 weeks ago

    Thanks!

    A very nice comment about Angular2 from here:

    All Google documentation is like reading Microsoft docs from the early 2000s.
    “Setting up an Angular project is a piece of cake! Just make sure the stateless reference prototype mutator inherits from the base memory loader legacy object implementing the MODOK service provider (not part of core: see here for equally unreadable details). You’ll then be ready to compile your Angular kernel, being careful to use Webpack 2.3.9 (note: not 2.3.8 as supplied with the repository). This is all you need to know to get started on a great Angular project. Angular: making development simple and fun again!”

  • Why we chose Vue.js over React   1 year 17 weeks ago

    Great write up with real-world, practical points. A very refreshing post on how web developers in the non-Fortune 500 world work.

    I've created apps in Angular 1 and it was decent, Angular2 (thru the beta/rc process) was a nightmare.

    At work, my catchphrase for Angular2 (beta/rc) was "everything made easy is hard again".

    Been using Vue.js for about 2 months and absolutely love it. Doubt I will ever go back to Angular2.x

    Thanks for posting this!

  • Why we chose Vue.js over React   1 year 17 weeks ago

    I'm using the Vue-based Quasar framework (http://quasar-framework.org/) and it is simply amazing.

  • Why we chose Vue.js over React   1 year 18 weeks ago

    Immutability was just mentioned as a marketing buzzword here. I respect functional patterns and immutability is a great thing when used in a right place - finally in a lot of cases it results in better code! But real world development is about balance and timing, and my concerns are mostly related to current situation specifically with immutability support and necessity in JS. If Javascript does not support immutability in core and the developer adds Immutable.js and then spends a day trying to tie it to Lodash and existing legacy code of system, because he did not realize that Lodash is not going to work (yes I know about lodash wrappers for immutable structures, it is just an example), and Immutable.js core methods are not enough for him to complete the task - so as a result, the deadlines are not met - that is what I call bad developer who was sold by marketing of Facebook and buzzwords, not functional paradigms. Business in a lot of cases values the speed of development and medium-quality code a lot more then bullet-proof reliability and perfect code, tied with slower development - because at the end of day, dead business does not need repos full of perfect code, it needs features completed on time! I see this from time to time - people who value paradigms and new technologies more than effective business tasks solving, and that’s what I am talking about in the post. When Facebook enforces immutable structures inside their huge team - that is completely different story. They see how it benefits their business, because quicker development techniques with plain JS are already not reliable enough for them, they break things too often. I see no reason why you should not use Clojurescript or Elm in pet projects or in production if you manage to do everything on time and the code is maintainable (not just by you, but most of developers that might see this code later) - it’s a great thing to learn new technologies, it makes you happy and finally makes you a better developer. But I doubt that small and medium sized business typical tasks require functional patterns like full immutability being enforced in current stage of JS development - the class of tasks these companies usually solve by JS is usually pretty simple, at the same time medium-skilled developers from the market might get troubles with such functional code, and good developers are expensive. (This situation might change in a few years when functional patterns will be more common)

    Another bad aspect of immutability being enforced by Facebook in JS as part of “default” stack (yep, the aspect not directly connected to immutability, but connected to situation with functional patterns in JS, and very important) is that it increases JS developers segmentation. When “oldschool” developers that have billions lines of legacy jQuery code inside their legacy systems are trying to jump from their mess to React + immutable.js it is just too much of new stuff for them in terms of mindset shift and code rewrite. When these guys look into webpack configs, Flux and Immutable.js docs, a lot of them think f*ck that, I will continue to write my jQuery code, it is just crazy, I just wanted this input to be saved to DB via ajax. Vue.js (and some REST apis on backend) can do miracles for these developers, because the most possible alternative is: just sit there in old jQuery code and suffer. When they master Vue.js - some of them will probably shift to React (and Immutable.js) if they see the need for it in their code, because going from Vue.js to React won’t be that hard already.

    For some developers that already use React and Immutable.js in their production code and are happy with it - Vue.js probably won’t be so interesting. That’s why there is so much negativity from young and smart devs who are already using React, I guess.

  • Why we chose Vue.js over React   1 year 18 weeks ago

    Thank you for your opinion. I guess I’m already competent enough to not become angry or upset when I read such comments :) You can use one method in your component to handle 10 inputs, but in real world you will have to normalize values that go into your method and check targets, and your method will quickly become ugly, for example try to use this approach when you have an array property in state, and the form field representing this array is rendered as as set of checkboxes. That’s why most of the tutorials on React components which use internal state (including Facebook official guides) - tend to use separate methods for each input, it’s just cleaner in the long run. This is not something you can’t solve in React by some coding and adding more components, but my opinion is that it should to be solved on basic level of the view framework I am using. (And when using Redux - you will have to create all your constants anyways)

  • Why we chose Vue.js over React   1 year 18 weeks ago

    Thank you for your feedback! I’m glad it helped someone :)

  • Why we chose Vue.js over React   1 year 18 weeks ago

    Competent and well informed? Have you read these comments?
    - https://www.reddit.com/r/webdev/comments/5ho71i/why_we_chose_vuejs_over_...
    - https://news.ycombinator.com/item?id=13152368

    "Or you can learn JavaScript."

  • Why we chose Vue.js over React   1 year 18 weeks ago

    abstract the if condition out of the render method into something like `renderTitle` then in that method put all the ifs ands or buts...easy peasy

  • Why we chose Vue.js over React   1 year 18 weeks ago

    I am your precise audience. My team works in legacy Drupal land as well and we haven't felt the need to move to any JS frameworks to manage our front-end. However, some of our stuff is about to get a little more complicated so we may need to. Since I manage our build process, I started looking into incorporating React and was a little discouraged by the amount of stuff we'd need. Your article has definitely prompted me to take a look at Vue.js. Thanks!

  • Why we chose Vue.js over React   1 year 18 weeks ago

    Is the link formatting broken here?

    Simple app based on official react starting package code has around 75MB

  • Why we chose Vue.js over React   1 year 18 weeks ago

    >> I'm not sure you fully embraced how immutability can help you reason about your programs.

    If you don't get it then you're not embracing fully enough. QED

  • Why we chose Vue.js over React   1 year 18 weeks ago

    I don't know, the author seems competent and well informed. I'll take this article as objective and factual reasons to stay away from both React and Angular.

  • Why we chose Vue.js over React   1 year 18 weeks ago

    While reading "Not being able to put plain old IF condition to some block of HTML code sucks" i must say .. IMHO if you need more than a simple ternary operator, you simply have an incompatible datastructure or -even- mindset.

    Still reading on to learn about VUE.js vs React though..

  • Why we chose Vue.js over React   1 year 18 weeks ago

    Holy carp no. Adding even more dependencies on top of react. This is going in the opposite direction from what's being discussed.

  • Why we chose Vue.js over React   1 year 18 weeks ago

    Thank you for this supportive and thoughtful comment. I agree that JS world is jumping around new shiny technologies like crazy. I think React is great in many aspects, and it is definitely good enough not to jump to Vue.js if it gets the job done for you! At the same time, I hope this post will motivate people who are stuck in jQuery and Prototype but who are feeling pain about all these landscape changes in JS around them - Vue will be a great step forward for them and their interfaces.

  • Why we chose Vue.js over React   1 year 18 weeks ago

    Looks interesting, thank you for the link!

  • Why we chose Vue.js over React   1 year 18 weeks ago

    Vue.js is not a framework.

Drupal association member