Semantic UI vs TypeScript

Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Semantic UI
Semantic UI

613
610
+ 1
578
TypeScript
TypeScript

10.6K
7.9K
+ 1
400
Add tool

Semantic UI vs TypeScript: What are the differences?

Developers describe Semantic UI as "A UI Component library implemented using a set of specifications designed around natural language". Semantic empowers designers and developers by creating a shared vocabulary for UI. On the other hand, TypeScript is detailed as "A superset of JavaScript that compiles to clean JavaScript output". TypeScript is a language for application-scale JavaScript development. It's a typed superset of JavaScript that compiles to plain JavaScript.

Semantic UI and TypeScript are primarily classified as "Front-End Frameworks" and "Templating Languages & Extensions" tools respectively.

"Easy to use and looks elegant", "Variety of components" and "Themes" are the key factors why developers consider Semantic UI; whereas "More intuitive and type safe javascript", "Type safe" and "JavaScript superset" are the primary reasons why TypeScript is favored.

Semantic UI and TypeScript are both open source tools. It seems that TypeScript with 50.5K GitHub stars and 6.98K forks on GitHub has more adoption than Semantic UI with 45.7K GitHub stars and 4.83K GitHub forks.

According to the StackShare community, TypeScript has a broader approval, being mentioned in 954 company stacks & 1390 developers stacks; compared to Semantic UI, which is listed in 77 company stacks and 50 developer stacks.

What is Semantic UI?

Semantic empowers designers and developers by creating a shared vocabulary for UI.

What is TypeScript?

TypeScript is a language for application-scale JavaScript development. It's a typed superset of JavaScript that compiles to plain JavaScript.
Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Why do developers choose Semantic UI?
Why do developers choose TypeScript?

