11 ms·

A Rant about Front-end Development

125 points by xlinux 2y ago

est 2y ago
SPA shouldn't be used for content heavy web pages anyway. SPAs today especially React were basically like Facebook's engineers decided to write js/css/html in the style of php.
brigadier132 2y ago
I hate this style of writing.
- oopsallmagic 2y ago
  [flagged]
- janalsncm 2y ago
  Tend to agree. The “piledrive” article yesterday was the same. It’s not that the author didn’t have good points, and it’s not that I even mind profanity. I just think the shocking language is a stand-in for a stronger argument.
  - Aeolun 2y ago
    That’s generally the case with frustration. Don’t want to spend too much effort on your argument because you know nobody will listen.
- MrVandemar 2y ago
  I don't mind it in small doses. That was the first article written like that I've read in a long time, and I enjoyed it, and laughed at some of it, and the topic certainly resonates with me.
renewiltord 2y ago
The thing about software is that you can always just write better software. The levels.io guy makes $2m/yr just being better by being simpler. So it's possible. What's the point of a rant without the code to back it.
- nerdponx 2y ago
  It looks like the author has written plenty of code to back their rant: > I did agency work for 11 years before making the choice to work for a very large tech company. I have worked across sectors like insurance, healthcare, retail, banking, investing, marketing, and manufacturing. I have worked with global brands which are household names. > I have written a lot of front-end code for a lot of companies. I have also dealt with a lot of consequences created by front-end code. My criticisms come from my role as a front-end developer and as someone affected by a front-end developer.
  - renewiltord 2y ago
    Just weird to do things one way and then get upset about it. If there's a better way do it that way. That's why levels.io guy is cool. He just walks the walk.
- oopsallmagic 2y ago
  [flagged]
t1c 2y ago
This screams "old man yells at cloud". Boo hoo, someone used an unordered list for numbered content? Who cares.
- MrVandemar 2y ago
  Doing something the right way is: (a) less work (b) scales from 10 items to 1,000 to 1,000,000 items effortlessly (c) works the same no matter what number system you have localised, such as greek, chinese, icelandic and arabic. As in any profession: use the right tools for the job, otherwise you're bashing in a nail with a screwdriver and scorning the guy using a hammer.
- oopsallmagic 2y ago
  [flagged]
Arainach 2y ago
This article could use a LOT of source links. Not because I believe points are wrong, but because if the author wants to rant that no one knows/has heard of things, why would anyone know what they're talking about? >The number of times I’ve seen numbers written inside of a <li> that’s inside of a <ul> — instead of just using an <ol> — is deeply disturbing. I've been reading and writing HTML since the 90s and off the top of my head can't recall ever seeing <ol>. Why is it better? For screen readers? A sentence to illustrate goes a long way.
- jiggawatts 2y ago
  TIL: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_ol_type_all_css https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_ol...
  - manuelmoreale 2y ago
    Since you're exploring lists: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_counter_styles/Using_CSS_counters https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_counter...
- MrVandemar 2y ago
  > <ol>. Why is it better? For screen readers? A sentence to illustrate goes a long way. It's better because it means it's a list of something in order, as opposed to a definition list or an unordered list. The distinctions are important. It means, for example, that you can meaningfully skip to the middle of an ordered list of the 100 tallest buildings, and be guaranteed to be looking at the 50th tallest building.
  - tstrimple 2y ago
    You're technically not guaranteed to have ordering. You can put an ordered list into any order you want. But semantically it indicates that the order of the list matters. I like the semantic model, but it can easily be abused and not mean anything at all.
- 2y ago
teaearlgraycold 2y ago
Most app’s code sucks but it’s honestly not the fault of React or styled components or server side rendering etc. It’s the fault of people treating front end like it’s easy and can have any old fool thrown at it. The truth is self-contained pages allow for more errors per line of code with fewer crashed sessions than a comparably bad backend with highly coupled modules. So hiring managers and bootcamps throw inexperienced devs at front ends until the tickets get closed. I’ve been doing this as a hobby since 2003, writing all caps <HEAD> tags and FTPing .htm files to a web host. I know a bit about how we got here. If you’re really this pissed off you should get a new job and build everything how you want it. I’ve work on greenfield projects almost exclusively for my entire career. It can be done.
aaronbrethorst 2y ago
I agree with a lot of this rant, but life is too short to care about `<section>`, `<header>`, and most other tags. If your content is highly legible to users—especially if they use assistive technologies—then it simply should not matter. The CSS Zen Garden is dead and it's time to till it and start over.
- jiggawatts 2y ago
  I've heard of a philosophy that instead of a million unique tags that do mostly nothing, modern HTML should use only <div> and <span> instead.
  - lmm 2y ago
    Yep. <div>, <span>, and JavaScript. If you actually want a simpler web stack, that's the way to do it.
    - jay_kyburz 2y ago
      Unfortunately you can't draw a table of number using just divs. It's just too slow and your users will notice. For tables of data, you have to use tables. I'm sure it's true for lots of other elements.
      - LegionMammal978 2y ago
        You can, you just have to set their "display" properties [0] to "table", "table-row", etc. The whole point of CSS is to divorce styling from the particular HTML tags. [0] https://developer.mozilla.org/en-US/docs/Web/CSS/display https://developer.mozilla.org/en-US/docs/Web/CSS/display
        joquarky 2y ago
        If you're going that minimalist, then why even have two tags (div, span) in your toolset when their only difference is display:block vs display:inline
deleted 2y ago
[deleted]
darepublic 2y ago
I just want to say I like pre-rendering > server side. Because you get a lot of performance benefits while still writing in a client side style. It is a low hanging fruit though I suppose a combination with ssr would be better.
STRiDEX 2y ago
I have to do "real" ssr every once in a while via the django jinja html files we have to send emails. It makes me want to die coming from our nice typescript react SPA frontend. Every object is a mystery and jinja syntax is functional but terrible to maintain and of course you're suddenly using tables because it's an email. I'd rather every element be a div than do one minute of editing those stupid jinja files.
- oopsallmagic 2y ago
  It sounds like your issue is with the syntax of Jinja, and the hellscape of HTML email. I'm not sure how 20 MB of inscrutable JavaScript would help, considering it's also just template rendering with extra steps (bonus: using the user's CPU cycles and power instead of your own).
  - lmm 2y ago
    > It sounds like your issue is with the syntax of Jinja, and the hellscape of HTML email. I'm not sure how 20 MB of inscrutable JavaScript would help, considering it's also just template rendering with extra steps 20MB of inscrutable JavaScript allows you to have a) a sane structured component system where you can actually build up UIs compositionally rather than a flat glorified string substituter (i.e. not actually "just template rendering"), and b) the control and abstractions needed to make good UIs out of nested tables.
    - sussmannbaka 2y ago
      you can compose UI on the backend without string substituting. Are you under the impress that JSX is some sort of thing exclusive to Frontend?
      - lmm 2y ago
        > you can compose UI on the backend without string substituting. Sure, but you're still going to be using "20 MB of inscrutable JavaScript". (Unless you use Wicket, but I'm not sure that's an option for emails, and would likely trigger the same complaints anyway). I mean, I hope you're not using the component style rendering layer for Python that I published ~10 years ago, because I haven't maintained it, and as far as I know there aren't any others.
ramesh31 2y ago
>CSS is fine; you’re the problem This one really gets me. Being looked at like an alien from mars when talking to people about styling a page with a few classes here and there rather than pulling in 6 different dependencies of Tailwind et. al is maddening. We are web developers. We get paid to know these things, not to complain about them being annoying and try to find hacky workarounds. And now I get to sift through your utility soup and hope to god there's a class in whatever framework you GPT'd some boilerplate for that does exactly what the designer wants.
- Aeolun 2y ago
  I like writing UI with Tailwind, but I have absolutely no idea why. Ultimately what I do is look up all the actual CSS values I want on their website, then stick in the proper classes. I think it must be because I have zero actual CSS to care about. There’s just nothing in my UI aside from React components, and there’s just enough sugar that it’s easier than using the style attribute everywhere.
