181–190 of 551 posts
Earlier quoted context omitted.
Imho, bullet points on the border box seems weird to me ( https://ibb.co/d0sDsQ2 ).
Thanks for the note! The left padding and margin situation on the ul is the bane of my existence.
I haven't looked at your css, but maybe changing the box model could help?
This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I…
Earlier quoted context omitted.
Tailwind is a build step with just as much 'spooky action at a distance'. If it wasn't, we'd just use inline CSS. With Tailwind you're trusting a 3rd party library to abstract the CSS spec for you, and for that abstracted quasi-spec to be followed by your build configuration.
I think there are some other benefits of tailwind. Say you have a set of css classes for different components. Then say one component on one page now needs to be styled differently. You have 3 options: 1. Create a whole new class which duplicates much of the previous class 2. Create a smaller class which is intended to override some rules from the first class 3. Factor out the common styles into smaller classes. All…
But if you've encapsulated the component at all, you're going to need to manage that variant somehow. You can't just have an 'extra tailwind classes' prop, since you can't ensure your overrides will take precedence.
Why not expose the component's styles via component-level tokens referenced through css variables? Then your new variant is a single css class on the component root that sets any new component token values that are then loaded by the component's existing css.
Earlier quoted context omitted.
"I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives." Well, what are the objectives? If they are complex, so should the code be complex. That's the nature of our job. By adding an advanced framework you up the complexity by default. Instead of adding more code, you add more build dependencies. This is especially wasteful on websites. In…
No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions. Frameworks abstract complexity, which in practical terms decreases the complexity I personally have to deal with, and shifts the complexity to the minds of a team of open-source developers who support the framework or library in parallel. Abstraction is exactly how we push the i…
Then, enjoy maintaining React apps once React inevitably bites the dust and ends up in the JS framework graveyard.
While I agree with most of the arguments here, this article feels a little contradictory - it recommends Tailwind but also tells us to 'stay clear of build steps'. Shipping massive CSS/JS resources goes against the whole inclusivity principle - many people don't have super fast internet connections or powerful enough computers..
The OP was making a point that the build step should not be required to run/display a web app. For example, tailwind without a build step is just the entire library. This means one can go a long way and even have a functioning web application without introducing a build step. I would say stripping unused CSS is in the same context as optimizing images, fonts etc perhaps generally a "cleanup & prepare assets for produ…
There's a kind of development version where that build step runs in the browser on page load, but it's still a build step in the sense of generating all that CSS dynamically, and it will produce a poor experience for a user if you try and use it in production.
Earlier quoted context omitted.
Have you used HTMX? I am yet to find a reason for using frameworks like React instead of HTMX.
I have used HTMX with Flask and Jinja. It makes the process much simpler to do the frontend development as a backend developer. But I can see its limitations. It's not suitable for anything bigger than a hobby project. Also, it doesn't help with keeping the frontend and the api totally separate. You have to return the html object from API which has its own set of problems.
This is patently false. It is being used in multiple significant production systems:
and many more. There are times where htmx isn't the right choice, but the idea that its not useful for anything more than a hobby project is simply false.
Earlier quoted context omitted.
Your suspicion is incorrect. Currently running 10 or so codebases with 8 devs using this approach. Thanks for catching the typo
Thats great. Show us!! What projects, is it 8 devs per project or total, what was the impact, any downsides? Nothing is more convincing than real world success stories.
“Locality of behaviour” is such a poorly defined rule. It’s just an invented name for going against separation of concerns. Calling CSS “spooky action at a distance” is a massive stretch too. Good principles here but the arguments are quite weak and could be much simpler.
> “Locality of behaviour” is such a poorly defined rule. And "separation of concerns" isn't? What should be separated? Along what lines? How do we determine these lines? When does it make sense to pull some concerns out into another class/framework/markup/whatever? When does it make more sense to leave things stuck together? The answer is: "It depends" . Not separating anything leads to spaghetti. Separating as much…
JS, CSS, and HTML aren't concerns, they are technologies that have cross-cutting concerns.
The main thesis seems to be that the user should be able to press View Source and understand what's going on. I agree, at least for web sites . For web apps , at least anything over 50 lines, you are probably going to want to use a typed language. (Well, you could technically use .js with TypeScript compiler and type annotations in special comments but I did not find that very pleasant.) I used to be really big on th…
This one confuses me: > Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax And then they demo using _hyperscript [0] as encouraged. However, that's a library built around a custom syntax. It's only using an HTML attribute to encode a script that's in a new language you need to learn. Is this serious? [0] https://hyperscript.org
source: I'm the creator of hyperscript.