6 ms·

Ships with tailwind? We’re jumping the shark with that

by pineapple_guy 4y ago

cultofmetatron 4y ago
a lot of the community was already using it. plus you can easily overide it.
- the_sleaze9 4y ago
  I believe a fundamental design tenet for Phoenix is the idea of "do it _this_ way, but there's always an escape hatch if you want/need it."
  - jahsome 4y ago
    I think you just described every single framework in existence. If that's not the way, what signifies a properly designed framework in your opinion?
    - pcthrowaway 4y ago
      Heh.. you haven't tried express.
    - josevalim 4y ago
      I don't think there is a definite answer for "what a property designed framework" is but I can try to explain where Phoenix sits in the possible trade-offs. One possible approach frameworks use to provide escape hatches is configuration. You ship with a series of defaults and, once you want to change it, you need to find out the proper knob to turn. A downside of this approach is finding the proper knobs when you need to tweak it. Another approach is code generation: you generate code (or configuration) and keep the knobs clear to user. There are still defaults (and conventions) but the knobs are laid out upfront in your application. The downside here is that having so many knobs upfront may seen daunting or noisy. Since you mentioned Rails, I will provide references on how Rails and Phoenix use those. Both frameworks leverage both techniques above, but Phoenix errs more on code generation and Rails more on configuration. Here is a practical example. Rails has a middleware stack that is part of all applications. This stack is hidden from you. Here is how the generator file for said application looks like: https://github.com/rails/rails/blob/d0d9e8e576b06c19f850751001d19efadf81df73/railties/lib/rails/generators/rails/app/templates/config/application.rb.tt https://github.com/rails/rails/blob/d0d9e8e576b06c19f8507510... Phoenix has a similar stack (called plug) and the default stack is part of your application. Here is the generator file for it (it is not part of your app but used to generate it): https://github.com/phoenixframework/phoenix/blob/3c27a34c27c075af6c99a05168ea709d5389e4fc/installer/templates/phx_web/endpoint.ex https://github.com/phoenixframework/phoenix/blob/3c27a34c27c... You can look at these approaches and try to compare the pros and cons. --- My biased opinion: I have worked with both and I prefer the Phoenix approach. I understand someone may find having all steps in your endpoint noisy or daunting, but the plus side is that it takes a glance to see all steps a request goes through and you can tweak it in any way you want. When comparing to Rails, if you want to insert a middleware in the middle of the default stack, you need to explicitly say before or after which middleware. If you want remove something, you need to state the negation and say "I don't want to have this". Overtime this makes it hard for you to visualize what your application does, because you need to assemble the pieces in your head and use tools to print the stack for you. This also matters on releasing new framework versions. Because Rails has its own stack, if it changes the default middleware stack in any way, it can slightly change how your code. What if the middleware you were inserting before was moved up? Or removed altogether? Or maybe a middleware you deleted was replaced by another one, with similar functionality. Do you want to remove it too? This can lead to subtle differences of behaviour when upgrading. The code generation approach requires you to opt-in to the new features, which is, IMO, one of the reasons why Phoenix could avoid breaking changes in the last 8 years or so. This is in no way a knock on Rails. I am 100% confident the Rails team is aware of those trade-offs and could equally argue for their choices. It also isn't a binary choice either, both frameworks use both approaches, with some general preferences for one over the other.
    - cultofmetatron 4y ago
      the "but there's always an escape hatch if you want/need it." is the critical difference. phoenix is super modular. In rails, you're really locked into a certain way of doing things. I've never felt like I've been corralled into a specific way of doing things that couldn't easily be changed with an hour of work at most.
      - dymk 4y ago
        I'm curious - what in Rails is like that? I've been doing RoR for a long time, and while "Rails is Omakase", I've never felt it was hard to swap out a component.
- bryanrasmussen 4y ago
  >you can easily override it from the article >First, you can customize your core UI components to suit whatever needs, designs, and tastes that you have. If you want to use Bulma or Bootstrap instead of Tailwind – no problem! Simply replace the function definitions in core_components.ex with your framework/UI specific implementations and the generators continue to provide a great starting point for new features whether you’re a beginner, or seasoned expert building bespoke product features. I mean I would think easily overriding it would be sending a -notailwind parameter when using a site generator or something. The above is not easily although not hard either. With a small amount of effort that might irritate you if you don't want to use tailwind is what is sounds like.
  - di4na 4y ago
    You can do `-no-assets` or `-no-html` or even delete that file. All the generated code is here to get you started and generate the default "hello world" page. But none of it is necessary.
    - jeanlucas 4y ago
      People don't read stuff, just wanna post opinions
  - conradfr 4y ago
    I agree. > If you want to use Bulma or Bootstrap instead of Tailwind – no problem! Simply replace the function definitions in core_components.ex with your framework/UI specific implementations "Simply" here means rewriting a 661 lines file. Maybe a more modular approach with only Tailwind support at release would have been better. I know I'm always the "Symfony does it better" guy but in this framework to use Bootstrap (or Foundation etc) for my forms[0] I "simply" have to put: > form_themes: ['bootstrap_5_horizontal_layout.html.twig'] Well maybe the first person to actually rewrite core_components.ex will share it in a Gist or something ;) I also find the new collocated views in the controllers folder a bit messy and not really productive in practice IMHO. [0]https://symfony.com/doc/current/form/form_themes.html https://symfony.com/doc/current/form/form_themes.html
