6 ms·

This is the blog equivalent of fast-food. Sure, it's technically "food", and most people will agree with the content, but it's essentially empty and does nothin

by tazu 2y ago

This is the blog equivalent of fast-food. Sure, it's technically "food", and most people will agree with the content, but it's essentially empty and does nothing good for your health (nothing to change things). I would love to see a list of projects that do less of the front-end garbage. Someone mentioned the levels.io guy. I also like HTMX. Personally, I've seen great success using 95% server-side rendered sites with 5% Alpine JS sprinkled on top.

edweis 2y ago
I am more doing 50%/50% when it comes to alpine/htmx. I guess it takes times to move away from the SOA mindset. Do you have open source project with the 5%/95% ?
- tazu 2y ago
  > Do you have open source project with the 5%/95% ? Not yet. I just use Alpine for form validation (with the awesome mask plugin), checkbox dropdowns, dialogs/modals, and toast notifications. Everything else is Go HTML templates. I wish there was a way to do custom builds of Alpine and just include what I need, but it probably wouldn't be too hard to do it in vanilla JS.
manuelmoreale 2y ago
I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone. The vast majority of websites out there probably don’t even need JS.
- lmm 2y ago
  > I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone. So actually not "100% server side rendering" at all. And probably paying all the costs of using JS more extensively, but gaining fewer of the benefits.
  - manuelmoreale 2y ago
    What the hell are you even taking about?
    - lmm 2y ago
      What does the term "100%" mean to you? How does that fit into "100% server site rendering and bits of JS here and there" in a way that forms a coherent concept?
      - manuelmoreale 2y ago
        100% of the rendered page is served by the server to the client. Most pages are HTML and CSS. In the rare occasions I need some interactivity (a gallery, some dynamic filtering, things like that) that functionality is provided by JS that’s included in the page, the same page that’s passed by the server to the browser. JS doesn’t render anything. If you turn it off the page is served anyway, some minor things might not work.
        fsckboy 2y ago
        >100% of the rendered page is served by the server to the client. servers always send 100% of what they send. is what is sent 100% rendered already? well, browsers do a fair amount of rendering, that's what they do with CSS and HTML. and then you're adding on JS. we differ in the language we use to describe what is happening. perhaps you've rendered something from a database wrangled into the 100% page that gets sent, it's just not done rendering yet.
        manuelmoreale 2y ago
        Well if you want to play the semantic game then there’s no such thing as a server side rendering because yes, the browser has to render that page on your monitor. But I suspect that’s a pointless definition.
  - zer00eyz 2y ago
- Aeolun 2y ago
  I personally do all my sites with a close to 100% client side rendering as I can get with modern JS frameworks. If I wanted to SSR I’d use PHP…
  - grishka 2y ago
    And what kind of problem do you solve with this approach? Your sites loading too fast?
    - xwolfi 2y ago
      Gnehehehe
    - LegionMammal978 2y ago
      At least for me, static page hosting costs me $0, whereas dynamic page hosting would very likely cost me > $0.
      - manuelmoreale 2y ago
        You can use a SSG and get the same result if that’s your main concern.
      - grishka 2y ago
        Where does your SPA pull its data from, if not from some sort of API that must be running on something that is capable of generating HTML as well?
        LegionMammal978 2y ago
        Most of my personal projects haven't had any state that needs to be managed server-side: any needed data is either static or can be pulled from "someone else's" unauthenticated API. Which is how I prefer it, since all incoming data from users is a big liability these days.
      - wfme 2y ago
        Dropping an SPA onto Cloudflare takes under 5 minutes including sign up and is completely free.
- threatofrain 2y ago
  For every front-facing website there's 10 internal facing tools and dashboards. You don't "need" JS would be the wrong framing here. It's more like you don't need JS aversion when you're developing internal tools and you don't need the complication of SSR either (ask yourself whether the native or mobile app world is jumping on the idea of ultra-thin clients). We waited so long to improve semantic HTML that ML rushed ahead and will probably deliver semantic comprehension far in excess of whatever we can hope for with conventional means now.