hliyan 2y ago
While I don't agree with the tone of the author, I do have to admit, there seems to be something foundationally wrong with front-end development. Yes, it's more complicated than server development in that it is a real-time, multi-point input, multi-output (rendered elements on screen) environment with synchronisation and concurrency needs. But I used to write front end applications with MFC (Microsoft Foundation Classes, which is C++) using Visual Studio circa 2005, and it was never as complex as an SPA today. There is something wrong somewhere, and I don't think it's JavaScript or the DOM. The flaw seems to be paradigmatic.
- oopsallmagic 2y ago
  Your second paragraph disproves your first. Websites' needs didn't drastically increase (I'm ignoring nonsense like WebGPU; render graphics outside the web browser like a God-fearing Christian!), but their complexity did. Why? Well, we told everyone with a pulse they could make six figures "doing web development", and we're reaping what we've sown. You can still design websites like it's 2005, and they'll be damn fast. But pitch something like MFC or even PHP to a 20-something frontend developer now and watch the blood drain from their face.
  - bluefirebrand 2y ago
    We don't build websites anymore, we build web apps It make seem trite but you just aren't going to have a good time building some of the stuff people build now using a LAMP stack
    - manuelmoreale 2y ago
      "We" build both. You might be building WebApps, I certianly don't and so are countless others. The web is not one homogenous thing where everyone is doing the same thing at the same time. Different people work on different projects serving different needs and we have to acknowledge that otherwise we end up in these silly tech-religious arguments where people think there's one and only one way to do things and that's certianly not the case.
- 2y ago
jamil7 2y ago
Maybe it’s time the author started doing something other than frontend dev?
deleted 2y ago
[deleted]
bottlepalm 2y ago
Yea I've been coding every framework under the sun since the 90s and I'm pretty happy with Next.js at the moment. It can render on the server and re-render on the client with the same framework, same language, same functions. Statically typed server to client and back to server. JSX/TSX has no strange template syntax and again static type checking. Compiling automatically tree shakes, bundles, code splits per route. I can do SSG, SSR, CSR, ISR. I can specify per route/api caching strategies. I can host serverless or self host. I'm knocking websites out left and right. It feels like I'm building a single application not two separate frontend/backend applications; managing overhead rendering and communicating between them. Next.js, Nuxt, Remix, SvelteKit - are all part of this next generation batteries included frameworks that can seamlessly transition from server side rendering to client side interactivity. $('.getResults').on('click', () => { $.ajax({ url: '/api/results', data: { foo: 'bar' }, success: function (result) { $('.results').html(result); } }); }); I mean look at this unmanageable bug prone code from the blog post. Nothing here is safe, no way to validate the classes where the data is coming from/going to. No validation of the api or its parameters. If you scaled this example you'd end up with nightmare level code. Yea I've been there already, I'm not going back.
- bluefirebrand 2y ago
  > I mean look at this unmanageable bug prone code from the blog post Yeah, it's hard to take any arguments about code quality seriously when this is being held up as some kind of ideal..
deleted 2y ago
[deleted]
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.
    - 2y ago
lmm 2y ago
Wow, I think this is the first time I've seen a page be wrong about so many things at once. No, the difference between header and section or p and div is not important (after you started off so promisingly by saying that content is what's important - the difference between a p and a div is not content). No, CSS really is the problem. No, you can't actually do server-side rendering in a different technology stack if you want the term "rendering" to mean anything (as much as semantic arguments are pointless in any case). Yes, JavaScript is actually the least-bad solution to every problem in web space; it's not ideal but it's a proper programming language that isn't completely nutso (just mostly nutso), which is more than you can say about CSS or HTML. If you actually want your life to be simpler, use React for everything, like everyone else. Stop worrying about how many dependencies you have and wasting your time reimplementing them worse.
- briandear 2y ago
  And attitudes like this are why we don’t have nice things
  - lmm 2y ago
    On the contrary. The reason front-end development is so much worse than regular development is some bizarre collective fetish for avoiding Javascript, avoiding dependencies, and writing ad hoc, informally-specified, bug-ridden, slow implementations of half of React. It's some kind of Luddism meets Protestant work ethic nonsense, and I'm continually baffled that otherwise intelligent people - people who would never have this kind of attitude in regular programming - keep falling into it.
- Skinney 2y ago
  Screen readers and other assistive technology fully expects your HTML to be semantic. It doesn’t always matter, but it matters often enough. CSS tends to be hard because (1) people insists on having a single page with a single stylesheet and (2) only divs are used, and so they use class names for everything. If you didn’t use a SPA you’d have scoping. If you used semantic HTML you could target based on semantic structure. Both of these makes CSS easier. JavaScript is fine to use if you have to. But using JavaScript when you don’t is just wasting time. I’ve seen people essentially re-implement default <form> behaviour too many times to count, and spend time looking for solutions to problems they only have because they insist on using technology for making interactive sites when they’re making something largely static. If you want a simpler life, choose the simplest technology that will solve your problem.
deleted 2y ago
[deleted]
kristopolous 2y ago
I had been programming for about 30 years, I loved it and was excited by it. After work I would go home and work on side projects. React single-handily killed it. It encouraged, usually required, all of the awful design patterns I used to chase all the junior engineers and interns about. This has become endemic in the JS world. Here's an example: did you know that the uuid npm used Math.random up through 2020 (v.7)? Cryptographically secure random number generation had been available in basically all browsers since 2011. 9 years. If I had an engineer submit that code, I'd rake them over the coals. Speaking of that, I'd usually need a half-time engineer on larger projects just for the management of the complexity. All of the various frameworks and updates and breaking changes. It was a 20/hour a week job just to stay on top of things. For instance, koajs. It's a bunch of dependency code of quality I would never let fly, but now I have to use it and grow my team, increase budget, push back deadlines - all to manage the piles. No thanks. I left that job, quit the industry entirely about 2 1/2 years ago. Reactjs was such atrocious self-aggrandizing bullshit, it made me quit programming. It's fragile, over-engineered, mostly broken, confused poorly defined amorphous concepts that poorly solve mostly imagined problems and the entire industry of front-end is eating up that mode of design like it's some sacred text. They'll use abstract buzzword concepts that have different conflicting definitions in basically every text you pick up, and they'll never concretely define them but continue to use them as abstract amorphous blobs. I've got very popular front-end projects. I've been at the C-level of more than one company that sold based on front-end design. The first professional javascript based web app I did was in 1997. I deployed Server Side JavaScript (SSJS)/LiveWire in the 90s, a decade before Node ever existed. I've been at this for a long, long time. After dealing with react, I never want to touch that stuff again.
- throwaway4good 2y ago
  Could it be that you never tried to understand react and why the approach makes sense to millions of developers?
  - kristopolous 2y ago
    We could waste each others time getting into the specifics but I can summarize it. It has affordances and design patterns that inexperienced, new, novice programmers find attractive and tempting but comes with all of the warts and issues surrounding intuitive patterns. That's why it takes over 10 years to get good at programming - counterintuitive insights are the clarifying beacons on any sufficiently complex project. People are "react programmers" instead of actually understanding the specs, standards, javascript, protocols or how things actually work. It's about 100 times easier to find a mediocre junior programmer than a comptent one. React allows, at a great cost of time, resources, and money, a large team of mediocre junior programmers to eventually create what once required a competent engineer and that is why it's popular. Your offshore outsourced $15/hr programming firm can now make a half-assed website or app and you don't actually need to find someone who knows what they are doing. If you've actually worked in the industry, actually dealt with code, been put on projects that are off the rails, you know this is true. You know this is exactly what is happening. Then management is unwilling to pony up the $250k to attract the right talent so you get stuck with the job of making heroic efforts to prevent the house of spaghetti from collapsing. You've been there. You've done this. You know exactly what I'm talking about.
throwaway4good 2y ago
What a silly rant. There is a huge world of different approaches to front-end and lots of them do cool and interesting things that would both up your productivity and give you completely new opportunities ... if you bothered instead of just being an old fart.
- briandear 2y ago
  It would be cool if all of the fancy front-end people would learn how to use HTML properly before lecturing the “old farts.” The <ol> example comes to mind.
  - throwaway4good 2y ago
    You can be old and experienced and still have an attitude of being open to new things ... at least to the point where you understand them before you embark on a rant.
    - bdougherty 2y ago
      We didn't have that in the article?
  - MrVandemar 2y ago
    The way some people code "HTML" these days is like an apprentice carpenter swaggering up to a house building site, and then banging in nails with the butt of their power-drill, and telling the "old fart" carpenters what losers they are for bothering to use a hammer. Use the right tool for the job. HTML is a toolbox, not a bucket of <divs> and <spans>.
acosmism 2y ago
i cant count the number of times i've had to generate boilerplate + interfaces etc etc for something that would be as simple as an onclick (onClick?) handler would have done. i have yet to actualize the serious promises of this ecosystem in any meaningful way and it doesn't seem to get better. also jsx is ugly.
- robertoandred 2y ago
  I can count it: zero. Onclick handlers work exactly as they always have.
  - acosmism 2y ago
    sure the browser accommodates. now how about dealing with wrapping everything in unnecessary empty tags and tree shaking and bloat etc. specialized dev inspector tools for each framework etc. there are layers...
    - robertoandred 2y ago
      There are no layers if all you want to do is add an onclick handler.
      - acosmism 2y ago
        there is. there is a build system. there are probably some typescript interfaces and lint checks you need to pass etc probably some other framework you need to familiarize yourself with if you are data binding etc. i'm not saying any of this is inherently bad - what im saying is 99% of the time this is overkill
        robertoandred 2y ago
        So don’t do that. Just open a text editor, write <button onclick="thing()">Click Here</button>, and celebrate.
tjpnz 2y ago
I fear that so much about what the web is has been forgotten. I've had some surreal discussions with frontend devs that don't have a fully formed concept of what a URL is. Their solution to "sharing" is to either have their users instruct each other using words on how to find a particular page, or to propose some overengineered URL shortening scheme to encapsulate state which belongs on the path or query string. It really feels as though usability is being treated as an afterthought.
robertoandred 2y ago
Yawn, another case of “new is bad because I don’t understand it.” Being nostalgic for jQuery? Really?
dmalik 2y ago
I agree with some of what the author is saying but add about 10 years of experience. Been coding sites since I was a kid in the mid 90s (I was a web master). I have 10 years working on brochure sites but have spent the last 10 working on major SaaS. Few things I disagree with: - The content rant was weird. I've always worked with content designers, instructional designers, or good marketing copy people. Was that about semantics? Sure ya, SEO and a11y. - Cascading CSS is great until you write a million+ line SaaS app and have 1000 devs working on the code. Then you need scope. The rant is specific to brochure sites. - SSR. Weird. Do devs really think that? I guess I'm out of touch or my colleagues are better than most. - A lot of rants seem to be ripping of jr devs. Show them the way! Very yells at cloud. - CSS nesting I really like. Example of nesting elements inside a class is a hack that should not be done. Nesting is easier to read if done properly.
hardwaregeek 2y ago
There’s a lot I disagree with but I’ll point out one in particular. > how do we make content presentable as easily as possible, with as little duplication as possible, and with as few negative impacts to the user as possible. Why is this the priority? If I wrote a language that was solely focused on removing duplicate code, and doing the minimum to appear decent, that would be a pretty bad language. I care a lot more about composability and readability than de-duplication and floor raising. Let’s face it. CSS comes from a fundamentally different situation than the modern web. I’m talking about optional styles that do not affect the content, that are written by one or two people, and likely total at most a few hundred lines. That is nowhere close to modern websites. Bemoan that all you like, it doesn’t change the reality.
- polydevil 2y ago
  Who says that the solely focus of CSS is avoiding duplicate code?
