Tailwind

[vorcigernix]

I got a basic landing page working with twind, but it is behind the tailwind itself and using twind instead really harms the productivity. Is it technically possible to use the tailwind instead?

[lucacasonato]

Yes, but Tailwind requires a build step, which I don't like. But you can have Tailwind generate a CSS file into static/ and then reference that from your component like you would in any old Tailwind project.

I am working on some features that will make the twind integration feel a lot more like native Tailwind (ie no need for the tw boilerplate).

[marvinhagemeister]

Agree with that. It's the reason why we're moving away from twind and a proper Tailwind CSS plugin is in the works. Stay tuned!

[nnmrts]

@dnlb @ivan-kleshnin Considering "No build step" as a benefit is somewhat ideological. I agree with that ideology but can understand that it is quite "out there" for most people. There's just this dream of shipping ES without a build step again, like it was "meant to be", I guess. Browsers nowadays aren't as scattered and different anymore and the standard got a lot of DX additions as well.

Of course, in reality, most projects I worked on in my job still have massive transpiling pipelines in the background. Often it is Typescript and/or React that just require a build step because they have their own non-standard syntax. But with every build step you add, you lose control of what's happening to your code and you just have to trust yet another company or unpaid open source dev, because I doubt most of us studied the source code of babel/swc/esbuild and know what we can expect in every edge case.

And yes, a lot of the problems regarding control loss and trust are also true for any library or framework, doesn't matter if they're compiling or not. But the difference is, runtime libraries don't actively change your code.

But with the specific example of twind vs. tailwind I can't disagree, twind (at least before v1) was very difficult to deal with if you are used to tailwind (like I was). Too many opinionated changes, way worse docs (it still has two different websites) and slow progress on fixing both. Also obviously tailwind doesn't really change your code, so regarding my points above it's a bit of an exception, but still, if I could decide between no build step at all and only one build step for tailwind, I would still choose no build step. However that ship has sailed the moment we started to use JSX, which needs a build step anyway (on the client at least).

Still, moving towards "no build step" by reducing any maybe unneeded steps shouldn't be discouraged. "No Runtime over No Build Step" is not a no-brainer to me, especially if the runtime solution runs as fast or sometimes even faster than prebuilt code.

[ivan-kleshnin]

@nnmrts sure, the reality is more complex than it's possible to describe in a single post.

Still, "no build step" was a big selling point of Deno. And it didn't work out so well. Because "no build" end goal is achievable for CLI scripts and (maybe) BE, but not FE. Script languages like Ruby, Python and JS are the exceptions where communities think of "compilation" as something optional.

For browser apps, even without JSX, there always is, and always will be, some kind of step at which you minify and vendor-prefix CSS, deduplicate the bundle, compress images, crop fonts, do etc. things with your assets. Bundle-less web development is an utopia.

especially if the runtime solution runs as fast or sometimes even faster than prebuilt code.

Even if they run faster they have to be downloaded. Which of "Download time" and "Interaction time" is more important – is project specific, no arguing.

[marvinhagemeister]

@nnmrts I don't think the "no build step" argument is a matter of "being out there", but rather not practical for most projects. As a maintainer, every Fresh project I've seen so far was written exclusively in TypeScript and used JSX. Both languages don't run natively in the browser and need to be transpiled at some point to make it work.

When it comes to Fresh that only affects islands at them moment. So far I haven't come across a Fresh projects where the code for islands wasn't written in TypeScript and didn't use JSX. What's more is that they often import third party dependencies which need to be served to the browser in some shape or form too.

In that sense the best option for a "no build step" route is to add a js file in the static/ directory and treat is as a static file and move code that should run in the browser there. This works with any framework though and doesn't require logic to make it work on the framework side.

Ultimately, this makes me really question if it was wrong of Fresh to market itself as having no build step because it always had one. It was just a matter of when it happened and where. With JIT-mode the build steps happens every single time a new isolate spins up (=slow) and with the AOT build this only happens once in CI per deployment (=fast + cheaper). Regardless of how one looks at that, both methods are ultimately a build step.

However that ship has sailed the moment we started to use JSX, which needs a build step anyway (on the client at least).

Yup, exactly. I think the discussion if a build step should be as light as possible (agree there) is a separate one. But in the context of Fresh I struggle to understand what the "no build step" is actually referring to.

[lino-levan]

At the end of the day, Fresh claiming to have "no build step" was a forcing function for Fresh to try to guarantee that JIT building is "fast enough". Unfortunately, the end result has more or less been to hope that esbuild builds pages fast enough without any other optimization work. I think "no build step" could work in deploy, especially if blob storage ever lands, but I'm not sure how generalizable it is. To be clear, I really like the concept, but maybe the deploy side really isn't there yet.

