5 ms·
I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not a
by pech0rin 3y ago
I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not already build a website with simple html/css?
The web has evolved and taken the place of desktop apps by and large. That is what SaaS has done. These websites are built to be fully functioning pieces of complex software. Using some tiny tools to markup html is never going to work for these types of applications.
I find this hand wringing over the complexity of the web so strange. Can we all just move on? The web has changed. I have been programming for over 15 years professionally. Yeah its changed. yeah frontend frameworks are a pain in the ass a lot of the time. So lets make it better, not fall backwards to a “simpler” time.
- codeptualize 3y agoThis is a very good point. I would also look in different directions for inclusivity. We now have Framer, Webflow and all the others, you don't have to write any code to make amazing websites.
- tonyennis 3y ago"fully functioning pieces of complex software" - in my experience a majority of software is simply not that complex. And the few places where it is are not on the view layer. To make sure we're not talking past each other, can you give examples of the kinds of software you're talking about? We do quite a lot of react work too, but it's ~20% of the projects we work on, when advanced frontend interactivity is needed.
- codeptualize 3y ago> "Not that complex" Even if you have a fully static website you generally have a navigation bar and footer that needs to be on multiple pages. Things don't need to get very complex to benefit from frameworks and tooling.
- zlg_codes 3y agoAre you really advocating for using frameworks as a glorified #include directive? Frameworks are necessary when the job you're doing is highly abstract and you're not totally picky about the result. They shine at those things, but they are overkill for a static website. Something like Pelican or Hugo would be better suited for that. Shit, you could roll your own SSG in a weekend.
- codeptualize 3y agoSo pelican and hugo are not frameworks? How is a static site generator any different from statically exporting next.js/nuxt.js or similar? I've used all the things mentioned, and I quite like the ergonomics of frameworks for static websites. Added benefit is that I can make static sites dynamic if necessary. And to be clear, these static exports are incredibly fast and performant. > you could roll your own SSG in a weekend Sure, I could do that, or I could build my app/website in that weekend..
- zlg_codes 3y agoI can't speak for Hugo but no, Pelican is not a framework. It's a static site generator. I cannot make general purpose, dynamic websites with Pelican. I can fake a few things, I can hook it up to cron to mimic it, but Pelican itself is concerned primarily with your data store, your theme, and generating static files to upload directly to your webspace. Sure, you can make plugins for Pelican to make it generate things the way you want, but it's still just a generator/builder using Jinja templates and Markdown or some other text transformation tool. Also, there's no real indicator that I used Pelican to build my site. There's no cruft I'm including in my <head> element or anything else. It outputs regular-ass HTML. I'm sure it's nice to be able to swap into dynamic web app mode if you decide a project's going differently than expected, but I don't run into that much with the things I design. I usually know from the beginning which tech I'll need to achieve the goal. Frameworks force the dev into specific ways of doing things, so if a program fits into that architecture, go nuts. I'm curious what you guys need on your sites that require so much JS.
- zlg_codes 3y agoI'm sorry, but the majority of the change has been inflicted by for-profit outfits who EEE'd the W3C to get what they wanted. None of us asked for a Javascript-dominated Web where you download megabytes of code before you see the first page. You make it better by separating concerns or finding better ways to do the same thing. By this point, QUIC and HTTP should fork instead of QUIC insisting on taking over HTTP. We can make this space better by pushing out complex "web" applications to their own protocol they can fuck up on their own instead of pushing the system requirements of a browser up every year.
- deleted 3y ago[deleted]