nate-sys 2y ago
difficult to believe that many are disagreeing in the comments. this is really one of the better "rant" posts.
joseferben 2y ago
i mostly agree with the rant, except for styling, i think tailwind is great. nowadays i default to htmx, alpine, sqlite and typescript, recently i’ve been working on a framework/starter using these tools: https://www.plainweb.dev/ https://www.plainweb.dev/
tflinton 2y ago
Why didn’t he mentioned rewriting or adding to browser history?!
rado 2y ago
He is right to rant about semantic HTML being replaced by framework div soup. It's awful for accessibility etc.
onion2k 2y ago
When I started building websites professionally (in 1998) we had an adage that people used all the time to talk about how to get traffic to your website: "content is king!" It was a play on the "cash is king" motto of small businesses I think. It was very accurate too; if you wanted traffic then you had to build a site people shared. Search engines were not as effective as they are today. Then the web changed a bit. In 2005 to 2015 (ish) people transitioned from being consumers of web content to creators of that content. We called it "Web 2.0". Content was still king because people went to their favorite sites to create things that other people would read. But anyone with half a brain could see what was coming next. Around 2015 people stopped making content for other people to spend time consuming and instead shifted to making content that was seen for as little time as was necessary for them to hit a 'like' button. 'Content' in any meaningful sense died. It became a sentence on Twitter, or a photo on Instagram, or a really short video on TikTok. The entire premise that users go to websites for the content is nostalgia. That side of the internet is effectively dead (despite some noble and awesome attempts to keep it going, HN being an example). Today very few people get paid to build static content sites. If you're a web dev you're paid to build an app that enables people to do things in a browser - and yes, that means working with something like React. All web devs try to crowbar React into everything simply because that's what they're paid to do, and they're paid to do that because that's what users want to do. Railing against it is a waste of time. The Internet today is not same as the Internet of 25 years ago.
- dmalik 2y ago
  Well said. Also been doing this since the 90s. I still like discovering new sites, blogs and creative things people make. HN is one of the better sites for that.
  - smj-edison 2y ago
    If you haven't already heard of it, you might like marginalia. It's a search engine/website finder/experiments. I've found it really useful for finding small blogs and interesting perspectives!
- manuelmoreale 2y ago
tflinton 2y ago
I literally left front end development because of stuff like this. It felt like insanity. Throwing out the door debuggers, linters, all the tooling so we could express objects as attributes?… and enforce managing state better?.. It felt like a flood of junior programmers in an echo chamber set off by an opportunistic engineers at Facebook who were more interested in creating their own job security then work to evolve an existing standard. Seriously who honestly thinks that the authors and governing board of HTML and CSS didn’t closely consider the features in react? What kind of arrogance does it take to say they’re fucking dumb let’s reinvent EVERY tool on front end because we know better. But I digress…
surfingdino 2y ago
I was recently on a project where the backend was written in Python and finished in two months. The frontend guys are still dicking around with React components eight months after the project started. The front end on this project is child's compared to the backend. It's frustrating. There was a point in the history of front-end dev when they all started calling themselves "rock stars" and became convinced that they are the future of software development. The SPA trend gave frontend devs an excuse to write unmaintainable code, gave designers an excuse to call themselves software developers, and then they all told the world they are doing "full-stack development" when Node appeared. Meanwhile they never bothered to learn pre-SPA UI, UX, or content design principles. Thing is, working on front end never gives you a chance to work on problems that backend has to deal with. I never let JS guys work on backend code, because they are lost if they cannot find a module online that does what they are asked to do, or is missing half of the features from the spec it promised to implement (always the hard ones). We then have to pick up the mess and rewrite it in Python or Golang, which is wast of time and money. I once quit when when the client showed me the Python code written by a JS dev. My devs refused to touch that shit and we went to work for another client.
- rmuratov 2y ago
  This is a big and poorly justified generalization.
  - surfingdino 2y ago
    To be fair to good JS backend devs, my view is biased by the fact that me and my team do Python and Golang work and the only time we interact with JS devs is when there is frontend to be written. Some frontend guys are good, most of them are poorly trained and those think they can write backend code and lobby managers to let them have a go at it. With disastrous results. I have never worked with JS backend devs who were any good. I am sure they exist, but I have yet to meet one.
- tasuki 2y ago
  > I never let JS guys work on backend code, because they are lost if they cannot find a module online > We then have to pick up the mess and rewrite it in Python or Golang If you really must feel smugly superior, why go with Python or Golang? You could be using Haskell! The JS devs I worked with in the past were competent developers who happened to do JavaScript.
Erem 2y ago
I built a fairly successful vc funded startup with a front end lead that thought this way about frontend frameworks. For a suitably complex application what happens is that you end up organically building your own framework in order to manage the mess of application state that is the screen. Now in order to spin up, new engineers need to learn this unusual organic framework to get things done rather than just use the excellently documented React that they likely already know.
- dmalik 2y ago
  Ya. This is why React is popular. It's just a bunch of decently good front end best practices. Popular, not the best X for Y but with easy replacements.
- mmcnl 2y ago
  Yeah. Seniority should come with the realization that all tools are there for a reason and every engineering decision is a trade-off. Accept that maybe you don't know everything and be open to change your mind. All these "opinions" don't get you (or your employer) anywhere.
throw156754228 2y ago
Thank you. I'm at a css in js company and everything you wrote about it is The Truth. We've got nav menus written in reams of javascript. Stuff that could be done with zero js, or a couple of lines of glue. In a previous role I used Ant Design which were on the SASS train, trying to override the specificity of their stupidly long selectors was painful. React is too loose, it just enforces no abstraction or discipline. JSX ends up an ugly nightmare of angle brackets, ampersands and question marks. You often have to piece together how the component works by staring at all the event handler code for minutes hours days. Most of my colleagues writing it would stare blankly if I mentioned MVC. I think I would come down on the side of Angular, it's opinionated, but at least they attempted to separate the template from the controller, and logic in the services.
graftak 2y ago
In 2001 the EU switched (mostly) from a local currency to the euro. For years people would calculate prices back to the currency of old. If you do it nowadays, over 2 decades later, people look at you funny. People who still rant about the simplicity of jQuery are of the same cloth.
- grishka 2y ago
  Except that unification did give enormous benefits, it allowed those countries to trade more freely. The horribly inefficient JS-ass 5-megabyte-bundle SPA blogs benefit no one in the long run. By the way, on my recent visit to Europe, there still was a total in francs "for information" on the receipt from a random grocery store in Paris.
  - awelxtr 2y ago
    > By the way, on my recent visit to Europe, there still was a total in francs "for information" on the receipt from a random grocery store in Paris. As an european: that's a problem. Why? Inflation. People who still change regularly to the old currency only do so for some of their finances AND romanticise the past.
csomar 2y ago
The author makes a few good points but on average sounds like an old man complaining about everything. There is a reason React took off, and there is a reason people choose React. Sure, if you are building a simple content heavy front-end, it doesn't make sense to chose a React framework or React at all. But many apps today come with heavy front-end interactions and have to sync with their back-end in real time. Good luck doing that with jQuery Ajax. And you can't blame the bootcampers. They were promised riches after a 6 months bootcamp. They were taught React and had little interactions with HTML. So they are doing what anyone else in their position will have done. So when they were out in the market, then React is was. Suddenly, everything became a React component; and if you made a website today, you'd better off start with React. In defense of React/NextJs: I have been blogging for 10+ years. I started by using WordPress. I have constantly failed to maintain a server up and running for more than a year. There is always something that comes up. A bad WordPress update, DB goes wrong, a failed payment, a bad WordPress plugin update, Server goes down because?, etc... 5 years ago, I switched to NextJS. It's a spaghetti of NPM modules just to build a very static website for very simple content. Sure. But 5 years later, the very same site is still up. There is no maintenance involved as the site is hosted in Github. Not sure I'd say the same about WordPress.
- lelanthran 2y ago
  > There is a reason React took off, and there is a reason people choose React. Sure, there's a reason. Doesn't mean it's a good one :-/ > 5 years ago, I switched to NextJS. It's a spaghetti of NPM modules just to build a very static website for very simple content. Sure. But 5 years later, the very same site is still up. There is no maintenance involved as the site is hosted in Github. Not sure I'd say the same about WordPress. Is 5 years considered a long time? Is that the bar? Because >6 years ago I wrote an internal site/app in C# using Jquery for front-end, and that is still up, working and being used by a few thousand people daily. It's even being extended every now and then. No NPM, no React, no Vue, no Next, no front-end build step.
