Need advice about which tool to choose?Ask the StackShare community!
React vs TypeScript: What are the differences?
Markdown code can be used in a website to present content in a structured format, making it easier to read and understand.
**1. Syntax**: React is a JavaScript library for building user interfaces while TypeScript is a superset of JavaScript that adds optional static typing. This means that React focuses on UI development, whereas TypeScript enhances JavaScript by providing static typing.
**2. Type Safety**: React does not enforce strict type checking, leading to potential runtime errors, while TypeScript allows developers to catch type-related errors during compile time, improving code robustness.
**3. Scalability**: React is suitable for smaller projects or parts of larger projects, while TypeScript is better suited for larger codebases, as its type system helps maintain code organization and enables code scalability.
**4. Language Features**: React primarily deals with components and lifecycle methods for building interfaces, whereas TypeScript empowers developers with additional language features like interfaces, enums, and advanced type system capabilities.
**5. Ecosystem Integration**: React can be used with TypeScript by adding TypeScript support to a React project, but TypeScript projects can fully leverage the libraries and tools in the TypeScript ecosystem, providing a broader range of support and functionality.
**6. Learning Curve**: React has a relatively lower learning curve compared to TypeScript, as getting started with React involves basic JavaScript knowledge, while TypeScript requires understanding of static typing concepts and additional language features.
In Summary, React and TypeScript differ in terms of their core focus on UI development vs. static typing, type safety, scalability, language features, ecosystem integration, and learning curve, making them suited for different types of projects and development environments.
What is the best MVC stack to build mobile-friendly, light-weight, and fast single-page application with Spring Boot as back-end (Java)? Is Bootstrap still required to front-end layer these days?
The idea is to host on-premise initially with the potential to move to the cloud. Which combo would have minimal developer ramp-up time and low long-term maintenance costs (BAU support)?
React might be a good option if you're considering a mobile app for the future, because of react native. Although, Vue.js has the easiest learning curve and offers a better developer ramp-up time. Vue.js is great to build SPAs, very clean and organized and you won't have a lot of long-term maintenance problems (like AngularJS, for example). Bootstrap can still be used, but with flexbox there's no need anymore.
I recommend React because of less memory occupant compare to Angular, but this will depend on your organisation flexibility. When you use React you need to import different libraries as per your need. On the other side angular is a complete framework.
Performance-wise I vote for react js as it loads up quickly and lighter on the mobile. You can make good PWA with SSR as well.
If you are new to all three react will be a good choice considering, react-native will be useful if you want to build cross platform mobile application today or tomorrow. If you are talking about bootstrap styling framework than it's a choice you can style ur components by ur self or use bootstrap 4.0 framework. The complete stack mentioned above is platform agnostic u can run it anywhere you want be it cloud or on-premise.
Simple datepickers are cumbersome. For such a simple data input, I feel like it takes far too much effort. Ideally, the native input[type="date"]
would just work like it does on FF and Chrome, but Safari and Edge don't handle it properly. So I'm left either having a diverging experience based on the browser or I need to choose a library to implement a datepicker since users aren't good at inputing formatted strings.
For React alone there are tons of examples to use https://reactjsexample.com/tag/date/. And then of course there's the bootstrap datepicker (https://bootstrap-datepicker.readthedocs.io/en/latest/), jQueryUI calendar picker, https://github.com/flatpickr/flatpickr, and many more.
How do you recommend going about handling date and time inputs? And then there's always moment.js, but I've observed some users getting stuck when presented with a blank text field. I'm curious to hear what's worked well for people...
In my view, the upside of React is you're likely to find more existing, robust design systems (e.g. sets of components containing anything from buttons to datepickers) in the React ecosystem than Vue. UI frameworks aside, momentjs comes in when you want operate on the date(times) you get back from whatever datepicker you choose (e.g. date formatting, date match).
I find using Vue.js to be easier (more concise / less boilerplate) and more intuitive than writing React. However, there are a lot more readily available React components that I can just plug into my projects. I'm debating whether to use Vue.js or React for an upcoming project that I'm going to use to help teach a friend how to build an interactive frontend. Which would you recommend I use?
I've used both Vue.js and React and I would stick with React. I know that Vue.js seems easier to write and its much faster to pick up however as you mentioned above React has way more ready made components you can just plugin, and the community for React is very big.
It might be a bit more of a steep learning curve for your friend to learn React over Vue.js but I think in the long run its the better option.
I chose to use Vue.js a few years ago mainly for the easy learning curve. I have no experience with React, so I won't make any comparison here. Regarding available components, I never felt locked in because of Vue when looking for components. It happens that a component I wish to use is not available as a Vue component (and nobody published any Vue wrapper for it), but in such cases I was able to quickly hack a Vue wrapper component. In the end I don't think a decision to choose one framework over another should be made solely because of the number of components available. (And not all components in either framework is maintained, bug free, documented or easy to use)
I would also go with React. The learning curve can be a little more difficult but as soon as you got the concepts it's really easy to create things. As everybody has mentioned the React community is huge and it keeps growing, anything you may need for your project there are super high probabilities that you will find it.
React is great, Vue.js is also great. But I'm personally using React, because React is changing the way I look at how JavaScript should be. This is a really big plus for me. Vue is good, but it's just another alternative. Also, too many big companies are using React, that means you can trust it for big projects.
I'd have to concur that I'd advise React. In addition to the reasons mentioned, the developer pool is significantly larger (and also slightly more expensive) for React. In time, engineering costs will even out as more and more teams adopt it. The community support is fantastic, and the available components significant.
Would start with Vue especially if you want to progress more quickly and don't want/need to spend time learning React just for the sake of it. You can always pick up React later if necessary. I would caution about using "more readily available React components" just because they exist.
Anything that interacts with the Internet, websites, applications, etc., while it may be more complex to build, will be easier to maintain in the long run. React
offers more flexibility, a much larger support base for knowledge and opinion, and is just as stable asVue
.
To make the best comparison in my opinion, think of React
as the Android OS and Vue
more like iOS. While Vue
may be advantageous in some cases, it is limited by constricting parameters. On the other hand, while React
may be more complex and incorporate more open-source/third-party constructs, it is supported by over 50,000 npm packages and allows for the use of JSX. Which I might add, once learned, becomes second nature to employ and offers more flexibility.
Both have their pro's and con's; however to agree what has been mentioned here before; Using Vue.js will be easier as it's learning curve isn't steep; plus learning Vue.js will teach you fundamentals which (in a sense) can be applied to React as well. Community support for React is indeed very big, but Vue.js is also still growing. Component wise, I wouldn't worry to much about that, writing your own components is also a good tool for learning a language.
Having developed in both Vue.js and React, I agree with your assessment of Vue. It does feel light and easier to understand and therefore learn. Seeing that Vue has some genetic roots with React, I would say start your friend out on Vue. If they need to learn React later, that should give them a good foundation. If you have a Pluralsight subscription, look for my course on Vue.js and feel free to use the demo project as a starting point.
Virtual dom and JSX. Vue is just a baby to the race. React has it's mobile platform version as react native . so it would be easy for you and you wont reinvent the wheel again for mobile apps.
We did a comparison between React, Vue and Angular and while found each capable of supporting our needs, we ended up using VueJS because of its ease of use, the ability to use templates, large and growing community and good documentation. After developing on it for a around 4 months we re-evaluated and agreed that we had made the right choice and continue to migrate our products/platform to it.
I would recommend both of them since Vue is a UI library and helps you to design beautiful website while react allows you to handle backend problems like comment management and onspot reloading more efficiently also react includes useState and react is a framework while vue is a library
As others have stated there are more canned components available for React, but your observation about it's complexity is an important one. There are architectural aspects of Vue.js that lead to cleaner more concise solutions. As React apps get bigger they become a little unwieldy. Depending on your requirements you need to weigh those competing concerns. Our team is using React, but I am beginning to question that choice as time goes on. Another consideration is that Vue.js is becoming more mature as we speak. Also as others join the project, react developers should be productive in Vue.js within days. Just my 2 cents...
It all depends. Vue.js is smaller, and from what I saw (benchmarks) faster. It's also slightly more intuitive and easier to grasp. React is more popular, and the adoption rate is much higher.
Again, it all depends.
If I may, my personal choice would perhaps be either React or Svelte.
VueJS hands down. Which components do you need? Have a look at Vuetify, mature project, plenty of components ready to plug and play. If on the other side you need more customization, have a look at tailwindcss. VueJS is much cleaner and IMO will overtake React soon. It's simply a better React.
It is hard to say which is good. I've used both. Vue is easier. But I feel more comfortable with React. That is why I chose React.
From a StackShare community member: "We are looking to rewrite our outdated front-end with TypeScript. Right now we have a mix of CoffeeScript and vanilla JavaScript. I have read that adopting TypeScript can help enforce better code quality, and best practices. I also heard good things about Flow (JS). Which one would you recommend and why?"
I use TypeScript because:
- incredible developer tooling and community support
- actively developed and supported by Microsoft (yes, I like Microsoft) ;)
- easier to make sense of a TS codebase because the annotations provide so much more context than plain JS
- refactors become easier (VSCode has superb support for TS)
I've switched back and forth between TS and Flow and decided a year ago to abandon Flow completely in favor of TS. I don't want to bash Flow, however, my main grievances are very poor tooling (editor integration leaves much to be desired), a slower release cycle, and subpar docs and community support.
I use TypeScript because it isn't just about validating the types I'm expecting to receive though that is a huge part of it too. Flow (JS) seems to be a type system only. TypeScript also allows you to use the latest features of JavaScript while also providing the type checking. To be fair to Flow (JS), I have not used it, but likely wouldn't have due to the additional features I get from TypeScript.
We originally (in 2017) started rewriting our platform from JavaScript to Flow (JS) but found the library support for Flow was lacking. After switching gears to TypeScript we've never looked back. At this point we're finding that frontend and backend libraries are supporting TypeScript out of the box and where the support is missing that the commuity is typically got a solution in hand.
I use TypeScript because the tooling is more mature (the decision to discontinue TSLint in favor of moving all its checks to ESLint is a thoughtful and mature decision), there's a ton of examples and tutorials for it, and it just generally seems to be where the industry is headed. Flow (JS) is a fine tool, but it just hasn't seen the uptake that TS has, and as a result is lacking a lot of the nicer small things, like thorough Visual Studio Code integration, offered by TS.
We currently use TypeScript at work. Previously we used Flow (JS) but it was sometimes really difficult to make the types work the way you want. Especially non-trivial types were problematic. And the IDE support wasn't good, Flow took too much resources and sometimes remain stuck and do not show errors (I use Visual Studio Code). With TypeScript we almost do not have these problems. IDE support is superb, working with types is much easier and typing system seems more mature and powerful. There are some downsides (like partion inheritance etc.), but TS team is still pushing it forward. So for me TypeScript is clear winner.
We use Underscore because it's a reasonable library for providing all the reasonable helper functions missing from JavaScript ES5 (or that perform poorly if you use the default ES5 version).
Since we're migrating the codebase to TypeScript , we'll likely end up removing most usage of it and ultimately no longer needing it, but we've been very happy with the library.
I use TypeScript for Web Applications and for both frontend and backend because it has a lot of tooling around it and they really got the types and type safety right. Flow (JS) on the other hand lacks tooling and most of the times I scramble to find the right way of building my contracts in which TypeScript is very intuitive and natural. Additionally TypeScript is very similar to Java so your backend engineers and full stack engineers can work with it without much of context switch.
The only time I think Flow shines is (based on probably my outdated knowledge) Flow is/was the only option if you want/wanted to build a React Native application mainly because React Native transpiler at the time I was working with it would only work with flow.
I use TypeScript because it's adoption by many developers, it's supported by many companies, and it's growth. AngularJS, React, @ASP.NET Core. I started using it in .NET Core, then for a job. Later I added more Angular experience and wrote more React software. It makes your code easier to understand and read... which means it makes other people's code easier to understand and read.
If you will start a project from scratch I recommend to use TypeScript. But, If you work with legacy projects written in JavaScript I recommend Flow (JS). Both tools have the same objective: reduce the bad code (which create illegible code, generate bugs e problems to maintenance). Flex helps you to avoid fall in bad codes, but TypeScript prevent you to c you to create bad codes. I believe cause this some JavaScript fans don't like TS, because TS block you to write some types o code. This is the fundamental difference between TS and Flow: Flow avoid problems, but no force. TS force you to prevent problems.
I use TypeScript because it's the most mature/issue-free Javascript type-checker available, as far as I've seen.
I use TypeScript because of broad support, on tools, repos, community ... the only reason to consider flow is if you're a facebook employee
I use TypeScript because I tried both on a Meteor project, and found the quantity of errors it enabled us to catch and the simplification of code it allowed was higher than Flow (JS).
I recommend TypeScript. When used correctly, TypeScript can enable your application to be scalable, easy to refactor, safe, and stable. One of the biggest draws of working with any typed language is that it forces you to think about your functions' inputs and outputs. This is invaluable as it can lead to more declarative, functional style code that ultimately can be easier to reason about.
TypeScript is however not a silver bullet. Just like anything new it takes time to fully understand the concepts of types, interfaces, abstract classes, and enums. In my experience engineers who excel when using TypeScript are those who have experience working with a statically typed language.
I use TypeScript because i love to program in Angular and used in node as well
It was easier to find people who've worked on React than Vue. Angular did not have this problem, but seemed way too bloated compared to React. Angular also brings in restrictions working within their MVC framework. React on the other hand only handles the view/rendering part and rest of the control is left to the developers. React has a very active community, support and has lots of ready-to-use plugins/libraries available.
It is a very versatile library that provides great development speed. Although, with a bad organization, maintaining projects can be a disaster. With a good architecture, this does not happen.
Angular is obviously powerful and robust. I do not rule it out for any future application, in fact with the arrival of micro frontends and cross-functional teams I think it could be useful. However, if I have to build a stack from scratch again, I'm left with react.
Working on a new SaaS web/mobile app and ended up with React as our choice of Frontend JavaScript framework for SPA web version with React Native for iOS, Android, Windows clients.
The key takeaways:
Both frameworks can do the job quite well for us. This might be true for the majority of utility web apps being built out there as well, so there was no "wrong" decision here.
Vue is often cited as easier to learn and code on. But only in case your engineers never worked with either Vue or React and start learning them from scratch. In our case, we knew we'll be hiring engineers who already have experience in the framework we'll select - so it was not a big argument for Vue.
We're building our engineering team in Ukraine and realised we have 3(!) times more engineers with React experience on the market than having Vue experience.
Mobile - React Native, despite being a different framework, still shares a lot with React and it's just easier for React developers to start using React Native in days.
The strongest points for our decision:
React community is larger, means more/faster answers to your questions and existing components.
Way more experienced React engineers on the market.
React + React Native is a great combo if you're building web and mobile clients of the same app.
I used React not just because it is more popular than Angular. But the declarative and composition it gives out of the box is fascinating and React.js is just a very small UI library and you can build anything on top of it.
Composing components is the strongest asset of React for me as it can breakdown your application into smaller pieces which makes it easy to reuse and scale.
Svelte is everything a developer could ever want for flexible, scalable frontend development. I feel like React has reached a maturity level where there needs to be new syntactic sugar added (I'm looking at you, hooks!). I love how Svelte sets out to rebuild a new language to write interfaces in from the ground up.
Our whole Vue.js frontend stack (incl. SSR) consists of the following tools:
- Nuxt.js consisting of Vue CLI, Vue Router, vuex, Webpack and Sass (Bundler for HTML5, CSS 3), Babel (Transpiler for JavaScript),
- Vue Styleguidist as our style guide and pool of developed Vue.js components
- Vuetify as Material Component Framework (for fast app development)
- TypeScript as programming language
- Apollo / GraphQL (incl. GraphiQL) for data access layer (https://apollo.vuejs.org/)
- ESLint, TSLint and Prettier for coding style and code analyzes
- Jest as testing framework
- Google Fonts and Font Awesome for typography and icon toolkit
- NativeScript-Vue for mobile development
The main reason we have chosen Vue.js over React and AngularJS is related to the following artifacts:
- Empowered HTML. Vue.js has many similar approaches with Angular. This helps to optimize HTML blocks handling with the use of different components.
- Detailed documentation. Vue.js has very good documentation which can fasten learning curve for developers.
- Adaptability. It provides a rapid switching period from other frameworks. It has similarities with Angular and React in terms of design and architecture.
- Awesome integration. Vue.js can be used for both building single-page applications and more difficult web interfaces of apps. Smaller interactive parts can be easily integrated into the existing infrastructure with no negative effect on the entire system.
- Large scaling. Vue.js can help to develop pretty large reusable templates.
- Tiny size. Vue.js weights around 20KB keeping its speed and flexibility. It allows reaching much better performance in comparison to other frameworks.
The project is a web gadget previously made using vanilla script and JQuery, It is a part of the "Quicktext" platform and offers an in-app live & customizable messaging widget. We made that remake with React eco-system and Typescript and we're so far happy with results. We gained tons of TS features, React scaling & re-usabilities capabilities and much more!
What do you think?
We are choosing to use TypeScript
over regular JavaScript
as it will allow us to leverage all of JavaScript
’s features while taking advantage of the stronger debugging support and readability of static typing. One of the highlights of TypeScript
is that its features (such as static typing) are entirely optional, meaning that our team can choose to write mostly JavaScript
code, utilizing our existing experience, while taking advantage of TypeScript’s
features when beneficial. While setting up TypeScript
will take a little additional time compared to regular JavaScript, it will ultimately increase our efficiency and productivity.
We chose to use React
due to its excellent selection of third-party libraries, ease-of-use, shallow learning curve, and developer tools/support. Although it is a JavaScript
library, it is completely compatible with TypeScript
. Logistically, it would be advantageous for our team as well since two of our three developers have used it heavily in the past. We will be pairing React
with the Redux
library, which will greatly simplify our React
state management and help increase our code organization. We will also be using the Material-UI
framework, which provides highly configurable components that we can use in our application.
When I started TipMe, I thought about using React frontend. At the end, plain, simple jQuery won.
I had to build this iteration of the site fast and by using jQuery I could keep using Django as a full stack development tool. One important point is Django form (combined with Django Bootstrap3) means that I don't have to reinvent form rendering again, which will be the case with React.
Over time, more interactivity seeped into the site and React components start making its way into the codebase.
I now wish the site is built using React so that I could add more user friendly interfaces easier (no more fuddling with server states) but I would still say jQuery helped me get past those early days.
React has by far and away been our most important library choice throughout the history of Sellpy. It is a library that offers great flexibility supported by a really strong core. The React team is doing incredible work bringing quality features to the core project and tons of quality third party libraries fill in the gaps.
Pros of React
- Components835
- Virtual dom673
- Performance578
- Simplicity508
- Composable442
- Data flow186
- Declarative166
- Isn't an mvc framework128
- Reactive updates120
- Explicit app state115
- JSX50
- Learn once, write everywhere29
- Easy to Use22
- Uni-directional data flow21
- Works great with Flux Architecture17
- Great perfomance11
- Javascript10
- Built by Facebook9
- TypeScript support8
- Speed6
- Scalable6
- Server Side Rendering6
- Props5
- Excellent Documentation5
- Functional5
- Easy as Lego5
- Closer to standard JavaScript and HTML than others5
- Cross-platform5
- Feels like the 90s5
- Easy to start5
- Hooks5
- Awesome5
- Scales super well4
- Allows creating single page applications4
- Server side views4
- Sdfsdfsdf4
- Start simple4
- Strong Community4
- Fancy third party tools4
- Super easy4
- Has arrow functions3
- Very gentle learning curve3
- Beautiful and Neat Component Management3
- Just the View of MVC3
- Simple, easy to reason about and makes you productive3
- Fast evolving3
- SSR3
- Great migration pathway for older systems3
- Rich ecosystem3
- Simple3
- Has functional components3
- Every decision architecture wise makes sense3
- HTML-like2
- Image upload2
- Sharable2
- Recharts2
- Split your UI into components with one true state2
- Permissively-licensed2
- Fragments2
- Datatables1
- React hooks1
Pros of TypeScript
- More intuitive and type safe javascript174
- Type safe106
- JavaScript superset80
- The best AltJS ever48
- Best AltJS for BackEnd27
- Powerful type system, including generics & JS features15
- Compile time errors11
- Nice and seamless hybrid of static and dynamic typing11
- Aligned with ES development for compatibility10
- Angular7
- Structural, rather than nominal, subtyping7
- Starts and ends with JavaScript5
- Garbage collection1
Sign up to add or upvote prosMake informed product decisions
Cons of React
- Requires discipline to keep architecture organized41
- No predefined way to structure your app30
- Need to be familiar with lots of third party packages29
- JSX13
- Not enterprise friendly10
- One-way binding only6
- State consistency with backend neglected3
- Bad Documentation3
- Error boundary is needed2
- Paradigms change too fast2
Cons of TypeScript
- Code may look heavy and confusing5
- Hype4