sbrother 4y ago
Honestly liveview + tailwind is just so good that I don't think this is a bad decision.
- deleted 4y ago
  [deleted]
bratsche 4y ago
It fits pretty neatly with components in LiveView, so for the sake of the default generators it makes sense to include. It's super simple to remove it and write components however you want though.
plainOldText 4y ago
I had always avoided using any CSS frameworks because I wanted to master and also maintain complete control over my CSS, but after having used Tailwind for a few projects now, I don't think I would every want to go back to writing raw css ever again.
- andrewflnr 4y ago
  My best guess is, you get your DRY properties by re-using app-specific components that use utility classes, rather than by re-using app-specific CSS classes? Trying to figure out why people think it's a good idea. It's certainly not the vision of web dev I was trained on.
  - peferron 4y ago
    CSS isn't special; HTML and JS have similar needs for reuse and customization. It doesn't make a lot of sense to have a completely separate solution that solves this problem for CSS only.
  - plainOldText 4y ago
    For me Tailwind is an elegant and powerful design language, one which has sane defaults, and which gives me the opportunity to experiment quickly and instill life in the structure of my html right there where I type it, with just a few keystrokes and no change in context.
  - CSSer 4y ago
    If I can chime in here, yeah that’s the gist although I’ll say Tailwind isn’t a panacea. My team and I still write vanilla CSS, but it’s less common and much more navigable. It’s usually because the Tailwind version (if the utilities exist) would be unwieldy. When I started writing CSS I would commonly encounter modestly sized websites of only a couple hundred pages with 17 thousand lines of CSS or more because of frameworks like Bootstrap. At least a few hundred of those lines would be overrides and just as many would probably be redundant. My team launched a 6 thousand page website this past year with only a couple hundred lines of vanilla CSS and roughly 3 thousand lines of Tailwind generated CSS total. At the end of the day, Tailwind is a zero-runtime, tree-shakable CSS framework generator. The burden of naming many common and universal design artifacts is alleviated. Class reusability goes through the roof. Custom stylesheets regain the ability to be edited with confidence again. It’s good. It makes the HTML a bit bloated and ugly which deters people at first, but dev tools pick up the slack and so far I’ve yet to see any performance impact there.
deleted 4y ago
[deleted]

Ships with tailwind? We’re jumping the shark with that

cultofmetatron 4y ago

a lot of the community was already using it. plus you can easily overide it.

the_sleaze9 4y ago
I believe a fundamental design tenet for Phoenix is the idea of "do it _this_ way, but there's always an escape hatch if you want/need it."
- jahsome 4y ago
  I think you just described every single framework in existence. If that's not the way, what signifies a properly designed framework in your opinion?
  - pcthrowaway 4y ago
    Heh.. you haven't tried express.
  - josevalim 4y ago
    I don't think there is a definite answer for "what a property designed framework" is but I can try to explain where Phoenix sits in the possible trade-offs. One possible approach frameworks use to provide escape hatches is configuration. You ship with a series of defaults and, once you want to change it, you need to find out the proper knob to turn. A downside of this approach is finding the proper knobs when you need to tweak it. Another approach is code generation: you generate code (or configuration) and keep the knobs clear to user. There are still defaults (and conventions) but the knobs are laid out upfront in your application. The downside here is that having so many knobs upfront may seen daunting or noisy. Since you mentioned Rails, I will provide references on how Rails and Phoenix use those. Both frameworks leverage both techniques above, but Phoenix errs more on code generation and Rails more on configuration. Here is a practical example. Rails has a middleware stack that is part of all applications. This stack is hidden from you. Here is how the generator file for said application looks like: https://github.com/rails/rails/blob/d0d9e8e576b06c19f850751001d19efadf81df73/railties/lib/rails/generators/rails/app/templates/config/application.rb.tt https://github.com/rails/rails/blob/d0d9e8e576b06c19f8507510... Phoenix has a similar stack (called plug) and the default stack is part of your application. Here is the generator file for it (it is not part of your app but used to generate it): https://github.com/phoenixframework/phoenix/blob/3c27a34c27c075af6c99a05168ea709d5389e4fc/installer/templates/phx_web/endpoint.ex https://github.com/phoenixframework/phoenix/blob/3c27a34c27c... You can look at these approaches and try to compare the pros and cons. --- My biased opinion: I have worked with both and I prefer the Phoenix approach. I understand someone may find having all steps in your endpoint noisy or daunting, but the plus side is that it takes a glance to see all steps a request goes through and you can tweak it in any way you want. When comparing to Rails, if you want to insert a middleware in the middle of the default stack, you need to explicitly say before or after which middleware. If you want remove something, you need to state the negation and say "I don't want to have this". Overtime this makes it hard for you to visualize what your application does, because you need to assemble the pieces in your head and use tools to print the stack for you. This also matters on releasing new framework versions. Because Rails has its own stack, if it changes the default middleware stack in any way, it can slightly change how your code. What if the middleware you were inserting before was moved up? Or removed altogether? Or maybe a middleware you deleted was replaced by another one, with similar functionality. Do you want to remove it too? This can lead to subtle differences of behaviour when upgrading. The code generation approach requires you to opt-in to the new features, which is, IMO, one of the reasons why Phoenix could avoid breaking changes in the last 8 years or so. This is in no way a knock on Rails. I am 100% confident the Rails team is aware of those trade-offs and could equally argue for their choices. It also isn't a binary choice either, both frameworks use both approaches, with some general preferences for one over the other.
  - cultofmetatron 4y ago
    the "but there's always an escape hatch if you want/need it." is the critical difference. phoenix is super modular. In rails, you're really locked into a certain way of doing things. I've never felt like I've been corralled into a specific way of doing things that couldn't easily be changed with an hour of work at most.
    - dymk 4y ago
      I'm curious - what in Rails is like that? I've been doing RoR for a long time, and while "Rails is Omakase", I've never felt it was hard to swap out a component.