- manuelmoreale 2y ago
  I coded this one for a friend more than 6 years ago: https://designed.space https://designed.space It runs on a basic LEMP stack (or rather a LEP since it's a file based cms) on a VPS I have not touched in years. The stack is outdated, the CMS is outdated. It runs just fine with no issues. I can move it to an up to date VPS and port it to a recent version of the CMS in a couple of hours and it would then be fine for probably another 6 or 7 years.
tobyhinloopen 2y ago
I’m with OP but we’re a rare breed.
smj-edison 2y ago
It seems he certainly hit a nerve here, regardless of people's position on the subject...
noduerme 2y ago
Arguably, for SPAs it doesn't matter what tags you use at all. Whatever you do is going to be inaccessible. Make everything a div. Who cares? We used to write all the UI components ourselves in Flash or Java. Sure, yes, understand the content that you're writing your UI around, and make the UI serve the content. That just begs the question of why one would get anal about which HTML5 tags are used for headers or navs or buttons.
Too 2y ago
This rant is missing the WHY in every section. While it has some valid points, it will unfortunately only satisfy those who are already in the same boat. The rest of us will keep wondering why he implicitly assumes that backend generated with js is sooo much worse than if was generated with anything else. I've also written my fair share of PHP before AJAX was even a word, plus lots of ASP.NET, Java and Python backends. Honestly, their templating languages all suck, compared to React components that are type safe and infinitely easier to compose and refactor (jinja anyone?). While their languages and ecosystems are a lot more powerful, JS these days isn't that terrible as a language, just keep a tight grip on your package.json. It is correct that there is something wrong with the culture of the front-end development, in that there seem to be no brakes on just piling crap on the next shiny thing and then building even more packages and abstractions around it, instead of fixing the underlying crap in the first place.
miffy900 2y ago
The entire article itself presents incredibly poor reasoning or no reasoning at all for its points. It's really hard to appreciate it now because CSS (along with JS+HTML) has been extended and upgraded gradually over the years, but CSS is incredibly good for styling and formatting DOCUMENTS - which have a very specific definition, especially back in the 90's when it was first conceived. This is what is was originally designed for. In that sense the complaints about CSS are perfectly reasonable: why are we using a document styling language for building arbitrarily sophisticated web applications when it was clearly not originally designed for that? You could say the same with HTML and JS really. > Quit acting like CSS is some giant-ass mistake that needs fixing. A group of people who were collectively smarter than us wrote those specs. They didn’t make mistakes. Assume you are making the mistake, not them. So what year again was the CSS standard was first published? Checks google quickly -- oh it was back in...1996. HTML was...1991. And JavaScript in...1995. Yes, it's well known that people in the 1990's were much smarter than people in the 2020's! It's not like there's been decades of progress since then! CSS is utterly fit for purose and bereft of any flaw or defect! Absolutely nothing new needs to be invented or discovered about front-end web development in 2024! There's no point in trying to improve things! OK, it's hilarious the author rails against things like SASS, and CSS is now being updated to incorporate many of the same features that SASS introduced: - CSS nesting: https://www.w3.org/TR/css-nesting-1/ https://www.w3.org/TR/css-nesting-1/ - Scoping (no more global): https://developer.chrome.com/docs/css-ui/at-scope https://developer.chrome.com/docs/css-ui/at-scope - Not to mention things like CSS variables, calc() etc. Usually people whine about the status quo or things staying the same for too long and in response, try to improve things. This article almost seems like a big whinge about how things should stop changing and regress or go back in time? That's not happening. If people had the author's sensibilities or attitude back in the 2000's we'd never move past `float: left` for positioning or tables for multi-columnar layouts. Utterly bizarre.
deleted 2y ago
[deleted]
nojvek 2y ago
For more than a decade, worked with many large Single page applications (SPAs) across startups and large companies. He has some good points regarding SASS. Other bits were about ranting. The issue with frontend dev is there is a gajillion bootcamps promoting it so we have a bell curve weighted heavily weighted towards juniors. Add in browser compatibility issues, framework churn and other headaches, there are fewer highly experienced FE devs who understand the browser in a deep way. FE code also tends to be highly stateful. Managing state well is one of the harder FE problems that few folks talk about. Add in the mix that some are apps and some are websites. There is no one right answer.
koonsolo 2y ago
Here is the main problem: front-end can mean "blog" on one end, and "photoshop replacement" on another.
- foul 2y ago
  Yeah, not only this article doesn't mention whether he slings around his own library or uses a less insane JS blob like jquery, alpine, htmx or hyperscript, he laments essentially that foundations for big webapps and cookie-cutter shit turnkey products are sold for small operations and static websites. In a lot of parts of this rant I couldn't abstain myself from thinking that he wants a web for documents and the web for applications swung around a lot of very bad habits and useless complexity in the field while waiting for wasm, aka "New Applet" to be production-ready.
shepherdjerred 2y ago
The problem isn't React. You can write a good website with React. You can write a good website with htmx. You can write a good website with HTML/CSS/vanilla JS. The average developer who cares enough to learn and use htmx/vanilla JS is going to write a superior product simply because they care more about performance and/or because they are better than the average developer. --- I'll plug my favorite way to build a site: Astro [0]. It allows you to write JSX that compiles to static HTML. You can use React/Vue/whatever as well for anything that actually needs to be dynamic. I'm not affiliated in any way, but I did build my personal site [1] with it. [0]: https://astro.build https://astro.build [1]: https://sjer.red https://sjer.red
bartimus 2y ago
I agree with many things. But: > Maybe it’s because Angular was no one’s first choice — even though it came first. Actually ExtJS was the first real framework. Angular was just one of the new kids on the block.
sebazzz 2y ago
If you want to reduce maintenance costs, reduce the amount of Javascript code and tooling. NPM-Javascript is a shitshow of constant breaking changes left and right, whether it is in your runtime framework, or your build system like gulp or more prominently webpack. Try maintaining 10 projects with these frameworks. You'll quickly look for something that is not as maintenance intensive. Example: No, you can't stay on Webpack version X, because (real example) it turned out that version of webpack relied on md5 which wouldn't work in newer node.js versions.
mmcnl 2y ago
Ranting is easy. It's nice to vent once in a while, but then what? All that remains is that the author is fed up with tools that don't solve his problems. Ok? The key difference between the web and any other type of development, is that you can distribute almost any type of application with the push of a button to billions of people, without the need to install anything. This is a superpower which _ofcourse_ comes with some complexity. Sometimes when you don't need that superpower and you have to navigate the complexity anyways it will be a frustrating experience, but that doesn't mean there is something fundamentally wrong or anything.
andreyvit 2y ago
Here’s practical experience from me running the tech side of a startup while sharing the author’s values. Server-side rendering (the normal kind from 1990s): 1. It is glorious. Everything that 37signals has to say about it is true. 2. However. I really miss React-style components as an abstraction. There are many ways around it that we use depending on the case (plain CSS classes, our own tiny Go/HTML component library, HTML custom tags), but we’re yet to produce something as ergonomic for more complex compositions. 3. We’ve added Hotwired Turbo for smoother page updates. I find it’s a lot more orderly than htmx, but we do miss some things that htmx would offer. CSS: 1. We started out with just plain CSS, using BEM and CUBE to structure it and manage complexity. 2. That still got us questioning the DIY nature of the U (utilities) part of CUBE — it got increasingly complex and random, and really just like every program grows a broken LISP interpreter inside, every custom CSS utilities library grows a broken copy of Tailwind inside. So we adopted the actual Tailwind for utilities. Tailwind is truly glorious, both for sheer productivity of writing the code, but also as a language for describing styling at just the right amount of detail — more powerful than CSS properties alone (hover:color-red-700, disabled:cursor-default), but more constrained than full CSS. 3. Tailwind introduces a build step, though, which sucks (and slows down the build by the whole second! My m2 Air can probably do a 60s supercomputer-level nuclear explosion simulation during that time.) Thankfully, part of our startup is doing custom themes for each client, for which actual Tailwind sucks even more (themes are edited at runtime, and you wouldn’t want to run actual Tailwind with its million Node dependencies on your server), so we’ve implemented a subset of Tailwind in Go, just the things we actually used, and it runs at runtime, eliminating any build steps for themes. 4. Bottom line: Tailwind is absolutely glorious as a shared design vocabulary. Non-tech people were able to adopt it and handle theming thanks to it. The actual implementation of Tailwind seems unacceptably slow, but I hear a Rust compiler is coming. JavaScript: 1. Plain old JavaScript is great, but needs some structure. We found that structure in Hotwired Stimulus, which we absolutely love. 2. But again, I do feel the desire for React-style rendering occasionally. We embed our widgets on customers’ e-commerce sites, and a chunk of HTML rendered based purely on data coming from an API with live updates is a perfect case for React. 3. Needless to say, running code on other people’s e-commerce sites is where I would never dare use a React-based stack, because I’d spend the rest of my life doing due diligence on the dependencies. (Our competitors are much less responsible about this, and it works out for them too, so this is more of a principles thing.) 4. This is probably the case where an in-house 500-line implementation of React-style rendering would be preferable to anything else. We already have a 100-line version, but it lacks many desirable features. Bottom line: Yes, you can (and should) run a modern startup based on a pragmatic server-side rendered stack, but you definitely want to add just a few modern things: something like Hotwired, something like Tailwind, some solution for more powerful components in your templates, and something like Preact for certain use cases.

