I still say Mithril ( https://mithril.js.org/ ) is where it's at. I am at a company now that uses Angular 4.x and I'm not impressed with it. IMO, it's a way to make JS seem more like Spring/Java (especially with Typescript) rather than understand how JS works and use it as it is. Not to mention the learning curve even for senior developers. Mithril took me maybe 30 minutes to understand. The entire source ( https://g…
Why we moved from Angular 2 to Vue.js and why we didn’t choose React
111–120 of 151 posts
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#112Earlier quoted context omitted.
Angular 2 kinda sucks. Simple oversights like not having a way to change focus on input fields leads me to believe it's run by crazy purists. There's many other mistakes, like not having access to component state for custom validators and the infamous change detection errors. Sometimes the error messages border on horrific, reminds me of debugging assembly. Some of these issues don't have any good solutions. The need…
No Framework is perfect. There are always tradeoffs. Just because some things didn't work for you doesn't mean you can generalize and say Angular2 is bad. The way the Author wrote, he is generalizing things and making assumptions based on baseless facts
Form validation is a long-solved problem and doing custom validation is a huge pain. Accessing the raw DOM sets off warning bells but in Angular2 it needs to be done for simple things like form field focus. You need to implement FieldValueAccessor for custom fields and the documentation for that sucks.
There's two different form libraries that are largely incompatible. Underneath that several ways to instantiate and manipulate both types of forms. It's so hard to build practical components that Angular2 Material still isn't finished.
If my company wasn't using ng2 extensively I would jump ship for react asap
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#113Earlier quoted context omitted.
We went from anything like JSX getting you laughed out of the room (LOL 'onclick' properties, hello, 1998 called! Also code doesn't belong in markup, so markup certainly doesn't belong in code, are you insane? Templates! Separate style!) and sensible, healthy skepticism of workflows like "compiling" not-html to still-not-HTML to eventually generate HTML at runtime, to all of that being just fine and anyone not immedi…
JSX is not html. JSX is not a templating language. The similarity between JSX syntax and the equivalent virtual DOM node names is the reason it exists. When you write JSX code you are writing javascript code using the JSX DSL to generate the virtual dom. 'HTML templates embedded in code' is simply not what happens when you use JSX. The fact that you got fooled into thinking that is the opposite of a DSL problem.
Which part of what I wrote makes you think I think JSX is an HTML template? The part where I specifically called it "not-html" and the react.createElement code it's translated to "still-not-html"?
That it's kind-of-HTML-but-not, turned into Javascript, turned into shadow-DOM transformations, turned into HTML, is Rube-Goldbergian enough to warrant skepticism. No need to misunderstand it to feel that it's an indication that something somewhere has gone deeply, fundamentally wrong.
And actually I think it'd be fair and consistent to call it a template language, were I inclined to press that point. That it becomes Javascript doesn't change the form it takes when you're writing it. Looks and quacks enough like a duck that insisting it's totally not a duck at all is untenable. Sure, it's translated into shadow-DOM-transforming JS. So? It's not like HTML itself doesn't go through some intermediary representations before becoming different colored glowing pixels on your screen.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#114Earlier quoted context omitted.
>rather than focusing on "omg html in my js" you should focus on "omg presentation code in my business logic code" because that's when you realize where the real boundary is. Just no. many times presentation code is tightly coupled with some desired functionality that drives that presentation. HTML inside JS is just inherently weird. It's one level of counter-intuitiveness to have the HTML set to some variable and pu…
> HTML inside JS is just inherently weird. ... The two languages just doesn't jive syntactically that's because you can't escape the notion that DOM must always be represented as HTML and nothing else. [v]DOM is a very well structured entity, and it so happens that our programming languages love structured entities and manipulating them.
I'm not talking about the mental model of writing DOM manipulation code. React still has user write actual HTML syntax.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#115Earlier quoted context omitted.
I agree. Having used both on small projects I was able to get started and finish quicker on Vue. That being said, I use React more because of the larger community, (easier to find answers, and components) as well as more jobs for React vs Vue. Also, Fiber introduces better animation performance, which i'll eventually use.
Things have become easier with create-react-app though.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#116Earlier quoted context omitted.
> It should take no more than 20 minutes to learn JSX. it should, but in practicality, for most front-end devs especially junior ones, it's not. Moving Angular 1 devs to Vue gets actual work going 3-4 times (anecdotal experience) quicker than with React. For most smaller shops/startups Vue is almost always a better idea - it's much easier finding devs (especially remote/<100k comp ones) with previous Angular 1 experi…
If you know only JS, JSX is much easier to pick up than some proprietary templating language. How do I do an if, a loop, a map, ... any code at all? In JSX, the answer is squiggly-brackets and regular old JS code. In Angular's templating system and Vue's, you've got to relearn all of these and more.
On the other hand, JSX is extremely difficult to read. I can glance at a relatively complex handlebars template I wrote two years ago and instantly understand what it renders. To do the same with a similar JSX component requires spending ten minutes to trace the control flow, understand all the helpers, and mentally re-inline all the loops and conditionals. It's conceptually simple, which is attractive, but in practice that seems to lead to noisy, nonlinear render functions that have little to no structural similarity to their final rendered DOM.
It's also worth noting that JSX is easy to pick up for javascript developers. It's next to impossible for the kind of design-focused frontend people who know HTML and CSS inside and out but only ever needed enough JS to write the occasional jQuery selector. If you're certain your project will never have any styling input from people who aren't first and foremost programmers then JSX might be a great fit, but the rest of us actually have to work with our teams.
* Yes, I know, JSX is technically not a template.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#117Earlier quoted context omitted.
> HTML inside JS is just inherently weird. ... The two languages just doesn't jive syntactically that's because you can't escape the notion that DOM must always be represented as HTML and nothing else. [v]DOM is a very well structured entity, and it so happens that our programming languages love structured entities and manipulating them.
Who said anything about DOM? You/Me/We are all talking about HTML code.. I'm not talking about the mental model of writing DOM manipulation code. React still has user write actual HTML syntax.
React has users write HTML-like syntax sugar that turns into createElement calls and i don't like that one bit. Hiccup[1] lets me write idiomatic Clojure code that represents DOM tree using convenient data literals and provides all necessary functions to manipulate it - and that i like.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#118Angular is a application framework, Vue is a view library. It's really frustrating to see these two compared, because they have different purposes and intentions. Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc. By the time you slap all of that on top, you may have well just stuck with Angular. I noticed in React by the tim…
Vuex and Vue Router are recommended from the official Vue website, used by most Vue users and work seamlessly together. What else are you missing?
The kind of things I want to build with Vue with Vuex and Vue Router are the same kinds of things I could build with Angular 1 and Angular 2 so the comparison makes sense to me.
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#119I still say Mithril ( https://mithril.js.org/ ) is where it's at. I am at a company now that uses Angular 4.x and I'm not impressed with it. IMO, it's a way to make JS seem more like Spring/Java (especially with Typescript) rather than understand how JS works and use it as it is. Not to mention the learning curve even for senior developers. Mithril took me maybe 30 minutes to understand. The entire source ( https://g…
Re: Why we moved from Angular 2 to Vue.js and why we didn’t choose React
#120Clickbait. The author switched from Angular 2 beta 9 (not even a release candidate) because he was unable to migrate to Angular 2.0.0 since 'too many things broke to make the upgrade non trivial'. Yet somehow rewriting the entire app in Vue is easier?
You'd be surprised how simple it is to re-write an application in Vue. As someone who just finished doing so, I can say that development speed is like nothing I've ever experienced. The application I rebuilt initially took about 2 months to build with React. I rebuilt it with Vue in 2 weeks by myself. I am not venerating Vue, just simply responding to your concerns about rebuilding entire applications.