My approach for a JS framework or library is that the time I can hope it will be maintained for is at most the time that it has already been maintained. This way, depending on how long my project is supposed to be supported I can make a reasonable choice about what to use.
I call it "JS half-life time".
We moved from Angular 1.3 to Vue.js. Vue came at a right time and I especially liked its ease of use, similarity to Angular and footprint. The most important thing to me personally was the speed and the development feedback cycle.
I like it, a mirror opposite of extreme "designed by committee" practices of big co. funded frameworks.
I feel purposefulness of Vue's design. There are no gigatons of features and behaviors which make you scratch your head and think "why it is there to begin with" like why Ang2 insists on using observer objects for HTTP responses, or why Ang1 had a such an extensive buildover around its component zoo to do just "new mySerice", or reasons for React's component rendering order peculiarities, or logic behind their choice of syntax.
Vue is very bare bones thing. It provides no reactive layer over complex object with non-primitive content. Lack of native support for maps or sets from ES6 is inconvenient a bit, but it is not hard to provide a function wrapper around any logic that uses them. I usually keep all business logic outside of Vue's instance and only wire though its inputs and outputs.
What I lack in all common frameworks is the ability to play smoothly with really complex DOM manipulations, like swapping prototypes of a DOM elements and mergings. Trying to do something like complex drag and drop logic usually means doing a lot of "do it within DOM element, or do it within framework's element" thinking
There may or may not be a large number of people who have the same kind of grasp of the codebase, but because it's so much a single person project it's probably more viable for someone to fork it to a new maintained project in case of disaster.
What happened to jQuery when John Resig focused on other things?
I'm actually hoping Vue.js builds everything needed for a Reactive minimalist framework and then development slows down similar to the speed of jQuery. I think people are sick of frameworks doing overhauls of their entire codebases every major version release.
2 flaws with this article.
1) Using a Beta product and complaining on Angular2. You could have waited till the product is matured
2) Blaming for the developers inefficiency on Typescript. If your developers coding speed is reduced blame on your developers.
Your title and article appears that something is wrong with Angular2 and moved to Vue.js. Before you post such articles make sure what your write makes sense
He cites two articles going into much more detail on the line of thinking regarding the tradeoff that is static typing. I realize this is one of those tab/spaces kinds of religious debates, but hopefully all sides can acknowledge that we are talking tradeoffs and not universal truths. Maybe one day we'll see loose typing as evil as "goto" statements, but the evidence isn't there yet. IMO.
Goto statements still have their fans, and on the other end of the spectrum you'll find people arguing that things like multiple return statements and exceptions are basically the same. It's hard to find absolute truths in computing. I bet there are a few people who'd like us to ditch that whole binary kerfuffle, too.
But yeah, they're trying to be productive in the short term, so it's probably not worth overanalyzing whether a distaste of static typing isn't emblematic of other issues. Getting things rolling has a higher priority...
Goto statements aren't always (or even usually) evil either. Sometimes I get the feeling no one ever really read past the headline of that paper.
Sure, you shouldn't use them unless you really have to, but "really have to" is a line that is difficult to discern. Dijkstra himself noted, "The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one."
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 needless complexity is true. Like every bad framework it makes easy things difficult while at the same time piling on "magic" that's often not useful.
The author is dead wrong on Typescript. Typescript is the best tool I've added to my web development stack in years. Shortly followed by tslint. Once you get used to it the type inference is so good that you only need to even specify the type maybe 1/5 the time.
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
Angular 2 is behind React and Vue in developer satisfaction. And the criticisms levied against NG2 are legitimate. They dropped the ball on a lot of things that were solved a long time ago in React.
Vue, on the other hand, has adopted many of the best features of React and responded well to user feedback. I think it's a strong competitor and I can totally understand someone picking Vue over React. I cannot say the same for NG2.
I think, unlike the author, I had pretty solid reasons why I didn't like it. Most applications are glorified forms on the front-end and Angular2 has the most rigid and difficult form handling I've used in a web framework.
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
> With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript.
TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript. If anything, TypeScript is a bonus.
> React mixes both JSX/HTML with JS code which I just don’t like since I strongly believe in separation of concerns and it looks ugly IMHO.
This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function.
In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern. From Vue.js' documentation: "One important thing to note is that separation of concerns is not equal to separation of file types." [1]
> Coding speed was an area Vue.js won by far, not having to learn JSX was of huge help.
It should take no more than 20 minutes to learn JSX.
> 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 experience and the learning curve is alot nicer. React is overengineering for most web apps.
You are probably right that Angular 1.x devs will ramp up a bit faster in Vue than React. Angular and Vue both add template syntax to HTML, which will be more familiar to Angular devs. However, I do not think initial ramp up time should matter that much, at least not for long running projects. More important questions are: How will the project scale? How easy will it be to maintain?
> React is overengineering for most web apps.
This is a peculiar statement, imo. Have you compared the surface APIs of React and Vue? React's API is much smaller. While Vue might be easier, React comes off as simpler.
> This is a peculiar statement, imo. Have you compared the surface APIs of React and Vue? React's API is much smaller. While Vue might be easier, React comes off as simpler.
This 'simplicity leading to complexity' issue reminds me of the many articles that argue why Lisps aren't more popular precisely because they're so powerful/simple.
I'm not experienced enough to know if the argument has merit, but I have noticed that my React projects often end up rather complex because I need so many extra packages to even get a basic app going (beyond the simple Todo demo apps anyways).
The moment I add an extra package, it's yet another choice to make, and yet another thing that makes my project less accessible to others. Where I might use Redux, others might only have experience with Baobab, Fluxt, Nuxxor, FlimFlam, or whatnot.
This situation does seem to be improving: Redux seems relatively 'safe' and standard enough, for example, and then there's stuff like create-react-app. However using Vue.js is still 'simpler' by having a more standardized ecosystem.
While personally I've always preferred simplicity and love React conceptually, I've definitely become more aware of the drawbacks of having a less standardizes ecosystem to work with. And I can definitely confirm that getting people new to front-end development started is much easier with Vue.js.
I even have a suspicion that the logic-in-template stuff, my reasons for avoiding Vue and Angular in the past, is much easier to 'get' by those who are new to front-end development. I'm not entirely sure why, but it's what I've experienced with all my 'students'.
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.
No. JSX is a small domain-specific language for expressing a hierarchy of virtual DOM nodes. Angular is a template language in that it eschews JavaScript compatibility in favor of its own directives that try to emulate basic iteration and conditional expression evaluation.
I think he meant that in vue.js/angular you have to learn a bunch of proprietary tags for each construct (if, foreach, etc.), whereas in JSX all you need is plain old javascript.
This is probably true, but it's a really poor rationale for choosing a templating* solution. Sure, JSX is slightly easier to pick up than a pure templating solution would be, but that doesn't mean learning modern templating tools is hard. Making already easy things easier isn't much of a win in my book.
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.
> 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
This seems more like a meme than reality. Design is hard. Someone that was able to credentialize in CSS of all things can learn some JS/JSX. Give them some professional courtesy and credit.
Saying that it's "next to impossible" seems kinda toot-my-own-horn dismissive.
Ramp up time shouldn't be the only consideration, in any moderately sized project ramp up time will be dwarfed by other concerns like ease of development. In general, ramp up time is one of the weakest arguments in favor of anything you can make and should only be taken into consideration after all other concerns have been shown to be moot. Likewise the argument about "finding devs". Any competent developer should be able to come up to speed with most anything mainstream relatively quickly, and in the case of junior devs they're often far more willing to invest in learning whatever niche technology you've selected. The quality of developers you hire should be a much larger concern, not the quantity.
As one data point, a number of years back when we needed to hire some frontend developers we actually advertised for Java developers because when we looked for JS devs the quality of candidates we got was abysmal. For another data point, when one company I worked for needed to hire Flex developers (this was a number of years ago) they once again advertised for Java developers, and when I responded asked if I was familiar with and/or willing to learn Flex, which I was. It took me about a month to fully come up to speed with Flex, and I was productive in it within a week.
Is that still true to this day? JS has exploded in popularity and utility in the last few years. Even Stanford and other high quality CS schools are teaching JS now.
Yes, it's in many ways exactly that popularity that's the problem. The ratio of good to mediocre programmers hasn't really changed any, but now there's a whole lot more JS devs out there, so finding the good ones is an exercise in wading through a sea of mediocrity. For better of worse, the Java developer ecosystem does a better job of filtering out the mediocre devs, and generally once you reach a certain level of experience picking up something like JS becomes a trivial exercise. We tend to favor candidates that have experience in multiple languages because it's a strong signal that they're a quality developer, and you tend to find more of that in your backend developer pool, where the frontend developer pool tends to have a lot of experience with a ton of frameworks, but they're all almost exclusively pure javascript focused.
It's a fair point, but by the same token it's usually easier to teach a backend dev good UI design principles, than it is to teach a mediocre frontend dev good programming principles. There's also the fact that for a lot of the kinds of work we're hiring for, there's a creative team producing design documents that the developers are working against, so they don't actually need good UI skills generally (although it certainly can help, particularly when the designers produce things that don't actually work in practice).
If a dev cannot pick up JSX in a day they should be let go. I don't feel this is extreme at all. I'm not saying that React is always the best choice, but JSX is absurdly simple, if it can't be understand very quickly that is a red flag.
> This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function.
I see this so much as an argument against React/JSX. I can not never figure out how putting the display logic in the display template is some how going away from separation of concerns.
As for JXF being hard to learn, that is just silly. Sure there are a few quirks but nothing in comparison to a learning a new templating tag language.
- Traditional SoC: template, styling, and logic for my app are separated
- React/ractive/vue/preact SoC: parts of my app - login boxes, payment areas, order displays - are separated. They may further be separated by template, styling, and logic or not.
You're slicing something vertically vs horizontally.
In practice I prefer one of these but saying which one wouldn't help illustrate the concept.
> Traditional SoC: template, styling, and logic for my app are separated
No, they are not. There is no real difference (other then syntax) between
{ rows.map(r=>(<Row data={r} />)) }
and
<div ng-repeat="r in rows"><Row data={{n}}/></div>
These are both logic that have to be run to display your page. The only real difference is that with JSX, it is easy and powerful enough to use that you could stick some non-display logic in there. Easy and powerful should not be an argument against it.
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 immediately on board with it being called a moron seemingly overnight, I guess because Facebook says it's fine?
Some people have a little whiplash from all that, and I think it's understandable.
It's because it flew in the face of commonly accepted best practices. It felt like a return to PHP/ASP days of old. But in reality, once you use it, you realize it's not that. It's a good abstraction. It puts concerns in the right place. Now, when I have to write something in any .erb file, it's like pulling teeth. JSX + React is a very good view-layer and component abstraction.
I'm not even saying it's a bad idea, just that I think it's entirely understandable that people are a little confused and upset that a decade plus of best practices suddenly did a 180 and they're being looked down on for even taking a second to go, "wait, what?"
Part of what's missing is that separation of concerns doesn't mean not mixing code and markup, it means not mixing your business logic with your rendering logic. One way of enforcing that is to put your rendering logic into a straightjacket and restrict it to very very simple primitives, nothing more complex than a simple for loop over some indexed value or a very primitive form of if/else statement, which is basically what most of the templating systems do. That forces you to keep your business logic out of the view logic because the view rendering system simply isn't powerful enough to express most of your business logic.
It turns out though that when you do that, it becomes really hard to express some more complicated (but perfectly valid) view logic, and then you end up moving a bunch of your view logic down into your business logic which is the same problem, just in the other direction. JSX takes the straightjacket off and gives you the full power of JS to express your view logic. Yes, it also opens the door to let you do bad things like in-lining all your business logic inside of your views, but realistically nobody is doing that, and the framework strongly discourages doing things like that.
This is the unfortunate result of people following "best practices" only because that's what other people do, and not because of some justifiable benefit of said practice.
> It's because it flew in the face of commonly accepted best practices.
People need to stop blindly following current "best practices" because they change all the time. Weigh up the pros and cons yourself. I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes.
Best practices for web app UIs have changed dramatically as we've went from e.g. server side only logic -> jQuery/AJAX based UIs -> Backbone -> Angular 1 -> React. This clearly shows we've no idea what the "best" way to do things is yet.
> I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes.
Don't do that. Perform loops outside of the final template. People get confused because they don't remember that JSX is just a tree of nested React.createElement function calls, so they decide that they should mix looping logic into a block of JSX because that's what they'd do in PHP even though you'd obviously not do that when looking at raw code.
I'm not seeing a huge difference. It's a bit cleaner, similar to how it would look if you did a similar refactor of plain JavaScript code, but it's still very similar. If the logic is short, it's cleaner to inline it sometimes. Going back to my comment, what are the pros and cons or is this just separation based on principle?
> People get confused because they don't remember that JSX is just a tree of nested React.createElement function calls, so they decide that they should mix looping logic into a block of JSX because that's what they'd do in PHP even though you'd obviously not do that when looking at raw code.
Basically what I'm saying is, if you were just writing React.createElement function calls, it'd be more obvious that the items.map should kept out of the rendering code, e.g.
Of course, this is a simplified example, but the more complex the template (i.e. the deeper the nesting) the more the code benefits from having loops and other control structures extracted from the final template.
When a programming expression is made significantly more concise via some abstraction, it can be used in new ways that weren't reasonable before.
JSX makes expressing dynamic, declarative DOM markup concise enough that a short expression such as: `items.map(item => <FooItem item={item}/>` is no longer overly obtuse/obfuscating.
If the `map` expression becomes much larger, it might make sense to refactor it out in some way. But I would argue that the important guiding principle here is readability and modularity. Drawing a hard line between flow/control structures and "template code" is not useful, in my mind.
As others have stated in this thread, the more useful distinction is between business logic and presentation. Loops rightfully exist in both of those domains.
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.
> 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.
> TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript.
If you code in TypeScript and extensively use plain objects and "any" types then you don't get a point of TypeScript and so you better don't use it at all.
> It makes more sense to group code based on function.
The idea of code layers and separation of concern comes form the improving code maintainability and testability ideas. Generally if you code has no layers, then it won't be convenient to unit test it. So it makes sense to group the files based on the function, so you can for example switch the entire function easily, but not putting all the function related sources code to the single file.
> In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern.
Single file components is a term, it's more like junction point for the component's parts, as it allows to reference separate/external files into the component file instead of putting everything inside a single file.
I've been attempting to learn Angular2 and React, but haven't delved into Vue. Angular2 is just different, but it makes more sense to me than 1 if you take the time to learn the concepts. If you go into 2 thinking your 1 skills will translate, then I get why you'd be frustrated. But I found 1 to be very vague conceptually, so many different ways to do the same thing that you end up with many bad implementations. And compared to React, Angular2 is cake imo. There's so much more materials to draw from, and ui libraries to use, and you have to import so much in order to do the same things in React. That may allow for more flexibility, but it makes the learning curve that much more difficult. I'm still not a fan of Typescript, but it seems important to get familiar with ES6.
Also angular-cli and create-react-app are both excellent tools that take a lot of the guess work out of the process, at the very least they show you how to do things right way and keep up to date with what's important.
Angular.X totally lacks of vision. For years it didn't know what it wanted to be, pilling up layers of layers of complexity with IoC containers (useless in a weakly and dynamically typed language such as javascript), Some custom HTML that even needs its own parser, Rx.JS (which is self sufficient if you use it, you literally do not need something on top of that). For what result? it's not faster, snappier in the client, lighter when it comes to the payload, not easier to learn or to test or to use. You don't need some ajax libs either, the fetch API already exists. Angular.X is trying to be the "JEE" of the front-end, except it miss the point of JEE which are a bunch of stable specs, which Angular isn't.
The vision is finally having a good UI kit. Components, templates, lazy loading, isomorphic/universal JS, precompilation, maintainability, code discoverability, ease of team development, testing, etc.
Angular CLI does the compilation, provides the boilerplate management (no need for IDE, if you don't want that), provides the language service (for static checking templates).
Google dogfoods it, they are on the latest rc always. Somehow they can manage the API changes/breaks. (And so far it wasn't much problem for us either.)
I don't know if rx is now a hard or optional dependency, but at least they haven't NIH-ed another Observable lib.
> "We invested in a beta product and then shock horror - it changes before it's released. Let's blame the framework on that poor choice."
Angular.2 has been in beta for years. And when it went out of beta it basically became something else. This is not a good thing. It's normal for teams to be excepting at least some level of stability in the library they are using. And now that Angular.X pretends to be using semver, it's going to be even worse.
The Angular team doesn't care about stability or lacked vision when they started 2, but a stable API is a valid expectation for a developer team.
But it's not surprising as frameworks with huge API surfaces like ExtJS have pulled the same trick for years, with the same results. Their downfall is more the consequence of API breaking than anything else.
> If you rely on a beta product you should have no expectation of API stability.
If i rely on a beta product, i don't expect a complete rewrite of the API when a stable version is released. That's exactly what happened, several times with Angular. Now you can't have it both ways as a vendor. You can't expect people to try out your product and test it in a professional setting then change everything at the last moment either. Or you're saying developers shouldn't even checkout Angular until it is out of beta. If that's what you're saying then the vendor shouldn't expect broad adoption.
I don't know what he's saying, but I would say that you should not have your product depend on something that is subject to change. Thus, although the vendor can do wrong by changing their product API when it is in Beta, it's still ultimately your fault for relying on something that hasn't had a stable release.
Although I get what people are saying about Beta products, the truth is that different vendors use the term "Beta" with different levels of precision, and thus should not typically be trusted not to pull the rug out from under you in some way if they haven't firmly committed to stability.
I have used Google's beta products for years (Gmail for example). You remark is valid for an alpha version, but a beta version should be the final product with maybe bugs to be fixed.
No idea why that comment is getting down voted. Beta can mean different things to different people. We all know google put gmail into beta for years, it was solid for years. That's one example of a product in beta.
But seriously, take a bet on a hip framework and it comes good (like react), good for you . But you can't cry when frameworks change API wildly when they clearly have a beta label on them.
everybody who feels so strongly about separation of code from templates - do you realize that down there it's still just bunch of string concat calls? it's literally what ERB templates in Ruby compile to, and similarly in literally every other template language.
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.
it's one of the reasons i love clojurescript's hiccup so much - i'm still clearly writing idiomatic clojure code but now the boundary is not some arbitrary "this file is named .html and this .js", but actual namespaces/functions, where it's obvious from scope and signature what data my templates depend on.
I got a theory about that. Somewhere along the way our IDEs and code editors trained us that different languages always belong in different files. Eventually people saw this as an aesthetically tidy arrangement to strive for.
Mixing bits of different languages "inline" within the same file got a bad rap despite the fact it was often a sensible approach to organizing common logic together.
You write html inside js? or sql inside python? omg noob!
Ironically I think our tools have programmed us to think/operate in a specific fashion that was convenient for IDE .
My theory is that a lot of us have gone down this road, eventually found the thing getting unwieldy and difficult to maintain, and swearing never again.
Vue 2 allows you to precompile your templates so you're not sending out a bunch of strings of data. Since it uses a virtual DOM, you can use a build tool to compile your templates down to the virtual DOM code to help your application run faster.
Did I suggest mixing presentation and business logic anywhere? My point was that forcing textual representation and another syntactic layer for presentation logic is unnecessary and harmful.
it is valuable to separate, but why is it valuable to force a different syntactic layer, often with heavy constrains on what logic can be expressed which inevitably leaks back into various helpers implemented in the layer you've just separated yourself from? why is it not better to separate using mechanics native to your language?
Templating is a bad term, it implies string generation, which is only a subset of what presentation logic is or is about. Taking that into account - if your presentation language is your program's language - I don't see the problem.
>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 put away and referenced further by the var.
It's another level to have html in-line with JS method calls. The two languages just doesn't jive syntactically
> 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.
DOM is what we're talking about. The fact that it's commonly represented by HTML and that somehow influenced how we ought to create/manipulate it in our code is exactly the problem.
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.
It's always a bit strange when someone chooses a framework based on how far they get in a few hours or days of testing. For medium sized or larger projects it's much more interesting how it will work long term with a large code base.
I'm not saying that Vue is no good or that it was not a good choice for the author, but the way he described their process makes me think that they optimized the wrong thing.
Maybe my viewpoint is too 'elitist' or something, but I have a hard time taking this seriously when one of the chief complaints of Typescript is that it is too "difficult"
It really makes me question the validity of the rest of the points.
Typescript is not difficult, it just solves problems almost no one has, and makes you do silly things that slow you down. Difficult like in 'petulant child' difficult, not 'what woman want' difficult.
While I understand the preference for not wanting it, it is a very "high-level" sort of complaint, and the rest of the points seem similarly "high-level."
They could all be valid points, but I wouldn't take any of them purely at face value.
Angular 2 in beta made bold claims about being 'production ready' which reads 'almost done', it was frustrating just how long it then took to become what I would consider production ready.
I consider Angular 4 the first release to produce just about acceptable sized app bundle. On the whole though it's a very ambitious project and I think it will be increasingly hard to ignore, we've currently no intention of changing framework.
I think this had to more to do with internal pressures at Google than the actual state of the code. They had been working on it for a long time, and, I think were under some pressure to actually ship something. Angular v4 is what the first production version should have looked like.
Having just upgraded a large AngularJS v1 project to Angular v4, I'm actually very happy with where it's ended up. It feels like a very good combination of power and flexibility. There are still some complex bits, but it feels more like the complexity is necessary and sanely designed, rather than the craziness of what AngularJS's directive stuff evolved into.
> With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript.
Sure defining a simple JS object has no overhead as opposed to maybe the 15-30 seconds of overhead that creating the Typescript interface entails. But that few additional seconds of overhead gives you this for rest of the (weeks, months and years) of the systems lifetime:
1. Instant IDE/editor code completion and error checking
2. Compile time checked contracts when that object is passed to another function
3. Compile time checks for misspelled or non-existent members of the object.
4. Instant refactoring of member names across files with any number of editors and IDEs
5. A chance to take a little higher level look at the design of your system.
After using Typescript for a couple of years now I've found that when I design my types well the overall design and flow of the system tends towards beauty. That is probably why the Haskell folks are always over on the sidelines smirking.
Clickbait. 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.
I did a rewrite from Angular 1 to Vue recently and it didn't take long at all plus it fixed a bunch of bugs that were problematic to fix in Angular. If you write your Angular 1 code in component style, moving them to Vue is pretty straightforward and a lot of the template conversions just involve changing keywords (e.g. ng-if -> v-if).
Have been using angular 1 and I so wish that I had used vue instead. vue is easy and intuitive compared to angular bloat. May be will take less than half hour to understand basics coming from angular.
I wonder why nowadays anyone would choose React and give away all patent rights to the E̶v̶i̶l̶ ̶c̶o̶r̶p̶o̶r̶a̶t̶i̶o̶n̶ Facebook (or not, in which case one would need to rewrite the app completely, since he cannot use React anymore). This alone should make choice way easier, if you decided to not use Angular anyway.
> I didn’t feel Typescript added substantial value and even worse, we noticed that our coding speed was reduced. With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. I highly recommend you to read the following articles before you start using Typescript. It is not the right solution for everyone.
If you read the linked article, it's using a graph of the number of GitHub issues labelled "bug" to justify that languages with strong static types don't reduce the number of bugs which isn't meaningful or convincing...
> The main thing we didn’t like and we still don’t like about Angular 2 is Typescript. I know Angular 2 can be used with Javascript but again, the decision to use Typescript was already taken and from what I understand, using pure Javascript with Angular 2 is not the ideal way you should be using Angular 2. In any case, getting rid of Typescript meant a full rewrite of the project.
...
> I still remember how easy to work with Angular 1 was, it certainly had it’s own problems, but it was nice to work with it compared to other frameworks, something that Angular 2 lost somewhere on the way.
I recently moved from Angular 1 because it didn't work well with TypeScript. The rest of my project was in TypeScript and all the bugs were coming from the Angular 1 layer because there was no static checking there.
TypeScript is an enormous improvement over plain JavaScript in my opinion in terms of productivity (better refactoring, better autocomplete) and making your code more robust (no unexpected null/undefined variables, no more mixing up strings and arrays). Ignoring TypeScript for large projects is a big mistake.
Angular 2 felt too verbose and overly complex so I switched to Vue which has decent add ons to work with TypeScript. If you use JSX for Vue templates as well, you get type checking for your templates.
The thing I find amusing about posts like these is that they come about once every 18 months. Just substitute the left framework for last years shiny and the right for the latest shiny. We developers are nothing if not consistent in our ability to chase the latest shiny. I do wish more developers would take the time to master languages instead of learning new frameworks though.
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://github.com/MithrilJS/mithril.js) is easily read in a few hours. They have multiple committers and an active gitter chat room for any problems. Plus you can use JSX if you like it that much. And it has a nice license.
I'm using Mithril with TypeScript. It's a great combo. All my Mithril views are stateless and TypeScript makes sure I pass down properly the arguments to the view. It feels almost like I'm writing Elm. Almost.
Are you not at a disadvantage with it having a smaller community or is there enough content out there? I like to support new innovations but knowing I can easily find a prewritten component for Vue or Angular is a big selling point.
I never felt like I had any problems, to be honest. It was so quick and easy to write things, I never worried. There are a decent amount of plugins out there on github, though. Give it a shot!
I envy how some companies can migrate from one to another framework like that.
Beside that, TypeScript is just fine once you get more time with it, you don't need to type everything.
On the other side I find Angular more stable framework on the long run.
In his comparison matrix, why was Reactivity a criteria? Why did Angular score a "Kind-of"? Reactivity is just another word for the framework's underlying change detection logic. Obviously all of these frameworks have that. The fact that he put the term "reactivity" up on a pedestal and rated angular down tells me the lack of understanding on the author's side
150 comments
[ 4.2 ms ] story [ 236 ms ] threadThe speed at which these frameworks pop up is almost exhausting.
[0] https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...
I feel purposefulness of Vue's design. There are no gigatons of features and behaviors which make you scratch your head and think "why it is there to begin with" like why Ang2 insists on using observer objects for HTTP responses, or why Ang1 had a such an extensive buildover around its component zoo to do just "new mySerice", or reasons for React's component rendering order peculiarities, or logic behind their choice of syntax.
Vue is very bare bones thing. It provides no reactive layer over complex object with non-primitive content. Lack of native support for maps or sets from ES6 is inconvenient a bit, but it is not hard to provide a function wrapper around any logic that uses them. I usually keep all business logic outside of Vue's instance and only wire though its inputs and outputs.
What I lack in all common frameworks is the ability to play smoothly with really complex DOM manipulations, like swapping prototypes of a DOM elements and mergings. Trying to do something like complex drag and drop logic usually means doing a lot of "do it within DOM element, or do it within framework's element" thinking
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I'm actually hoping Vue.js builds everything needed for a Reactive minimalist framework and then development slows down similar to the speed of jQuery. I think people are sick of frameworks doing overhauls of their entire codebases every major version release.
But yeah, they're trying to be productive in the short term, so it's probably not worth overanalyzing whether a distaste of static typing isn't emblematic of other issues. Getting things rolling has a higher priority...
https://en.wikipedia.org/wiki/Setun
Knuth has also hypothesized that we may one day start producing ternary computers again due to their efficiency and elegance.
Sure, you shouldn't use them unless you really have to, but "really have to" is a line that is difficult to discern. Dijkstra himself noted, "The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one."
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 needless complexity is true. Like every bad framework it makes easy things difficult while at the same time piling on "magic" that's often not useful.
The author is dead wrong on Typescript. Typescript is the best tool I've added to my web development stack in years. Shortly followed by tslint. Once you get used to it the type inference is so good that you only need to even specify the type maybe 1/5 the time.
Vue, on the other hand, has adopted many of the best features of React and responded well to user feedback. I think it's a strong competitor and I can totally understand someone picking Vue over React. I cannot say the same for NG2.
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
TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript. If anything, TypeScript is a bonus.
> React mixes both JSX/HTML with JS code which I just don’t like since I strongly believe in separation of concerns and it looks ugly IMHO.
This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function.
In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern. From Vue.js' documentation: "One important thing to note is that separation of concerns is not equal to separation of file types." [1]
> Coding speed was an area Vue.js won by far, not having to learn JSX was of huge help.
It should take no more than 20 minutes to learn JSX.
1. https://vuejs.org/v2/guide/single-file-components.html#What-...
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 experience and the learning curve is alot nicer. React is overengineering for most web apps.
> React is overengineering for most web apps.
This is a peculiar statement, imo. Have you compared the surface APIs of React and Vue? React's API is much smaller. While Vue might be easier, React comes off as simpler.
This 'simplicity leading to complexity' issue reminds me of the many articles that argue why Lisps aren't more popular precisely because they're so powerful/simple.
I'm not experienced enough to know if the argument has merit, but I have noticed that my React projects often end up rather complex because I need so many extra packages to even get a basic app going (beyond the simple Todo demo apps anyways).
The moment I add an extra package, it's yet another choice to make, and yet another thing that makes my project less accessible to others. Where I might use Redux, others might only have experience with Baobab, Fluxt, Nuxxor, FlimFlam, or whatnot.
This situation does seem to be improving: Redux seems relatively 'safe' and standard enough, for example, and then there's stuff like create-react-app. However using Vue.js is still 'simpler' by having a more standardized ecosystem.
While personally I've always preferred simplicity and love React conceptually, I've definitely become more aware of the drawbacks of having a less standardizes ecosystem to work with. And I can definitely confirm that getting people new to front-end development started is much easier with Vue.js.
I even have a suspicion that the logic-in-template stuff, my reasons for avoiding Vue and Angular in the past, is much easier to 'get' by those who are new to front-end development. I'm not entirely sure why, but it's what I've experienced with all my 'students'.
Isn't that exactly what JSX is?
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.
This seems more like a meme than reality. Design is hard. Someone that was able to credentialize in CSS of all things can learn some JS/JSX. Give them some professional courtesy and credit.
Saying that it's "next to impossible" seems kinda toot-my-own-horn dismissive.
As one data point, a number of years back when we needed to hire some frontend developers we actually advertised for Java developers because when we looked for JS devs the quality of candidates we got was abysmal. For another data point, when one company I worked for needed to hire Flex developers (this was a number of years ago) they once again advertised for Java developers, and when I responded asked if I was familiar with and/or willing to learn Flex, which I was. It took me about a month to fully come up to speed with Flex, and I was productive in it within a week.
I see this so much as an argument against React/JSX. I can not never figure out how putting the display logic in the display template is some how going away from separation of concerns.
As for JXF being hard to learn, that is just silly. Sure there are a few quirks but nothing in comparison to a learning a new templating tag language.
- Traditional SoC: template, styling, and logic for my app are separated
- React/ractive/vue/preact SoC: parts of my app - login boxes, payment areas, order displays - are separated. They may further be separated by template, styling, and logic or not.
You're slicing something vertically vs horizontally.
In practice I prefer one of these but saying which one wouldn't help illustrate the concept.
No, they are not. There is no real difference (other then syntax) between
{ rows.map(r=>(<Row data={r} />)) }
and
<div ng-repeat="r in rows"><Row data={{n}}/></div>
These are both logic that have to be run to display your page. The only real difference is that with JSX, it is easy and powerful enough to use that you could stick some non-display logic in there. Easy and powerful should not be an argument against it.
Some people have a little whiplash from all that, and I think it's understandable.
It turns out though that when you do that, it becomes really hard to express some more complicated (but perfectly valid) view logic, and then you end up moving a bunch of your view logic down into your business logic which is the same problem, just in the other direction. JSX takes the straightjacket off and gives you the full power of JS to express your view logic. Yes, it also opens the door to let you do bad things like in-lining all your business logic inside of your views, but realistically nobody is doing that, and the framework strongly discourages doing things like that.
People need to stop blindly following current "best practices" because they change all the time. Weigh up the pros and cons yourself. I personally don't see any difference with doing a loop in JSX and doing a loop in HTML using special tag attributes.
Best practices for web app UIs have changed dramatically as we've went from e.g. server side only logic -> jQuery/AJAX based UIs -> Backbone -> Angular 1 -> React. This clearly shows we've no idea what the "best" way to do things is yet.
Don't do that. Perform loops outside of the final template. People get confused because they don't remember that JSX is just a tree of nested React.createElement function calls, so they decide that they should mix looping logic into a block of JSX because that's what they'd do in PHP even though you'd obviously not do that when looking at raw code.
It's as simple as that. There is never a reason to mix logic into the "template" part of the component.Basically what I'm saying is, if you were just writing React.createElement function calls, it'd be more obvious that the items.map should kept out of the rendering code, e.g.
Of course, this is a simplified example, but the more complex the template (i.e. the deeper the nesting) the more the code benefits from having loops and other control structures extracted from the final template.JSX makes expressing dynamic, declarative DOM markup concise enough that a short expression such as: `items.map(item => <FooItem item={item}/>` is no longer overly obtuse/obfuscating.
If the `map` expression becomes much larger, it might make sense to refactor it out in some way. But I would argue that the important guiding principle here is readability and modularity. Drawing a hard line between flow/control structures and "template code" is not useful, in my mind.
As others have stated in this thread, the more useful distinction is between business logic and presentation. Loops rightfully exist in both of those domains.
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.
If you code in TypeScript and extensively use plain objects and "any" types then you don't get a point of TypeScript and so you better don't use it at all.
> It makes more sense to group code based on function.
The idea of code layers and separation of concern comes form the improving code maintainability and testability ideas. Generally if you code has no layers, then it won't be convenient to unit test it. So it makes sense to group the files based on the function, so you can for example switch the entire function easily, but not putting all the function related sources code to the single file.
> In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern.
Single file components is a term, it's more like junction point for the component's parts, as it allows to reference separate/external files into the component file instead of putting everything inside a single file.
Also angular-cli and create-react-app are both excellent tools that take a lot of the guess work out of the process, at the very least they show you how to do things right way and keep up to date with what's important.
Angular.X totally lacks of vision. For years it didn't know what it wanted to be, pilling up layers of layers of complexity with IoC containers (useless in a weakly and dynamically typed language such as javascript), Some custom HTML that even needs its own parser, Rx.JS (which is self sufficient if you use it, you literally do not need something on top of that). For what result? it's not faster, snappier in the client, lighter when it comes to the payload, not easier to learn or to test or to use. You don't need some ajax libs either, the fetch API already exists. Angular.X is trying to be the "JEE" of the front-end, except it miss the point of JEE which are a bunch of stable specs, which Angular isn't.
Angular CLI does the compilation, provides the boilerplate management (no need for IDE, if you don't want that), provides the language service (for static checking templates).
Google dogfoods it, they are on the latest rc always. Somehow they can manage the API changes/breaks. (And so far it wasn't much problem for us either.)
I don't know if rx is now a hard or optional dependency, but at least they haven't NIH-ed another Observable lib.
"We were unable to learn how to use TypeScript properly, so let's abandon gradual typing and suffer a net loss in productivity over the longer term."
Angular.2 has been in beta for years. And when it went out of beta it basically became something else. This is not a good thing. It's normal for teams to be excepting at least some level of stability in the library they are using. And now that Angular.X pretends to be using semver, it's going to be even worse.
The Angular team doesn't care about stability or lacked vision when they started 2, but a stable API is a valid expectation for a developer team.
But it's not surprising as frameworks with huge API surfaces like ExtJS have pulled the same trick for years, with the same results. Their downfall is more the consequence of API breaking than anything else.
It's very easy to blame vendors when it's your own poor decision making that got you in the mess to begin with.
If i rely on a beta product, i don't expect a complete rewrite of the API when a stable version is released. That's exactly what happened, several times with Angular. Now you can't have it both ways as a vendor. You can't expect people to try out your product and test it in a professional setting then change everything at the last moment either. Or you're saying developers shouldn't even checkout Angular until it is out of beta. If that's what you're saying then the vendor shouldn't expect broad adoption.
Although I get what people are saying about Beta products, the truth is that different vendors use the term "Beta" with different levels of precision, and thus should not typically be trusted not to pull the rug out from under you in some way if they haven't firmly committed to stability.
But seriously, take a bet on a hip framework and it comes good (like react), good for you . But you can't cry when frameworks change API wildly when they clearly have a beta label on them.
Yes, using a small lib will get you initially there, but then there will be a full rewrite of that too, or it'll become completely abandoned, etc.
Angular at least has some idea of upgrade path.
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.
it's one of the reasons i love clojurescript's hiccup so much - i'm still clearly writing idiomatic clojure code but now the boundary is not some arbitrary "this file is named .html and this .js", but actual namespaces/functions, where it's obvious from scope and signature what data my templates depend on.
Mixing bits of different languages "inline" within the same file got a bad rap despite the fact it was often a sensible approach to organizing common logic together.
You write html inside js? or sql inside python? omg noob!
Ironically I think our tools have programmed us to think/operate in a specific fashion that was convenient for IDE .
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 put away and referenced further by the var.
It's another level to have html in-line with JS method calls. 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.
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.
[1] https://github.com/weavejester/hiccup
I'm not saying that Vue is no good or that it was not a good choice for the author, but the way he described their process makes me think that they optimized the wrong thing.
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.
It really makes me question the validity of the rest of the points.
They could all be valid points, but I wouldn't take any of them purely at face value.
I consider Angular 4 the first release to produce just about acceptable sized app bundle. On the whole though it's a very ambitious project and I think it will be increasingly hard to ignore, we've currently no intention of changing framework.
Having just upgraded a large AngularJS v1 project to Angular v4, I'm actually very happy with where it's ended up. It feels like a very good combination of power and flexibility. There are still some complex bits, but it feels more like the complexity is necessary and sanely designed, rather than the craziness of what AngularJS's directive stuff evolved into.
Sure defining a simple JS object has no overhead as opposed to maybe the 15-30 seconds of overhead that creating the Typescript interface entails. But that few additional seconds of overhead gives you this for rest of the (weeks, months and years) of the systems lifetime:
After using Typescript for a couple of years now I've found that when I design my types well the overall design and flow of the system tends towards beauty. That is probably why the Haskell folks are always over on the sidelines smirking.Can anybody share experience with nuxt.js ?
Who has source code in native HTML lying around?
If you read the linked article, it's using a graph of the number of GitHub issues labelled "bug" to justify that languages with strong static types don't reduce the number of bugs which isn't meaningful or convincing...
> The main thing we didn’t like and we still don’t like about Angular 2 is Typescript. I know Angular 2 can be used with Javascript but again, the decision to use Typescript was already taken and from what I understand, using pure Javascript with Angular 2 is not the ideal way you should be using Angular 2. In any case, getting rid of Typescript meant a full rewrite of the project. ... > I still remember how easy to work with Angular 1 was, it certainly had it’s own problems, but it was nice to work with it compared to other frameworks, something that Angular 2 lost somewhere on the way.
I recently moved from Angular 1 because it didn't work well with TypeScript. The rest of my project was in TypeScript and all the bugs were coming from the Angular 1 layer because there was no static checking there.
TypeScript is an enormous improvement over plain JavaScript in my opinion in terms of productivity (better refactoring, better autocomplete) and making your code more robust (no unexpected null/undefined variables, no more mixing up strings and arrays). Ignoring TypeScript for large projects is a big mistake.
Angular 2 felt too verbose and overly complex so I switched to Vue which has decent add ons to work with TypeScript. If you use JSX for Vue templates as well, you get type checking for your templates.
Not to mention the learning curve even for senior developers. Mithril took me maybe 30 minutes to understand. The entire source (https://github.com/MithrilJS/mithril.js) is easily read in a few hours. They have multiple committers and an active gitter chat room for any problems. Plus you can use JSX if you like it that much. And it has a nice license.
More folks need to try it out.
http://cl.ly/2I2r2S2v171T
In his comparison matrix, why was Reactivity a criteria? Why did Angular score a "Kind-of"? Reactivity is just another word for the framework's underlying change detection logic. Obviously all of these frameworks have that. The fact that he put the term "reactivity" up on a pedestal and rated angular down tells me the lack of understanding on the author's side