alganet 2y ago
Do we need a project, or a tool? Consider the tool the author mentioned, jQuery. It is on the text almost as a museum piece. The things jQuery did (compatibility, CSS selectors, fetch) became standards or stable almost a decade ago. We don't need a 2024 version of jQuery, what that tool did we can now do vanilla. And that's about it. Perhaps React would be useful for a large project, with lots of complexity to manage, and assuming that people involved have experience in using it to manage such complexity. On the other hand, that React project that contains only some forms and page navigation could totally be <form and <a with some small vanilla JS snippets.
- blowski 2y ago
  Sometimes I choose React because it’s easier for me, despite it adding unnecessary complexity to the project. For example, I’m terrible at front end, and design. Tailwind has a React library that handles many of the UI requirements and produces a decent-looking front end with minimal effort. I know enough React that the complexity doesn’t scare me, and there’s so much documentation and training available that it’s easy to find answers. It integrates easily with other frameworks. I can reuse components I built for other projects. React is often not the optimal choice for the project, but can yet still be the right choice.
  - alganet 2y ago
    I feel the same about vanilla web. There are many pure CSS libraries out there that meet varying degrees of UX requirements. Form controls, typography, layout, everything. MDN has a complete documentation with complete browser support, examples, reference. It's awesome. On React world, I often have issues with community components. I needed a dynamic table in my last job, there was simply none. You had to pay for a premium component, or use a code that barely passes 3min auditing (material-table-core). It was a nightmare. A dynamic table qualifies as something I'd rather have a framework do for me. Jesus, YUI did that for free 15 years ago (with tests, with cross browser, with rendering and painting considerations...). However, we ended up rewriting significant portions of the original component we chose (all data handling, all export and import, all menu, all cell rendering, all style).
