6 ms·

> 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 wa

• che_shirecat 9y ago
  > 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.
  • erokar 9y ago
    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.
    • mercer 9y ago
      > 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'.
  • christophilus 9y ago
    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.
    • aloisdg 9y ago
      You can use JSX without trouble with Vue
      • sasmithjr 9y ago
        Here's a link for anyone wanting to read more about it: https://vuejs.org/v2/guide/render-function.html#JSX https://vuejs.org/v2/guide/render-function.html#JSX
    • rocky1138 9y ago
      > proprietary templating language Isn't that exactly what JSX is?
      • jsd1982 9y ago
        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.
        • davidjnelson 9y ago
          I wish you could write non string based jsx in angular. Or at least make aot fast enough for the regular webpack watch / recompile workflow.
      • chrisco255 9y ago
        No it's a standard. You can use JSX with Vue 2.0 now, as well as Preact and others.
  • orclev 9y ago
    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.
    • chrisco255 9y ago
      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.
      • orclev 9y ago
        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.
  • root_axis 9y ago
    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.
• mohaine 9y ago
  > 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.
  • nailer 9y ago
    Without arguing one way or the other: - 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.
    • mohaine 9y ago
      > 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.
  • ashark 9y ago
    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.
• vladimir-y 9y ago
  > 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.