125 points by xlinux 2y ago

est 2y ago

SPA shouldn't be used for content heavy web pages anyway. SPAs today especially React were basically like Facebook's engineers decided to write js/css/html in the style of php.

brigadier132 2y ago

I hate this style of writing.

oopsallmagic 2y ago
[flagged]
janalsncm 2y ago
Tend to agree. The “piledrive” article yesterday was the same. It’s not that the author didn’t have good points, and it’s not that I even mind profanity. I just think the shocking language is a stand-in for a stronger argument.
- Aeolun 2y ago
  That’s generally the case with frustration. Don’t want to spend too much effort on your argument because you know nobody will listen.
MrVandemar 2y ago
I don't mind it in small doses. That was the first article written like that I've read in a long time, and I enjoyed it, and laughed at some of it, and the topic certainly resonates with me.

renewiltord 2y ago

The thing about software is that you can always just write better software. The levels.io guy makes $2m/yr just being better by being simpler. So it's possible. What's the point of a rant without the code to back it.

nerdponx 2y ago
It looks like the author has written plenty of code to back their rant: > I did agency work for 11 years before making the choice to work for a very large tech company. I have worked across sectors like insurance, healthcare, retail, banking, investing, marketing, and manufacturing. I have worked with global brands which are household names. > I have written a lot of front-end code for a lot of companies. I have also dealt with a lot of consequences created by front-end code. My criticisms come from my role as a front-end developer and as someone affected by a front-end developer.
- renewiltord 2y ago
  Just weird to do things one way and then get upset about it. If there's a better way do it that way. That's why levels.io guy is cool. He just walks the walk.
oopsallmagic 2y ago
[flagged]

t1c 2y ago

This screams "old man yells at cloud". Boo hoo, someone used an unordered list for numbered content? Who cares.

MrVandemar 2y ago
Doing something the right way is: (a) less work (b) scales from 10 items to 1,000 to 1,000,000 items effortlessly (c) works the same no matter what number system you have localised, such as greek, chinese, icelandic and arabic. As in any profession: use the right tools for the job, otherwise you're bashing in a nail with a screwdriver and scorning the guy using a hammer.
oopsallmagic 2y ago
[flagged]

Arainach 2y ago

This article could use a LOT of source links. Not because I believe points are wrong, but because if the author wants to rant that no one knows/has heard of things, why would anyone know what they're talking about? >The number of times I’ve seen numbers written inside of a <li> that’s inside of a <ul> — instead of just using an <ol> — is deeply disturbing. I've been reading and writing HTML since the 90s and off the top of my head can't recall ever seeing <ol>. Why is it better? For screen readers? A sentence to illustrate goes a long way.

jiggawatts 2y ago
TIL: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_ol_type_all_css https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_ol...
- manuelmoreale 2y ago
  Since you're exploring lists: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_counter_styles/Using_CSS_counters https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_counter...
MrVandemar 2y ago
> <ol>. Why is it better? For screen readers? A sentence to illustrate goes a long way. It's better because it means it's a list of something in order, as opposed to a definition list or an unordered list. The distinctions are important. It means, for example, that you can meaningfully skip to the middle of an ordered list of the 100 tallest buildings, and be guaranteed to be looking at the 50th tallest building.
- tstrimple 2y ago
  You're technically not guaranteed to have ordering. You can put an ordered list into any order you want. But semantically it indicates that the order of the list matters. I like the semantic model, but it can easily be abused and not mean anything at all.
2y ago

teaearlgraycold 2y ago

Most app’s code sucks but it’s honestly not the fault of React or styled components or server side rendering etc. It’s the fault of people treating front end like it’s easy and can have any old fool thrown at it. The truth is self-contained pages allow for more errors per line of code with fewer crashed sessions than a comparably bad backend with highly coupled modules. So hiring managers and bootcamps throw inexperienced devs at front ends until the tickets get closed. I’ve been doing this as a hobby since 2003, writing all caps <HEAD> tags and FTPing .htm files to a web host. I know a bit about how we got here. If you’re really this pissed off you should get a new job and build everything how you want it. I’ve work on greenfield projects almost exclusively for my entire career. It can be done.

aaronbrethorst 2y ago

I agree with a lot of this rant, but life is too short to care about `<section>`, `<header>`, and most other tags. If your content is highly legible to users—especially if they use assistive technologies—then it simply should not matter. The CSS Zen Garden is dead and it's time to till it and start over.

jiggawatts 2y ago
I've heard of a philosophy that instead of a million unique tags that do mostly nothing, modern HTML should use only <div> and <span> instead.
- lmm 2y ago
  Yep. <div>, <span>, and JavaScript. If you actually want a simpler web stack, that's the way to do it.
  - jay_kyburz 2y ago
    Unfortunately you can't draw a table of number using just divs. It's just too slow and your users will notice. For tables of data, you have to use tables. I'm sure it's true for lots of other elements.
    - LegionMammal978 2y ago
      You can, you just have to set their "display" properties [0] to "table", "table-row", etc. The whole point of CSS is to divorce styling from the particular HTML tags. [0] https://developer.mozilla.org/en-US/docs/Web/CSS/display https://developer.mozilla.org/en-US/docs/Web/CSS/display
      - joquarky 2y ago
        If you're going that minimalist, then why even have two tags (div, span) in your toolset when their only difference is display:block vs display:inline

deleted 2y ago

[deleted]

darepublic 2y ago

I just want to say I like pre-rendering > server side. Because you get a lot of performance benefits while still writing in a client side style. It is a low hanging fruit though I suppose a combination with ssr would be better.

STRiDEX 2y ago

I have to do "real" ssr every once in a while via the django jinja html files we have to send emails. It makes me want to die coming from our nice typescript react SPA frontend. Every object is a mystery and jinja syntax is functional but terrible to maintain and of course you're suddenly using tables because it's an email. I'd rather every element be a div than do one minute of editing those stupid jinja files.

oopsallmagic 2y ago
It sounds like your issue is with the syntax of Jinja, and the hellscape of HTML email. I'm not sure how 20 MB of inscrutable JavaScript would help, considering it's also just template rendering with extra steps (bonus: using the user's CPU cycles and power instead of your own).
- lmm 2y ago
  > It sounds like your issue is with the syntax of Jinja, and the hellscape of HTML email. I'm not sure how 20 MB of inscrutable JavaScript would help, considering it's also just template rendering with extra steps 20MB of inscrutable JavaScript allows you to have a) a sane structured component system where you can actually build up UIs compositionally rather than a flat glorified string substituter (i.e. not actually "just template rendering"), and b) the control and abstractions needed to make good UIs out of nested tables.
  - sussmannbaka 2y ago
    you can compose UI on the backend without string substituting. Are you under the impress that JSX is some sort of thing exclusive to Frontend?
    - lmm 2y ago
      > you can compose UI on the backend without string substituting. Sure, but you're still going to be using "20 MB of inscrutable JavaScript". (Unless you use Wicket, but I'm not sure that's an option for emails, and would likely trigger the same complaints anyway). I mean, I hope you're not using the component style rendering layer for Python that I published ~10 years ago, because I haven't maintained it, and as far as I know there aren't any others.

ramesh31 2y ago

>CSS is fine; you’re the problem This one really gets me. Being looked at like an alien from mars when talking to people about styling a page with a few classes here and there rather than pulling in 6 different dependencies of Tailwind et. al is maddening. We are web developers. We get paid to know these things, not to complain about them being annoying and try to find hacky workarounds. And now I get to sift through your utility soup and hope to god there's a class in whatever framework you GPT'd some boilerplate for that does exactly what the designer wants.

Aeolun 2y ago
I like writing UI with Tailwind, but I have absolutely no idea why. Ultimately what I do is look up all the actual CSS values I want on their website, then stick in the proper classes. I think it must be because I have zero actual CSS to care about. There’s just nothing in my UI aside from React components, and there’s just enough sugar that it’s easier than using the style attribute everywhere.

hliyan 2y ago

While I don't agree with the tone of the author, I do have to admit, there seems to be something foundationally wrong with front-end development. Yes, it's more complicated than server development in that it is a real-time, multi-point input, multi-output (rendered elements on screen) environment with synchronisation and concurrency needs. But I used to write front end applications with MFC (Microsoft Foundation Classes, which is C++) using Visual Studio circa 2005, and it was never as complex as an SPA today. There is something wrong somewhere, and I don't think it's JavaScript or the DOM. The flaw seems to be paradigmatic.

