Javascript vs. Typescript
Comparison Table
|
Javascript |
Typescript |
| Velocity |
You can write code faster. |
Writing typescript code might be slower than javascript. |
| Code Quality |
It's tricky to track down TypeErrors. Your code always has a risk of errors |
You can track down TypeErrors before your application is shipped to production. |
Notes
- Inferring data types gives you more hints about how your code works. It can boost productivity especially when you're collaborating with other devs.
-
TypeError is one of the most common javascript errors. The top 8 javascript errors out of 10 are TypeErrors. Check this website.
- Typescript has the largest community among javascript typing tools. That's why this tool is chosen for comparison.
## Next.js vs. React
React vs. Next.js
Comparison Table
|
React |
Next.js |
| Subsequent routing and navigating |
React app always guarantees fast subsequent navigating and routing. |
Subsequent navigating and routing in Next.js app is likely to be slower and less smooth. |
| Initial Page Load |
React app needs to download and parse the entire bundle without code splitting, so initial page loads slowly. |
Next.js server creates HTML immediately and sends it to the client, so initial page loads shortly. |
| SEO(Search Engine Optimization) |
Not all search engine bots can run javascript, so some of them cannot index(visit and read) react app. It is not SEO-friendly. |
Next.js app has better SEO becauase bots don't need to run javascript to see the content and initial page loads shortly. Also, Dynamic meta tags and open-graph tags let users preview the content on social media and search engines. |
| Code Splitting |
You need to split code manually. |
Next.js provides route-based code splitting by default. |
| Font Optimization |
Not supported by default |
next/@font prevents CLS(Cumulative Layout Shift). |
| Image Optimization |
Not supported by default |
Size optimization provides a minimal-sized and quality-assured copy of image for each device Images are lazy-loaded for faster page loading. Placeholders prevent CLS while page loading as well. |
| Cost |
Rendering HTML doesn't take any money. |
Redering HTML on the server side takes money. |
Notes
- Next.js app might be slower on subsequent navigation. However, it can mitigate the problem by caching and prefetching routes.
Performance: CSR problems vs. SSR solutions
|
Client Side Rendering |
Server Side Rendering |
| Downloading javascript |
It takes much time to download a javascript bundle, preventing the initial page from rendering. |
Next.js server creates HTML on the server side and sends it to the client immediately, so the initial page loads faster. Route-based code splitting is set by default, so each route downloads minimal javascript required to load itself. |
| Running javascript |
It takes much time to run a javascript bundle, preventing the initial page from rendering. |
Full Route cache caches each route. Caching routes on the server side would be faster than parsing and running a javascript bundle for rendering HTML. Also, partial prerendering caches static parts of each route and only fills the dynamic parts, rendering HTML on the server side even faster. This feature is still experimental, but hopefully, it's stable soon! |
| Data-fetching |
It takes a lot of time to fetch the API server. |
Data cache caches API response for each request. Caching response data on the server side would be faster than fetching the API server on the client side every single time. |
CSS-in-JS vs. TailwindCSS
CSS-in-JS
Benefits
- You can write JavaScript expressions for styling.
- It has a large community support for react-native.
Drawbacks
- Currently, Runtime CSS-in-JS libraries, such as styled-components and emotions, are not supported by Server Components. Only build-time CSS-in-JS libraries are supported.
- Even if you can write CSS in a javascript file components and styling are separated.
TailwindCSS
Benefits
- You can write CSS faster.
- CSS and HTML are tied completely together.
- Most CSS properties depend on parents or children, so it's easier to read CSS once you get used to it.
Drawbacks
- It's hard to get used to it
- When you use JavaScript expressions, you need to do repetitive work.
https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
Top comments (8)
Css-in-js is absolutely supported in server components, check out PandaCSS.
What do you mean with the 2nd drawback of css-in-js? You can write css-in-js directly onto the react element if you want to, it doesn't get more tightly coupled than that... Wouldn't recommend doing that though, just put it in the same file so the styling doesn't make your component code hard to read like with tailwind 😛
You're missing two huge drawbacks of tailwind
Thanks for pointing out that build-time css-in-js libraries are supported in server components. I should have made it clear that runtime css-in-js libraries are not supported.
Note that I'm rather used to runtime css-in-js libraries like styled-components and emotions. You need to define components and they are being used in components inside, so I felt like the markup and styling are less coupled than tailwindCSS.
In my last project, it was uncomfortable to use styled-components even when I tried to separate styled-components and normal components. I placed style-components inside
*.styles.tsand imported them to regular components. It was conversome to check these styled-components whenever I had to debug styling.I did some dynamic styling by using template literals. Like below
<div class={${error ? "text-red-600" : "text-green-600"}}></div>Plus, I cannot relate to your point that 'Only a tiny subset of CSS is supported in tailwindcss', since I didn't really have to customize my tailwindcss at all except for theming. It supports media queries, flex, grid, sr-only, and animation. What did you want to do with that and how did tailwindCSS get in the way? I'd like to know more!
Again, thanks for leaving a comment and sharing your thoughts!!☺️
text-red-600 and text-green-600 are not dynamic, you cant do: text-${departmentPalette}-primary.
I don't think it's fair to say: this runtime thing doesn't work in server components, while comparing it to a build time thing like tailwind.
PandaCSS can interpret dynamic values, aslong as they are known at build time and without any additional configuration
Like you said, tailwindcss has some limitations about dynamic classNames. That's why I said you need to do more repetitive work if you're using tailwindCSS.
You take an example of PandaCSS, but it is a build-time CSS. I admit that I should fix it, so I edited my content, saying that only run-time css libraries have some limitations.
I would consider using build-time CSS-in-JS libraries if I was completely disappointed by TailwindCSS, but I was really satisfied with it! With ShadCN UI I could stay extremely productive while improving accessibility.
Css-in-js is a syntax style though, it's about the pros and cons of that way of working vs tailwind way of working. The fact is you can do css-in-js without any of the imaginary downsides that people like to give it, because they don't have any real arguments against css-in-js, other than they don't like the syntax of writing css vs writing utility class names.
I got curious about PandaCSS, and I looked at it. I like the way it styles! I was comparing tailwind to style-component mainly, since my experience is quite confined.
However, I'd like to use it when this library if it gains more popularity, since I don't want to spend my time trying to figure out how to fix internal bugs, and ShadCN-UI is really making me stay productive.
PandaCSS is pretty stable already, haven't had problems with it and the documentation and typescript support is just heavenly 😁 yea styled-components is from a previous era that will be forgotten about soon.
What kind of styling libraries do you use for react-native? It seems like styled-components and emotion is still used because they are react-native compatible.