jasonkester 2y ago
Here's one for your list: https://bettybeta.com/ https://bettybeta.com/ It's a community site, with lots of user generated content and interactivity, but nearly every page is rendered on the server. There are bits that need to respond and re-layout the page on the fly (like https://bettybeta.com/bouldering/projects https://bettybeta.com/bouldering/projects ), that get just enough Vue to be able to do so. But they really are Pages, which means that you don't need to download and process 14mb of javascript to look at the homepage or any content page you might land on from Google. Roughly 100% of consumer-facing websites can be built like this.
dclowd9901 2y ago
I’d love a return to sane css frameworks like SMACSS. And I’m using “framework” in the conceptual way. It’s not a library or anything. Just a set of rules you create for your css. Composable, no compiling, no muss, no fuss. I built something with it once. I wonder if it’s still in use.

by tazu 2y ago

edweis 2y ago

I am more doing 50%/50% when it comes to alpine/htmx. I guess it takes times to move away from the SOA mindset. Do you have open source project with the 5%/95% ?

tazu 2y ago
> Do you have open source project with the 5%/95% ? Not yet. I just use Alpine for form validation (with the awesome mask plugin), checkbox dropdowns, dialogs/modals, and toast notifications. Everything else is Go HTML templates. I wish there was a way to do custom builds of Alpine and just include what I need, but it probably wouldn't be too hard to do it in vanilla JS.

manuelmoreale 2y ago

I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone. The vast majority of websites out there probably don’t even need JS.

lmm 2y ago
> I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone. So actually not "100% server side rendering" at all. And probably paying all the costs of using JS more extensively, but gaining fewer of the benefits.
- manuelmoreale 2y ago
  What the hell are you even taking about?
  - lmm 2y ago
    What does the term "100%" mean to you? How does that fit into "100% server site rendering and bits of JS here and there" in a way that forms a coherent concept?
    - manuelmoreale 2y ago
      100% of the rendered page is served by the server to the client. Most pages are HTML and CSS. In the rare occasions I need some interactivity (a gallery, some dynamic filtering, things like that) that functionality is provided by JS that’s included in the page, the same page that’s passed by the server to the browser. JS doesn’t render anything. If you turn it off the page is served anyway, some minor things might not work.
      - fsckboy 2y ago
        >100% of the rendered page is served by the server to the client. servers always send 100% of what they send. is what is sent 100% rendered already? well, browsers do a fair amount of rendering, that's what they do with CSS and HTML. and then you're adding on JS. we differ in the language we use to describe what is happening. perhaps you've rendered something from a database wrangled into the 100% page that gets sent, it's just not done rendering yet.
        manuelmoreale 2y ago
        Well if you want to play the semantic game then there’s no such thing as a server side rendering because yes, the browser has to render that page on your monitor. But I suspect that’s a pointless definition.
- zer00eyz 2y ago
Aeolun 2y ago
I personally do all my sites with a close to 100% client side rendering as I can get with modern JS frameworks. If I wanted to SSR I’d use PHP…
- grishka 2y ago
  And what kind of problem do you solve with this approach? Your sites loading too fast?
  - xwolfi 2y ago
    Gnehehehe
  - LegionMammal978 2y ago
    At least for me, static page hosting costs me $0, whereas dynamic page hosting would very likely cost me > $0.
    - manuelmoreale 2y ago
      You can use a SSG and get the same result if that’s your main concern.
    - grishka 2y ago
      Where does your SPA pull its data from, if not from some sort of API that must be running on something that is capable of generating HTML as well?
      - LegionMammal978 2y ago
        Most of my personal projects haven't had any state that needs to be managed server-side: any needed data is either static or can be pulled from "someone else's" unauthenticated API. Which is how I prefer it, since all incoming data from users is a big liability these days.
    - wfme 2y ago
      Dropping an SPA onto Cloudflare takes under 5 minutes including sign up and is completely free.
threatofrain 2y ago
For every front-facing website there's 10 internal facing tools and dashboards. You don't "need" JS would be the wrong framing here. It's more like you don't need JS aversion when you're developing internal tools and you don't need the complication of SSR either (ask yourself whether the native or mobile app world is jumping on the idea of ultra-thin clients). We waited so long to improve semantic HTML that ML rushed ahead and will probably deliver semantic comprehension far in excess of whatever we can hope for with conventional means now.

alganet 2y ago

Do we need a project, or a tool? Consider the tool the author mentioned, jQuery. It is on the text almost as a museum piece. The things jQuery did (compatibility, CSS selectors, fetch) became standards or stable almost a decade ago. We don't need a 2024 version of jQuery, what that tool did we can now do vanilla. And that's about it. Perhaps React would be useful for a large project, with lots of complexity to manage, and assuming that people involved have experience in using it to manage such complexity. On the other hand, that React project that contains only some forms and page navigation could totally be <form and <a with some small vanilla JS snippets.

blowski 2y ago
Sometimes I choose React because it’s easier for me, despite it adding unnecessary complexity to the project. For example, I’m terrible at front end, and design. Tailwind has a React library that handles many of the UI requirements and produces a decent-looking front end with minimal effort. I know enough React that the complexity doesn’t scare me, and there’s so much documentation and training available that it’s easy to find answers. It integrates easily with other frameworks. I can reuse components I built for other projects. React is often not the optimal choice for the project, but can yet still be the right choice.
- alganet 2y ago
  I feel the same about vanilla web. There are many pure CSS libraries out there that meet varying degrees of UX requirements. Form controls, typography, layout, everything. MDN has a complete documentation with complete browser support, examples, reference. It's awesome. On React world, I often have issues with community components. I needed a dynamic table in my last job, there was simply none. You had to pay for a premium component, or use a code that barely passes 3min auditing (material-table-core). It was a nightmare. A dynamic table qualifies as something I'd rather have a framework do for me. Jesus, YUI did that for free 15 years ago (with tests, with cross browser, with rendering and painting considerations...). However, we ended up rewriting significant portions of the original component we chose (all data handling, all export and import, all menu, all cell rendering, all style).

jasonkester 2y ago

Here's one for your list: https://bettybeta.com/ https://bettybeta.com/ It's a community site, with lots of user generated content and interactivity, but nearly every page is rendered on the server. There are bits that need to respond and re-layout the page on the fly (like https://bettybeta.com/bouldering/projects https://bettybeta.com/bouldering/projects ), that get just enough Vue to be able to do so. But they really are Pages, which means that you don't need to download and process 14mb of javascript to look at the homepage or any content page you might land on from Google. Roughly 100% of consumer-facing websites can be built like this.

dclowd9901 2y ago

I’d love a return to sane css frameworks like SMACSS. And I’m using “framework” in the conceptual way. It’s not a library or anything. Just a set of rules you create for your css. Composable, no compiling, no muss, no fuss. I built something with it once. I wonder if it’s still in use.