oopsallmagic 2y ago
Your second paragraph disproves your first. Websites' needs didn't drastically increase (I'm ignoring nonsense like WebGPU; render graphics outside the web browser like a God-fearing Christian!), but their complexity did. Why? Well, we told everyone with a pulse they could make six figures "doing web development", and we're reaping what we've sown. You can still design websites like it's 2005, and they'll be damn fast. But pitch something like MFC or even PHP to a 20-something frontend developer now and watch the blood drain from their face.
- bluefirebrand 2y ago
  We don't build websites anymore, we build web apps It make seem trite but you just aren't going to have a good time building some of the stuff people build now using a LAMP stack
  - manuelmoreale 2y ago
    "We" build both. You might be building WebApps, I certianly don't and so are countless others. The web is not one homogenous thing where everyone is doing the same thing at the same time. Different people work on different projects serving different needs and we have to acknowledge that otherwise we end up in these silly tech-religious arguments where people think there's one and only one way to do things and that's certianly not the case.
2y ago

jamil7 2y ago

Maybe it’s time the author started doing something other than frontend dev?

deleted 2y ago

[deleted]

bottlepalm 2y ago

Yea I've been coding every framework under the sun since the 90s and I'm pretty happy with Next.js at the moment. It can render on the server and re-render on the client with the same framework, same language, same functions. Statically typed server to client and back to server. JSX/TSX has no strange template syntax and again static type checking. Compiling automatically tree shakes, bundles, code splits per route. I can do SSG, SSR, CSR, ISR. I can specify per route/api caching strategies. I can host serverless or self host. I'm knocking websites out left and right. It feels like I'm building a single application not two separate frontend/backend applications; managing overhead rendering and communicating between them. Next.js, Nuxt, Remix, SvelteKit - are all part of this next generation batteries included frameworks that can seamlessly transition from server side rendering to client side interactivity. $('.getResults').on('click', () => { $.ajax({ url: '/api/results', data: { foo: 'bar' }, success: function (result) { $('.results').html(result); } }); }); I mean look at this unmanageable bug prone code from the blog post. Nothing here is safe, no way to validate the classes where the data is coming from/going to. No validation of the api or its parameters. If you scaled this example you'd end up with nightmare level code. Yea I've been there already, I'm not going back.

bluefirebrand 2y ago
> I mean look at this unmanageable bug prone code from the blog post Yeah, it's hard to take any arguments about code quality seriously when this is being held up as some kind of ideal..

deleted 2y ago

[deleted]

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.
  - 2y ago

lmm 2y ago

Wow, I think this is the first time I've seen a page be wrong about so many things at once. No, the difference between header and section or p and div is not important (after you started off so promisingly by saying that content is what's important - the difference between a p and a div is not content). No, CSS really is the problem. No, you can't actually do server-side rendering in a different technology stack if you want the term "rendering" to mean anything (as much as semantic arguments are pointless in any case). Yes, JavaScript is actually the least-bad solution to every problem in web space; it's not ideal but it's a proper programming language that isn't completely nutso (just mostly nutso), which is more than you can say about CSS or HTML. If you actually want your life to be simpler, use React for everything, like everyone else. Stop worrying about how many dependencies you have and wasting your time reimplementing them worse.

briandear 2y ago
And attitudes like this are why we don’t have nice things
- lmm 2y ago
  On the contrary. The reason front-end development is so much worse than regular development is some bizarre collective fetish for avoiding Javascript, avoiding dependencies, and writing ad hoc, informally-specified, bug-ridden, slow implementations of half of React. It's some kind of Luddism meets Protestant work ethic nonsense, and I'm continually baffled that otherwise intelligent people - people who would never have this kind of attitude in regular programming - keep falling into it.
Skinney 2y ago
Screen readers and other assistive technology fully expects your HTML to be semantic. It doesn’t always matter, but it matters often enough. CSS tends to be hard because (1) people insists on having a single page with a single stylesheet and (2) only divs are used, and so they use class names for everything. If you didn’t use a SPA you’d have scoping. If you used semantic HTML you could target based on semantic structure. Both of these makes CSS easier. JavaScript is fine to use if you have to. But using JavaScript when you don’t is just wasting time. I’ve seen people essentially re-implement default <form> behaviour too many times to count, and spend time looking for solutions to problems they only have because they insist on using technology for making interactive sites when they’re making something largely static. If you want a simpler life, choose the simplest technology that will solve your problem.

deleted 2y ago

[deleted]

kristopolous 2y ago

I had been programming for about 30 years, I loved it and was excited by it. After work I would go home and work on side projects. React single-handily killed it. It encouraged, usually required, all of the awful design patterns I used to chase all the junior engineers and interns about. This has become endemic in the JS world. Here's an example: did you know that the uuid npm used Math.random up through 2020 (v.7)? Cryptographically secure random number generation had been available in basically all browsers since 2011. 9 years. If I had an engineer submit that code, I'd rake them over the coals. Speaking of that, I'd usually need a half-time engineer on larger projects just for the management of the complexity. All of the various frameworks and updates and breaking changes. It was a 20/hour a week job just to stay on top of things. For instance, koajs. It's a bunch of dependency code of quality I would never let fly, but now I have to use it and grow my team, increase budget, push back deadlines - all to manage the piles. No thanks. I left that job, quit the industry entirely about 2 1/2 years ago. Reactjs was such atrocious self-aggrandizing bullshit, it made me quit programming. It's fragile, over-engineered, mostly broken, confused poorly defined amorphous concepts that poorly solve mostly imagined problems and the entire industry of front-end is eating up that mode of design like it's some sacred text. They'll use abstract buzzword concepts that have different conflicting definitions in basically every text you pick up, and they'll never concretely define them but continue to use them as abstract amorphous blobs. I've got very popular front-end projects. I've been at the C-level of more than one company that sold based on front-end design. The first professional javascript based web app I did was in 1997. I deployed Server Side JavaScript (SSJS)/LiveWire in the 90s, a decade before Node ever existed. I've been at this for a long, long time. After dealing with react, I never want to touch that stuff again.

throwaway4good 2y ago
Could it be that you never tried to understand react and why the approach makes sense to millions of developers?
- kristopolous 2y ago
  We could waste each others time getting into the specifics but I can summarize it. It has affordances and design patterns that inexperienced, new, novice programmers find attractive and tempting but comes with all of the warts and issues surrounding intuitive patterns. That's why it takes over 10 years to get good at programming - counterintuitive insights are the clarifying beacons on any sufficiently complex project. People are "react programmers" instead of actually understanding the specs, standards, javascript, protocols or how things actually work. It's about 100 times easier to find a mediocre junior programmer than a comptent one. React allows, at a great cost of time, resources, and money, a large team of mediocre junior programmers to eventually create what once required a competent engineer and that is why it's popular. Your offshore outsourced $15/hr programming firm can now make a half-assed website or app and you don't actually need to find someone who knows what they are doing. If you've actually worked in the industry, actually dealt with code, been put on projects that are off the rails, you know this is true. You know this is exactly what is happening. Then management is unwilling to pony up the $250k to attract the right talent so you get stuck with the job of making heroic efforts to prevent the house of spaghetti from collapsing. You've been there. You've done this. You know exactly what I'm talking about.

throwaway4good 2y ago

What a silly rant. There is a huge world of different approaches to front-end and lots of them do cool and interesting things that would both up your productivity and give you completely new opportunities ... if you bothered instead of just being an old fart.

briandear 2y ago
It would be cool if all of the fancy front-end people would learn how to use HTML properly before lecturing the “old farts.” The <ol> example comes to mind.
- throwaway4good 2y ago
  You can be old and experienced and still have an attitude of being open to new things ... at least to the point where you understand them before you embark on a rant.
  - bdougherty 2y ago
    We didn't have that in the article?
- MrVandemar 2y ago
  The way some people code "HTML" these days is like an apprentice carpenter swaggering up to a house building site, and then banging in nails with the butt of their power-drill, and telling the "old fart" carpenters what losers they are for bothering to use a hammer. Use the right tool for the job. HTML is a toolbox, not a bucket of <divs> and <spans>.

acosmism 2y ago

i cant count the number of times i've had to generate boilerplate + interfaces etc etc for something that would be as simple as an onclick (onClick?) handler would have done. i have yet to actualize the serious promises of this ecosystem in any meaningful way and it doesn't seem to get better. also jsx is ugly.

robertoandred 2y ago
I can count it: zero. Onclick handlers work exactly as they always have.
- acosmism 2y ago
  sure the browser accommodates. now how about dealing with wrapping everything in unnecessary empty tags and tree shaking and bloat etc. specialized dev inspector tools for each framework etc. there are layers...
  - robertoandred 2y ago
    There are no layers if all you want to do is add an onclick handler.
    - acosmism 2y ago
      there is. there is a build system. there are probably some typescript interfaces and lint checks you need to pass etc probably some other framework you need to familiarize yourself with if you are data binding etc. i'm not saying any of this is inherently bad - what im saying is 99% of the time this is overkill
      - robertoandred 2y ago
        So don’t do that. Just open a text editor, write <button onclick="thing()">Click Here</button>, and celebrate.

tjpnz 2y ago

I fear that so much about what the web is has been forgotten. I've had some surreal discussions with frontend devs that don't have a fully formed concept of what a URL is. Their solution to "sharing" is to either have their users instruct each other using words on how to find a particular page, or to propose some overengineered URL shortening scheme to encapsulate state which belongs on the path or query string. It really feels as though usability is being treated as an afterthought.

robertoandred 2y ago

Yawn, another case of “new is bad because I don’t understand it.” Being nostalgic for jQuery? Really?

dmalik 2y ago

I agree with some of what the author is saying but add about 10 years of experience. Been coding sites since I was a kid in the mid 90s (I was a web master). I have 10 years working on brochure sites but have spent the last 10 working on major SaaS. Few things I disagree with: - The content rant was weird. I've always worked with content designers, instructional designers, or good marketing copy people. Was that about semantics? Sure ya, SEO and a11y. - Cascading CSS is great until you write a million+ line SaaS app and have 1000 devs working on the code. Then you need scope. The rant is specific to brochure sites. - SSR. Weird. Do devs really think that? I guess I'm out of touch or my colleagues are better than most. - A lot of rants seem to be ripping of jr devs. Show them the way! Very yells at cloud. - CSS nesting I really like. Example of nesting elements inside a class is a hack that should not be done. Nesting is easier to read if done properly.

