> add non-default variations (mostly different heights/widths than what it ships with).
Check out https://github.com/tailwindlabs/tailwindcss-jit. It got released 3 weeks ago, and supports variable variables in width and height now.
1,498 karma · joined February 19, 2017
https://github.com/BrianHung cv.brianhung.me
Check out https://github.com/tailwindlabs/tailwindcss-jit. It got released 3 weeks ago, and supports variable variables in width and height now.
Pretty much, but that concept by itself is underrated. By having all of the CSS inline on your components, the developer doesn't have to click on a class name and find the css file associated with producing that class.
Tailwind is also a design system, so some non-obvious rules like box-shadows, colors, font-sizes are pre-picked. That means instead of remembering what font-size to use for a figure caption, "was it 0.85rem or 0.75rem", you can just use `text-xs`. Design constraint is good here because you get a consistent look throughout your app. It's kind of like having global css variables: by modifying your tailwind.config.js, you can change all `text-xs` to a different font-size now.
And then when you want to break out of that design system, "I need something smaller than a caption, say text-2xs", you can extend tailwind by defining your own atomic class names.
> benefit of using it vs something like bootstrap
Haven't used bootstrap since my first basic website years ago, but it seems like a vanilla js component + css library. Tailwind is primarily a css library, so you can use it with React and Vue as well. The way you install Tailwind is different too: Bootstrap you put into the head of your document and no build step is required; however, with a build step, you can remove unused css to get the minimal working spreadsheet.
I moved a React side-project from CRA to Next.js for server-side rendering benefits, but the latter doesn't support directly importing css styles in jsx to avoid problems with the global scope.
The two options offered were CSS modules and CSS-in-JS. I didn't like either approaches having hashes in the classname when opening the website in devtools, and both seemed too locked into React/JSX.
Tailwind 1. doesn't have component framework lock-in 2. doesn't make me think of css classnames 3. atomic classnames are readable in dev tools 4. provides default colors and box shadows, etc.
In addition, they're starting to make a render-less component library (https://headlessui.dev/): that means you can customize how components look without having to understand how its javascript internals work, which I'd find a huge plus compared to other libraries like ant design or material-ui.
- vite + react
More beginner friendly than webpack in starting a new project, and faster developer experience: page reloads almost instantly when you're modifying a component.
> I was a huge to-do list junkie, but back then all of the task apps were either single-player or weird desktop apps with syncing issues.
> I decided to build a shared to-do list app for teams.
Yeah, simple single-player to-do lists are great beginner projects to do to learn CRUD and a frontend framework. But enabling real-time multiplayer ups the ante because now you have to manage state and updates between multiple clients and a server.
That being said, if modern websites were rated by utility to user divided by complexity of tech stack, I must say Hacker News would be one of the top ranked sites compared to something similar like Reddit or Twitter which at times feels... like a juggling act on top of unicycle just to read some comments. :)
With :root, you can write css variables that can be accessed by any other element on the page (?).
So to implement a light and dark theme, you could have something like `@media (prefers-color-scheme: light){ :root { --bg-color: #FFF; }`, and then have the body element use that via `body { background: var(--bg-color); }`.
They already had nodes for images and embeds [1, 2] which made development easy (I would recommend checking out the source code; its about a hundred lines of code for each, and simple). But as I made more custom nodes, I learned pretty well the internals of tiptap and how it used ProseMirror. And over time, I've come to appreciate knowing its api.
So if there's any advice for people trying to get started with ProseMirror, I would say to look at libraries which built upon it as example code such as tiptap or the outline rich-markdown-editor [3].
[1] https://github.com/ueberdosis/tiptap/blob/main/packages/tipt...
[2] https://github.com/ueberdosis/tiptap/blob/main/examples/Comp...
- The contributions from the various institutions were as follows:
- $300 million: Bankers Trust, Barclays, Chase, Credit Suisse First Boston, Deutsche Bank, Goldman Sachs, Merrill Lynch, J.P.Morgan, Morgan Stanley, Salomon Smith Barney, UBS
- $125 million: Société Générale
- $100 million: Paribas and Lehman Brothers
- Bear Stearns and Crédit Agricole declined to participate.
https://en.wikipedia.org/wiki/Long-Term_Capital_Management#1...
Say you wanted to build a rich text editor, which can't diff-and-merge as easily as with plain text. Instead of using git for version control, you can use CRDTs very similarly by fetching the remote state, merging with local state, and then pushing.
In that sense, you could build local first software with interoperable hosting platforms (like Github for git) [1].
See [2] as an another example but for a budgeting app.
[1] https://josephg.com/blog/crdts-are-the-future/ [2] https://actualbudget.com/blog/porting-local-app-web
Example of a schema: https://github.com/ProseMirror/prosemirror-schema-basic/blob...
Example of a document converted to JSON: https://tiptap.dev/export
In addition, ProseMirror is built with JavaScript, and would require writing custom code to adapt to Vue or React. Slate and Draft are both built with React, which has it pros and cons. For example, using React means on each key press it’s going to run it’s whole virtual dom diff algorithm resulting in a higher input latency [1]. ProseMirror is more performant in this case by not using React and managing its own editor state. But Slate and Draft, by using React, gets easy server side rendering.
If I were to build a clone of Typora or Bear, I’d use Slate because 1. those editors are close to what Discord has as its chat editor and Discord uses Slate 2. Slate has better markdown support out of the box.
However if I were to build a Notion clone more focused on WYSIWYG, then I’d go with ProseMirror.
I wouldn’t go with Draft in any scenario since the community seems smaller and the library is less maintained, although twitter uses it.
[1] https://juretriglav.si/what-happens-when-you-type-a-single-l...
That reminds me of this blogpost [1]. It's definitely possible to optimize the input latency of rich text editors in the browser: they just have to be close to the metal of the 'contenteditable' browser api.
[1] https://juretriglav.si/what-happens-when-you-type-a-single-l...
If you learn ProseMirror [1], then building on top of outline's rich-markdown-editor or tiptap (which is also ProseMirror based) should be easier. What issues are you currently running into with extending that editor?
From the exemption list, is there any that rival the likes of Uber or Lyft?
1. this doesn't require modifying git's merge algorithm itself; just having custom merge drivers built on top.
2. Is using more space (edit history of CRDTs vs a regular json document) worth it for automatic merging?
I think an issue with this approach is that it's top down, as as mentioned in the article, "those at the top can’t manage all the information about the economy".
A counter-argument may be to just let towns and cities decide what to develop then, since local people have the best information about their neighborhoods. However, 1. this is already the default method and has resulted in housing crises where NIMBYism is rampant. 2. UBI would also help in this case as you're increasing the demand for housing while increasing competition between people living there and not (assuming people want to move to the area in the first place).