[vorcigernix]

I understand. It is great that Fresh does not have any build step. I was looking at "shim" in docs, but it felt like it will degrade UX in a significant way (FOUC, extra library to load). Adding tw function call is only half of the problem. I miss colored shadows, shadow and border transparency and some other things. I'll probably do what you suggest for now, in early phase of the project it is okay to recompile css from time to time. Thanks for answer and more importantly, thanks for building this great framework.

…

On Fri, Jul 1, 2022, 1:49 AM Luca Casonato ***@***.***> wrote: Yes, but Tailwind requires a build step, which I don't like. But you can have Tailwind generate a CSS file into static/ and then reference that from your component like you would in any old Tailwind project. I am working on some features that will make the twind integration feel a lot more like native Tailwind (ie no need for the tw boilerplate). — Reply to this email directly, view it on GitHub <#317 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLZODD3N5W7K7ZAFRTIITVRYXAVANCNFSM52GP67JA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[vorcigernix]

Yes, I do. You can import the shim I mentioned and keep the syntax as it is in tailwind. See twind docs. Sorry, this is a reply to @mattgi

…

On Fri, Jul 1, 2022, 9:11 AM Matt Ginty ***@***.***> wrote: Are you working in VSCode and, if so, do you have intellisense/autocompletion working for twind? the recomended class={tw``} doesn't appear to work for me. Any help would be appreciated (vscode settings.json example?) — Reply to this email directly, view it on GitHub <#317 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLZOCTW7NKEIHLIHWYU3TVR2KYVANCNFSM52GP67JA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tzakharko]

This is what I do:

• put a dummy css file in the static directory
• use an _app.tsx to inject a global stylesheet as described here Using static CSS in Fresh #492 (comment)
• Create a tailwind-template.css that contains the usual @tailwind directives.
• Create a tailwind.config.js with content: ["./routes/**/*.tsx", "./islands/**/*.tsx", "./components/**/*.tsx"]
• Modify the start task in deno.json to run tailwind cli in parallel with the Deno server: "start": "deno run -A --watch=static/,routes/ dev.ts & npx tailwindcss -i ./tailwind-template.css -o ./static/tailwind.css --watch"

Now you can use your tailwind classes in class and everything works like a charm. It's a decent enough solution for now, at least until Fresh gains more ergonomic twind integration and until twind-next is out with Tailwind 3.x support.

And to be honest, I am ok with a little build step once in a while — don't really see much point in recomputing all these styles if my app doesn't need any dynamism.

[nonissue]

@tzakharko Do you have an example project you could share? twind seems cool, but it sucks that it doesn't support tailwind V3, and I couldn't get @twind/next (unreleased v3 update) working with fresh.

[tzakharko]

Sure, I made a simple repo that illustrates the idea.

https://github.com/tzakharko/fresh-with-tailwind

[sebilasse]

@nonissue @lucacasonato Please talk to the twind author cause the next version https://esm.sh/[email protected]/ with tailwind 3 is basically stable and also brings up other improvements over tailwind3, e.g rules –
https://github.com/tw-in-js/twind/blob/next/documentation/migration.md

I am using it in fresh here and it is nice.

import { defaultConfig, setup, tw } from "@twind";

setup(defaultConfig);
function render(ctx: RenderContext, render: InnerRenderFunction) {
  tw.clear();
  render();
  ctx.styles.splice(0, ctx.styles.length, ...tw.target);
  // ...
}

[figuernd]

At a minimum the install step should be changed so that it is clear Twind is being used, the current prompt is misleading: Fresh has built in support for styling using Tailwind CSS. Do you want to use this?

[lino-levan]

I think Tailwind CSS is fine, but it should say something like Fresh has built in support for styling using Tailwind CSS (through twind). Do you want to use this?

[tlgimenes]

Hi folks. Adding to this discussion, I created an analogous to dev.ts called devCSS.ts that uses postCSS and plugins to add tailwind to my project. The idea is that I run postCSS+Tailwind on my project boot process, store the generated asset at /static/main.css and include it at _app.tsx. It's working great for now. It adds a 1s-ish to the boot of the server, which is run only in development mode, so I guess this is an ok-ish tradeoff. Check it out in here :)

Also, linking here my Thoughts on CSS and what I think the ideal CSS stack should bring.

[marvinhagemeister]

FYI: Starting with Fresh 1.6 we'll ship with a first class Tailwind CSS plugin in favor of twind.