hardwaregeek 2y ago

There’s a lot I disagree with but I’ll point out one in particular. > how do we make content presentable as easily as possible, with as little duplication as possible, and with as few negative impacts to the user as possible. Why is this the priority? If I wrote a language that was solely focused on removing duplicate code, and doing the minimum to appear decent, that would be a pretty bad language. I care a lot more about composability and readability than de-duplication and floor raising. Let’s face it. CSS comes from a fundamentally different situation than the modern web. I’m talking about optional styles that do not affect the content, that are written by one or two people, and likely total at most a few hundred lines. That is nowhere close to modern websites. Bemoan that all you like, it doesn’t change the reality.

polydevil 2y ago
Who says that the solely focus of CSS is avoiding duplicate code?

nate-sys 2y ago

difficult to believe that many are disagreeing in the comments. this is really one of the better "rant" posts.

joseferben 2y ago

i mostly agree with the rant, except for styling, i think tailwind is great. nowadays i default to htmx, alpine, sqlite and typescript, recently i’ve been working on a framework/starter using these tools: https://www.plainweb.dev/ https://www.plainweb.dev/

tflinton 2y ago

Why didn’t he mentioned rewriting or adding to browser history?!

rado 2y ago

He is right to rant about semantic HTML being replaced by framework div soup. It's awful for accessibility etc.

onion2k 2y ago

When I started building websites professionally (in 1998) we had an adage that people used all the time to talk about how to get traffic to your website: "content is king!" It was a play on the "cash is king" motto of small businesses I think. It was very accurate too; if you wanted traffic then you had to build a site people shared. Search engines were not as effective as they are today. Then the web changed a bit. In 2005 to 2015 (ish) people transitioned from being consumers of web content to creators of that content. We called it "Web 2.0". Content was still king because people went to their favorite sites to create things that other people would read. But anyone with half a brain could see what was coming next. Around 2015 people stopped making content for other people to spend time consuming and instead shifted to making content that was seen for as little time as was necessary for them to hit a 'like' button. 'Content' in any meaningful sense died. It became a sentence on Twitter, or a photo on Instagram, or a really short video on TikTok. The entire premise that users go to websites for the content is nostalgia. That side of the internet is effectively dead (despite some noble and awesome attempts to keep it going, HN being an example). Today very few people get paid to build static content sites. If you're a web dev you're paid to build an app that enables people to do things in a browser - and yes, that means working with something like React. All web devs try to crowbar React into everything simply because that's what they're paid to do, and they're paid to do that because that's what users want to do. Railing against it is a waste of time. The Internet today is not same as the Internet of 25 years ago.

dmalik 2y ago
Well said. Also been doing this since the 90s. I still like discovering new sites, blogs and creative things people make. HN is one of the better sites for that.
- smj-edison 2y ago
  If you haven't already heard of it, you might like marginalia. It's a search engine/website finder/experiments. I've found it really useful for finding small blogs and interesting perspectives!
manuelmoreale 2y ago

tflinton 2y ago

I literally left front end development because of stuff like this. It felt like insanity. Throwing out the door debuggers, linters, all the tooling so we could express objects as attributes?… and enforce managing state better?.. It felt like a flood of junior programmers in an echo chamber set off by an opportunistic engineers at Facebook who were more interested in creating their own job security then work to evolve an existing standard. Seriously who honestly thinks that the authors and governing board of HTML and CSS didn’t closely consider the features in react? What kind of arrogance does it take to say they’re fucking dumb let’s reinvent EVERY tool on front end because we know better. But I digress…

surfingdino 2y ago

I was recently on a project where the backend was written in Python and finished in two months. The frontend guys are still dicking around with React components eight months after the project started. The front end on this project is child's compared to the backend. It's frustrating. There was a point in the history of front-end dev when they all started calling themselves "rock stars" and became convinced that they are the future of software development. The SPA trend gave frontend devs an excuse to write unmaintainable code, gave designers an excuse to call themselves software developers, and then they all told the world they are doing "full-stack development" when Node appeared. Meanwhile they never bothered to learn pre-SPA UI, UX, or content design principles. Thing is, working on front end never gives you a chance to work on problems that backend has to deal with. I never let JS guys work on backend code, because they are lost if they cannot find a module online that does what they are asked to do, or is missing half of the features from the spec it promised to implement (always the hard ones). We then have to pick up the mess and rewrite it in Python or Golang, which is wast of time and money. I once quit when when the client showed me the Python code written by a JS dev. My devs refused to touch that shit and we went to work for another client.

rmuratov 2y ago
This is a big and poorly justified generalization.
- surfingdino 2y ago
  To be fair to good JS backend devs, my view is biased by the fact that me and my team do Python and Golang work and the only time we interact with JS devs is when there is frontend to be written. Some frontend guys are good, most of them are poorly trained and those think they can write backend code and lobby managers to let them have a go at it. With disastrous results. I have never worked with JS backend devs who were any good. I am sure they exist, but I have yet to meet one.
tasuki 2y ago
> I never let JS guys work on backend code, because they are lost if they cannot find a module online > We then have to pick up the mess and rewrite it in Python or Golang If you really must feel smugly superior, why go with Python or Golang? You could be using Haskell! The JS devs I worked with in the past were competent developers who happened to do JavaScript.

Erem 2y ago

I built a fairly successful vc funded startup with a front end lead that thought this way about frontend frameworks. For a suitably complex application what happens is that you end up organically building your own framework in order to manage the mess of application state that is the screen. Now in order to spin up, new engineers need to learn this unusual organic framework to get things done rather than just use the excellently documented React that they likely already know.

dmalik 2y ago
Ya. This is why React is popular. It's just a bunch of decently good front end best practices. Popular, not the best X for Y but with easy replacements.
mmcnl 2y ago
Yeah. Seniority should come with the realization that all tools are there for a reason and every engineering decision is a trade-off. Accept that maybe you don't know everything and be open to change your mind. All these "opinions" don't get you (or your employer) anywhere.

throw156754228 2y ago

Thank you. I'm at a css in js company and everything you wrote about it is The Truth. We've got nav menus written in reams of javascript. Stuff that could be done with zero js, or a couple of lines of glue. In a previous role I used Ant Design which were on the SASS train, trying to override the specificity of their stupidly long selectors was painful. React is too loose, it just enforces no abstraction or discipline. JSX ends up an ugly nightmare of angle brackets, ampersands and question marks. You often have to piece together how the component works by staring at all the event handler code for minutes hours days. Most of my colleagues writing it would stare blankly if I mentioned MVC. I think I would come down on the side of Angular, it's opinionated, but at least they attempted to separate the template from the controller, and logic in the services.

graftak 2y ago

In 2001 the EU switched (mostly) from a local currency to the euro. For years people would calculate prices back to the currency of old. If you do it nowadays, over 2 decades later, people look at you funny. People who still rant about the simplicity of jQuery are of the same cloth.

grishka 2y ago
Except that unification did give enormous benefits, it allowed those countries to trade more freely. The horribly inefficient JS-ass 5-megabyte-bundle SPA blogs benefit no one in the long run. By the way, on my recent visit to Europe, there still was a total in francs "for information" on the receipt from a random grocery store in Paris.
- awelxtr 2y ago
  > By the way, on my recent visit to Europe, there still was a total in francs "for information" on the receipt from a random grocery store in Paris. As an european: that's a problem. Why? Inflation. People who still change regularly to the old currency only do so for some of their finances AND romanticise the past.

csomar 2y ago

The author makes a few good points but on average sounds like an old man complaining about everything. There is a reason React took off, and there is a reason people choose React. Sure, if you are building a simple content heavy front-end, it doesn't make sense to chose a React framework or React at all. But many apps today come with heavy front-end interactions and have to sync with their back-end in real time. Good luck doing that with jQuery Ajax. And you can't blame the bootcampers. They were promised riches after a 6 months bootcamp. They were taught React and had little interactions with HTML. So they are doing what anyone else in their position will have done. So when they were out in the market, then React is was. Suddenly, everything became a React component; and if you made a website today, you'd better off start with React. In defense of React/NextJs: I have been blogging for 10+ years. I started by using WordPress. I have constantly failed to maintain a server up and running for more than a year. There is always something that comes up. A bad WordPress update, DB goes wrong, a failed payment, a bad WordPress plugin update, Server goes down because?, etc... 5 years ago, I switched to NextJS. It's a spaghetti of NPM modules just to build a very static website for very simple content. Sure. But 5 years later, the very same site is still up. There is no maintenance involved as the site is hosted in Github. Not sure I'd say the same about WordPress.

lelanthran 2y ago
> There is a reason React took off, and there is a reason people choose React. Sure, there's a reason. Doesn't mean it's a good one :-/ > 5 years ago, I switched to NextJS. It's a spaghetti of NPM modules just to build a very static website for very simple content. Sure. But 5 years later, the very same site is still up. There is no maintenance involved as the site is hosted in Github. Not sure I'd say the same about WordPress. Is 5 years considered a long time? Is that the bar? Because >6 years ago I wrote an internal site/app in C# using Jquery for front-end, and that is still up, working and being used by a few thousand people daily. It's even being extended every now and then. No NPM, no React, no Vue, no Next, no front-end build step.
manuelmoreale 2y ago
I coded this one for a friend more than 6 years ago: https://designed.space https://designed.space It runs on a basic LEMP stack (or rather a LEP since it's a file based cms) on a VPS I have not touched in years. The stack is outdated, the CMS is outdated. It runs just fine with no issues. I can move it to an up to date VPS and port it to a recent version of the CMS in a couple of hours and it would then be fine for probably another 6 or 7 years.