Sign up to add, upvote and see more prosMake informed product decisions

    Be the first to leave a con
      Be the first to leave a con
      Jobs that mention Semantic UI and TypeScript as a desired skillset
      OneSignalOneSignal
      San Mateo, California
      OneSignalOneSignal
      San Mateo, California
      OneSignalOneSignal
      San Mateo, California
      What companies use Semantic UI?
      What companies use TypeScript?

      Sign up to get full access to all the companiesMake informed product decisions

      What tools integrate with Semantic UI?
      What tools integrate with TypeScript?

      Sign up to get full access to all the tool integrationsMake informed product decisions

      What are some alternatives to Semantic UI and TypeScript?
      Bootstrap
      Bootstrap is the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web.
      UIkIt
      UIkit gives you a comprehensive collection of HTML, CSS, and JS components which is simple to use, easy to customize and extendable.
      Ant Design
      An enterprise-class UI design language and React-based implementation. Graceful UI components out of the box, base on React Component. A npm + webpack + babel + dora + dva development framework.
      Material-UI
      It is a comprehensive guide for visual, motion, and interaction design across platforms and devices.
      Animate.css
      It is a bunch of cool, fun, and cross-browser animations for you to use in your projects. Great for emphasis, home pages, sliders, and general just-add-water-awesomeness.
      See all alternatives
      Decisions about Semantic UI and TypeScript
      Eli Hooten
      Eli Hooten
      CTO at Codecov · | 11 upvotes · 55.7K views
      atCodecovCodecov
      Visual Studio Code
      Visual Studio Code
      Vue.js
      Vue.js
      CoffeeScript
      CoffeeScript
      JavaScript
      JavaScript
      TypeScript
      TypeScript

      We chose TypeScript at Codecov when undergoing a recent rewrite of a legacy front end. Our previous front end was a mishmash of vanilla JavaScript and CoffeeScript , and was expanded upon haphazardly as the need arose. Without a unifying set of paradigms and patterns, the CoffeeScript and JavaScript setup was proving hard to maintain and expand upon by an engineering team. During a move to Vue.js , we decided to also make the move to TypeScript. Integrating TypeScript and Vue.js is fairly well understood at this point, so the setup wasn't all that difficult, and we felt that the benefits of incorporating TypeScript would outweigh the required time to set it up and get our engineering team up to speed.

      Choosing to add TypeScript has given us one more layer to rely on to help enforce code quality, good standards, and best practices within our engineering organization. One of the biggest benefits for us as an engineering team has been how well our IDEs and editors (e.g., Visual Studio Code ) integrate with and understand TypeScript . This allows developers to catch many more errors at development time instead of relying on run time. The end result is safer (from a type perspective) code and a more efficient coding experience that helps to catch and remove errors with less developer effort.

      See more
      Koa
      Koa
      React Router
      React Router
      Foundation
      Foundation
      Semantic UI
      Semantic UI
      Bootstrap
      Bootstrap
      PostCSS
      PostCSS
      Less
      Less
      Sass
      Sass
      styled-components
      styled-components
      React Helmet
      React Helmet
      Webpack
      Webpack
      TypeScript
      TypeScript
      JavaScript
      JavaScript
      Apollo
      Apollo
      GraphQL
      GraphQL
      React
      React
      #JSX
      #React.
      #Css
      #StyledComponents.
      #Async
      #HTML
      #GraphQL
      #Apollo

      ReactQL is a React + GraphQL front-end starter kit. #JSX is a natural way to think about building UI, and it renders to pure #HTML in the browser and on the server, making it trivial to build server-rendered Single Page Apps. GraphQL via Apollo was chosen for the data layer; #GraphQL makes it simple to request just the data your app needs, and #Apollo takes care of communicating with your API (written in any language; doesn't have to be JavaScript!), caching, and rendering to #React.

      ReactQL is written in TypeScript to provide full types/Intellisense, and pick up hard-to-diagnose goofs that might later show up at runtime. React makes heavy use of Webpack 4 to handle transforming your code to an optimised client-side bundle, and in throws back just enough code needed for the initial render, while seamlessly handling import statements asynchronously as needed, making the payload your user downloads ultimately much smaller than trying to do it by hand.

      React Helmet was chosen to handle <head> content, because it works universally, making it easy to throw back the correct <title> and other tags on the initial render, as well as inject new tags for subsequent client-side views.

      styled-components, Sass, Less and PostCSS were added to give developers a choice of whether to build styles purely in React / JavaScript, or whether to defer to a #css #preprocessor. This is especially useful for interop with UI frameworks like Bootstrap, Semantic UI, Foundation, etc - ReactQL lets you mix and match #css and renders to both a static .css file during bundling as well as generates per-page <style> tags when using #StyledComponents.

      React Router handles routing, because it works both on the server and in the client. ReactQL customises it further by capturing non-200 responses on the server, redirecting or throwing back custom 404 pages as needed.

      Koa is the web server that handles all incoming HTTP requests, because it's fast (TTFB < 5ms, even after fully rendering React), and its natively #async, making it easy to async/await inside routes and middleware.

      See more
      React Native
      React Native
      Java
      Java
      Flow (JS)
      Flow (JS)
      TypeScript
      TypeScript

      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.

      See more
      Flow (JS)
      Flow (JS)
      TypeScript
      TypeScript

      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.

      See more
      David Koblas
      David Koblas
      VP Engineering at Payment Rails · | 9 upvotes · 8.2K views
      atPayment RailsPayment Rails
      TypeScript
      TypeScript
      Flow (JS)
      Flow (JS)
      JavaScript
      JavaScript

      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.

      See more
      Forrest Norvell
      Forrest Norvell
      engineering manager at self-employed · | 6 upvotes · 17.1K views
      Visual Studio Code
      Visual Studio Code
      Flow (JS)
      Flow (JS)
      ESLint
      ESLint
      TSLint
      TSLint
      TypeScript
      TypeScript

      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.

      See more
      Visual Studio Code
      Visual Studio Code
      Flow (JS)
      Flow (JS)
      TypeScript
      TypeScript

      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.

      See more
      JavaScript
      JavaScript
      Flow (JS)
      Flow (JS)
      TypeScript
      TypeScript

      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.

      See more
      .NET Core
      .NET Core
      React
      React
      AngularJS
      AngularJS
      TypeScript
      TypeScript

      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.

      See more
      TypeScript
      TypeScript

      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.

      See more
      Gustavo Muñoz
      Gustavo Muñoz
      Web UI Developer at Globant · | 2 upvotes · 5.3K views
      CoffeeScript
      CoffeeScript
      JavaScript
      JavaScript
      Flow (JS)
      Flow (JS)
      React
      React
      TypeScript
      TypeScript
      Angular 2
      Angular 2
      #ECMA
      #Angular

      Long ago when Angular 2 evolved I had to decide between the new #Angular and TypeScript or React. I really love typing my code, but forced to use TypeScript was a bit too much. I prefer the new #ECMA standard and the evolution of the old and reliable JavaScript. So finding Flow (JS) was an incredible milestone in my career as a developer. Finally, I could use types in my code, and JavaScript with the new standard. I already had the experience of CoffeeScript, so TypeScript was not an option.

      See more
      Flow (JS)
      Flow (JS)
      JavaScript
      JavaScript
      CoffeeScript
      CoffeeScript
      TypeScript
      TypeScript

      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?"

      See more
      Jason Barry
      Jason Barry
      Cofounder at FeaturePeek · | 4 upvotes · 10.6K views
      atFeaturePeekFeaturePeek
      npm
      npm
      Yarn
      Yarn
      Babel
      Babel
      Sublime Text
      Sublime Text
      JavaScript
      JavaScript
      React
      React
      TypeScript
      TypeScript
      Flow (JS)
      Flow (JS)
      #Frontend

      I think our #Frontend stack is pretty standard – but we have taken some deviations from a typical modern stack:

      • Flow (JS) instead of TypeScript. Flow was an easy choice 2+ years ago, as both flow and React were (and still are) maintained by Facebook. Today, it seems that the JavaScript community has settled on TypeScript as the winner. For new projects, I'd choose TS, but I don't see the point in migrating an existing project from flowtype to TS, when the end result will be roughly the same. Sure, memory usage is a bit high, and every now and then I have to kill some zombie processes, but our text editors (Sublime Text), CI scripts, and Babel are already set up to take advantage of the type safety that flow offers. When/if the React team writes React itself in TS, then I'll take a closer look – until then, flow works for us.

      • Yarn instead of npm. When yarn debuted, we never looked back. Now npm has pretty much caught up with speed and lockfiles, but yarn gives me confidence that my dependency installs are deterministic. Really interested in the plug-n-play (PnP) feature that removes the need for a node_modules folder, but haven't implemented this yet.

      See more
      Interest over time
      Reviews of Semantic UI and TypeScript
      Avatar of lpellegr
      Noticeable
      Review ofTypeScriptTypeScript

      Typed JavaScript is just fantastic for medium to large size projects. The type system is well thought and compatible with standard JavaScript. Almost any new Javascript-based development should use TypeScript to save time and prevent technical debt over time.

      How developers use Semantic UI and TypeScript
      Avatar of NewCraft
      NewCraft uses TypeScriptTypeScript

      Typescript has been a win because, in general, it makes codebase maintenance less brittle. It's significantly easier to refactor in TS than JS, which encourages incremental improvements, file re-organizing, etc. Our developers are happier with the overall development experience.

      The downside is that TS sometimes exacerbates problems caused by Node's fragmented ecosystem. Sometimes @types/ don't work, other times types are outdated. This can lead to problems with newly-installed libraries.

      If your project is big enough, I'd say TS is nearly always worth it, but it can make selecting libraries a pain.

      Avatar of Matt Welke
      Matt Welke uses TypeScriptTypeScript

      Used for Node.js personal projects that I think will have a longer lifetime than others, or that are combined with a web front end component like Angular (to share types).

      Generally a poor developer experience. Usage decreasing recently compared to other preferred programming languages/platforms.

      Avatar of Marc3842h
      Marc3842h uses TypeScriptTypeScript

      TypeScript is used in Kuro (https://github.com/Marc3842h/kuro).

      Kuro is the browser facing portion of shiro. Typescript is the language in which the web server and the frontend scripts are written in. They later get compiled down to vanilla JavaScript.

      Avatar of John Harris
      John Harris uses TypeScriptTypeScript

      Excellent design-time type checking and the ability for the Typescript compiler to attach typing information to metadata at compile time allows for relatively simple type checking at run-time as well.

      Avatar of Blood Bot
      Blood Bot uses TypeScriptTypeScript

      We, our team can sleep comfortable at night know "x is undefined" will not occur in production. It's also really helpful as IDE help in code completion when they know types.

      Avatar of osu! Ripple
      osu! Ripple uses Semantic UISemantic UI

      We use Semantic UI for our frotend. A heavily customised version of it, but still Semantic UI under the hood.

      Avatar of Ralic Lo
      Ralic Lo uses Semantic UISemantic UI

      Used Semantic UI + Angular2 together with Spring or Node/Express for full stack web application development.

      Avatar of Giftstarter
      Giftstarter uses Semantic UISemantic UI

      We haven't yet, but we would like to integrate into our Web App.

      Avatar of Eliana Abraham
      Eliana Abraham uses Semantic UISemantic UI

      It's pretty. Used it once for MDST.

      Avatar of Wellzesta
      Wellzesta uses Semantic UISemantic UI

      Grid, widgets, theming.

      How much does Semantic UI cost?
      How much does TypeScript cost?
      Pricing unavailable
      Pricing unavailable
      News about Semantic UI
      More news