bryanrasmussen 4y ago
>you can easily override it from the article >First, you can customize your core UI components to suit whatever needs, designs, and tastes that you have. If you want to use Bulma or Bootstrap instead of Tailwind – no problem! Simply replace the function definitions in core_components.ex with your framework/UI specific implementations and the generators continue to provide a great starting point for new features whether you’re a beginner, or seasoned expert building bespoke product features. I mean I would think easily overriding it would be sending a -notailwind parameter when using a site generator or something. The above is not easily although not hard either. With a small amount of effort that might irritate you if you don't want to use tailwind is what is sounds like.
- di4na 4y ago
  You can do `-no-assets` or `-no-html` or even delete that file. All the generated code is here to get you started and generate the default "hello world" page. But none of it is necessary.
  - jeanlucas 4y ago
    People don't read stuff, just wanna post opinions
- conradfr 4y ago
  I agree. > If you want to use Bulma or Bootstrap instead of Tailwind – no problem! Simply replace the function definitions in core_components.ex with your framework/UI specific implementations "Simply" here means rewriting a 661 lines file. Maybe a more modular approach with only Tailwind support at release would have been better. I know I'm always the "Symfony does it better" guy but in this framework to use Bootstrap (or Foundation etc) for my forms[0] I "simply" have to put: > form_themes: ['bootstrap_5_horizontal_layout.html.twig'] Well maybe the first person to actually rewrite core_components.ex will share it in a Gist or something ;) I also find the new collocated views in the controllers folder a bit messy and not really productive in practice IMHO. [0]https://symfony.com/doc/current/form/form_themes.html https://symfony.com/doc/current/form/form_themes.html

sbrother 4y ago

Honestly liveview + tailwind is just so good that I don't think this is a bad decision.

deleted 4y ago
[deleted]

bratsche 4y ago

It fits pretty neatly with components in LiveView, so for the sake of the default generators it makes sense to include. It's super simple to remove it and write components however you want though.

plainOldText 4y ago

I had always avoided using any CSS frameworks because I wanted to master and also maintain complete control over my CSS, but after having used Tailwind for a few projects now, I don't think I would every want to go back to writing raw css ever again.

andrewflnr 4y ago
My best guess is, you get your DRY properties by re-using app-specific components that use utility classes, rather than by re-using app-specific CSS classes? Trying to figure out why people think it's a good idea. It's certainly not the vision of web dev I was trained on.
- peferron 4y ago
  CSS isn't special; HTML and JS have similar needs for reuse and customization. It doesn't make a lot of sense to have a completely separate solution that solves this problem for CSS only.
- plainOldText 4y ago
  For me Tailwind is an elegant and powerful design language, one which has sane defaults, and which gives me the opportunity to experiment quickly and instill life in the structure of my html right there where I type it, with just a few keystrokes and no change in context.
- CSSer 4y ago
  If I can chime in here, yeah that’s the gist although I’ll say Tailwind isn’t a panacea. My team and I still write vanilla CSS, but it’s less common and much more navigable. It’s usually because the Tailwind version (if the utilities exist) would be unwieldy. When I started writing CSS I would commonly encounter modestly sized websites of only a couple hundred pages with 17 thousand lines of CSS or more because of frameworks like Bootstrap. At least a few hundred of those lines would be overrides and just as many would probably be redundant. My team launched a 6 thousand page website this past year with only a couple hundred lines of vanilla CSS and roughly 3 thousand lines of Tailwind generated CSS total. At the end of the day, Tailwind is a zero-runtime, tree-shakable CSS framework generator. The burden of naming many common and universal design artifacts is alleviated. Class reusability goes through the roof. Custom stylesheets regain the ability to be edited with confidence again. It’s good. It makes the HTML a bit bloated and ugly which deters people at first, but dev tools pick up the slack and so far I’ve yet to see any performance impact there.

deleted 4y ago

[deleted]