tobyhinloopen 2y ago

I’m with OP but we’re a rare breed.

smj-edison 2y ago

It seems he certainly hit a nerve here, regardless of people's position on the subject...

noduerme 2y ago

Arguably, for SPAs it doesn't matter what tags you use at all. Whatever you do is going to be inaccessible. Make everything a div. Who cares? We used to write all the UI components ourselves in Flash or Java. Sure, yes, understand the content that you're writing your UI around, and make the UI serve the content. That just begs the question of why one would get anal about which HTML5 tags are used for headers or navs or buttons.

Too 2y ago

This rant is missing the WHY in every section. While it has some valid points, it will unfortunately only satisfy those who are already in the same boat. The rest of us will keep wondering why he implicitly assumes that backend generated with js is sooo much worse than if was generated with anything else. I've also written my fair share of PHP before AJAX was even a word, plus lots of ASP.NET, Java and Python backends. Honestly, their templating languages all suck, compared to React components that are type safe and infinitely easier to compose and refactor (jinja anyone?). While their languages and ecosystems are a lot more powerful, JS these days isn't that terrible as a language, just keep a tight grip on your package.json. It is correct that there is something wrong with the culture of the front-end development, in that there seem to be no brakes on just piling crap on the next shiny thing and then building even more packages and abstractions around it, instead of fixing the underlying crap in the first place.

miffy900 2y ago

The entire article itself presents incredibly poor reasoning or no reasoning at all for its points. It's really hard to appreciate it now because CSS (along with JS+HTML) has been extended and upgraded gradually over the years, but CSS is incredibly good for styling and formatting DOCUMENTS - which have a very specific definition, especially back in the 90's when it was first conceived. This is what is was originally designed for. In that sense the complaints about CSS are perfectly reasonable: why are we using a document styling language for building arbitrarily sophisticated web applications when it was clearly not originally designed for that? You could say the same with HTML and JS really. > Quit acting like CSS is some giant-ass mistake that needs fixing. A group of people who were collectively smarter than us wrote those specs. They didn’t make mistakes. Assume you are making the mistake, not them. So what year again was the CSS standard was first published? Checks google quickly -- oh it was back in...1996. HTML was...1991. And JavaScript in...1995. Yes, it's well known that people in the 1990's were much smarter than people in the 2020's! It's not like there's been decades of progress since then! CSS is utterly fit for purose and bereft of any flaw or defect! Absolutely nothing new needs to be invented or discovered about front-end web development in 2024! There's no point in trying to improve things! OK, it's hilarious the author rails against things like SASS, and CSS is now being updated to incorporate many of the same features that SASS introduced: - CSS nesting: https://www.w3.org/TR/css-nesting-1/ https://www.w3.org/TR/css-nesting-1/ - Scoping (no more global): https://developer.chrome.com/docs/css-ui/at-scope https://developer.chrome.com/docs/css-ui/at-scope - Not to mention things like CSS variables, calc() etc. Usually people whine about the status quo or things staying the same for too long and in response, try to improve things. This article almost seems like a big whinge about how things should stop changing and regress or go back in time? That's not happening. If people had the author's sensibilities or attitude back in the 2000's we'd never move past `float: left` for positioning or tables for multi-columnar layouts. Utterly bizarre.

deleted 2y ago

[deleted]

nojvek 2y ago

For more than a decade, worked with many large Single page applications (SPAs) across startups and large companies. He has some good points regarding SASS. Other bits were about ranting. The issue with frontend dev is there is a gajillion bootcamps promoting it so we have a bell curve weighted heavily weighted towards juniors. Add in browser compatibility issues, framework churn and other headaches, there are fewer highly experienced FE devs who understand the browser in a deep way. FE code also tends to be highly stateful. Managing state well is one of the harder FE problems that few folks talk about. Add in the mix that some are apps and some are websites. There is no one right answer.

koonsolo 2y ago

Here is the main problem: front-end can mean "blog" on one end, and "photoshop replacement" on another.

foul 2y ago
Yeah, not only this article doesn't mention whether he slings around his own library or uses a less insane JS blob like jquery, alpine, htmx or hyperscript, he laments essentially that foundations for big webapps and cookie-cutter shit turnkey products are sold for small operations and static websites. In a lot of parts of this rant I couldn't abstain myself from thinking that he wants a web for documents and the web for applications swung around a lot of very bad habits and useless complexity in the field while waiting for wasm, aka "New Applet" to be production-ready.

shepherdjerred 2y ago

The problem isn't React. You can write a good website with React. You can write a good website with htmx. You can write a good website with HTML/CSS/vanilla JS. The average developer who cares enough to learn and use htmx/vanilla JS is going to write a superior product simply because they care more about performance and/or because they are better than the average developer. --- I'll plug my favorite way to build a site: Astro [0]. It allows you to write JSX that compiles to static HTML. You can use React/Vue/whatever as well for anything that actually needs to be dynamic. I'm not affiliated in any way, but I did build my personal site [1] with it. [0]: https://astro.build https://astro.build [1]: https://sjer.red https://sjer.red

bartimus 2y ago

I agree with many things. But: > Maybe it’s because Angular was no one’s first choice — even though it came first. Actually ExtJS was the first real framework. Angular was just one of the new kids on the block.

sebazzz 2y ago

If you want to reduce maintenance costs, reduce the amount of Javascript code and tooling. NPM-Javascript is a shitshow of constant breaking changes left and right, whether it is in your runtime framework, or your build system like gulp or more prominently webpack. Try maintaining 10 projects with these frameworks. You'll quickly look for something that is not as maintenance intensive. Example: No, you can't stay on Webpack version X, because (real example) it turned out that version of webpack relied on md5 which wouldn't work in newer node.js versions.

mmcnl 2y ago

Ranting is easy. It's nice to vent once in a while, but then what? All that remains is that the author is fed up with tools that don't solve his problems. Ok? The key difference between the web and any other type of development, is that you can distribute almost any type of application with the push of a button to billions of people, without the need to install anything. This is a superpower which _ofcourse_ comes with some complexity. Sometimes when you don't need that superpower and you have to navigate the complexity anyways it will be a frustrating experience, but that doesn't mean there is something fundamentally wrong or anything.

andreyvit 2y ago

Here’s practical experience from me running the tech side of a startup while sharing the author’s values. Server-side rendering (the normal kind from 1990s): 1. It is glorious. Everything that 37signals has to say about it is true. 2. However. I really miss React-style components as an abstraction. There are many ways around it that we use depending on the case (plain CSS classes, our own tiny Go/HTML component library, HTML custom tags), but we’re yet to produce something as ergonomic for more complex compositions. 3. We’ve added Hotwired Turbo for smoother page updates. I find it’s a lot more orderly than htmx, but we do miss some things that htmx would offer. CSS: 1. We started out with just plain CSS, using BEM and CUBE to structure it and manage complexity. 2. That still got us questioning the DIY nature of the U (utilities) part of CUBE — it got increasingly complex and random, and really just like every program grows a broken LISP interpreter inside, every custom CSS utilities library grows a broken copy of Tailwind inside. So we adopted the actual Tailwind for utilities. Tailwind is truly glorious, both for sheer productivity of writing the code, but also as a language for describing styling at just the right amount of detail — more powerful than CSS properties alone (hover:color-red-700, disabled:cursor-default), but more constrained than full CSS. 3. Tailwind introduces a build step, though, which sucks (and slows down the build by the whole second! My m2 Air can probably do a 60s supercomputer-level nuclear explosion simulation during that time.) Thankfully, part of our startup is doing custom themes for each client, for which actual Tailwind sucks even more (themes are edited at runtime, and you wouldn’t want to run actual Tailwind with its million Node dependencies on your server), so we’ve implemented a subset of Tailwind in Go, just the things we actually used, and it runs at runtime, eliminating any build steps for themes. 4. Bottom line: Tailwind is absolutely glorious as a shared design vocabulary. Non-tech people were able to adopt it and handle theming thanks to it. The actual implementation of Tailwind seems unacceptably slow, but I hear a Rust compiler is coming. JavaScript: 1. Plain old JavaScript is great, but needs some structure. We found that structure in Hotwired Stimulus, which we absolutely love. 2. But again, I do feel the desire for React-style rendering occasionally. We embed our widgets on customers’ e-commerce sites, and a chunk of HTML rendered based purely on data coming from an API with live updates is a perfect case for React. 3. Needless to say, running code on other people’s e-commerce sites is where I would never dare use a React-based stack, because I’d spend the rest of my life doing due diligence on the dependencies. (Our competitors are much less responsible about this, and it works out for them too, so this is more of a principles thing.) 4. This is probably the case where an in-house 500-line implementation of React-style rendering would be preferable to anything else. We already have a 100-line version, but it lacks many desirable features. Bottom line: Yes, you can (and should) run a modern startup based on a pragmatic server-side rendered stack, but you definitely want to add just a few modern things: something like Hotwired, something like Tailwind, some solution for more powerful components in your templates, and something like Preact for certain use cases.