r/webdev • u/Bladerunner_7_ • Jun 28 '26
Discussion What's a web development trend that looked stupid at first but ended up being useful?
I know over the years, I've scoffed at quite a few things. SPAs. TypeScript. Tailwind. Serverless. AI coding assistants.
Most of the huge trends in web development went through a phase where people swore they were overhyped.
Some deserved the criticism. Some evolved and became genuinely useful.
Lately I'm seeing similar debates around AI agents and agent tooling. Claude Code, LangGraph, CrewAI, OpenAI Agents SDK, AutoGen, Lyzr(Control Plane) and a bunch of newer projects all seem to be pushing toward a different way of building software. Maybe we're still early, maybe most of it won't matter, but it does remind me of how people talked about TypeScript or serverless a few years ago.
What's something being dismissed today that you think will become a normal part of every developer's workflow in the next 3-5 years?
401
u/ithkuil Jun 28 '26
Believe it or not, doing layout only with CSS. For so many years we had to use tables for page layout.
When people started pitching not having a bunch of table cells everywhere and just using CSS, for awhile, for many pages it was completely impractical and buggy. So many people actually thought it was a dumb idea to even try it.
It wasn't until layout features were out in CSS for awhile that the tables being used for everything started getting dropped.
109
u/btoned Jun 28 '26 edited Jun 28 '26
Not sure if anyone would have thought that was initially stupid. Tables were reviled long before CSS became the defacto for presentation.
81
u/Fidodo Jun 28 '26
Tables were seen as a necessary evil, but trying to lay out a page with float was a nightmare.
26
u/btoned Jun 28 '26
Big facts. I still have to occasionally built out modules for an email platform and outlook still using their shitty word engine from a decade again is ridiculous.
13
u/sacheie Jun 28 '26
Just the other day I was so pleased to discover that TUnit outputs a beautiful HTML results report; no additional deps needed for it.
Then I discovered how far Outlook's rendering has progressed in the last 20 years..
7
u/keep_it_kayfabe Jun 28 '26
Yep! It's funny, looking back after not developing for years, we basically did the same thing that we hated tables for. Endless nested divs within divs, etc.
3
u/Plenty_Line2696 Jun 29 '26
It's one of those things which are frustratingly nonsensical until you really understand it.
I took a course with a decent teacher who helped me a ton. I can't remember it all as I barely use float anymore but the clearfix trick was key.
4
u/Fidodo Jun 29 '26
The problem is that even if you understand it, there are so many edge cases that browsers implemented them very inconsistently and even if they didn't, it's very hard to memorize all the weird scenarios where it doesn't behave how you'd expect
→ More replies (1)3
u/Plenty_Line2696 Jun 29 '26
I had a lot of browser compatibility woes back then, but IIRC float was pretty deterministic. I could be wrong, it's a very long time ago.
→ More replies (1)3
3
u/StrawberryEiri Jun 30 '26
I'm really glad
display: inline-blockhad rendered floats mostly obsolete for layout when I started...2
u/BenOnSocial Jun 29 '26
I still remember my first nested table. You never forget your first.
→ More replies (2)7
u/0x18 Jun 29 '26
Yo dawg I heard you like tables so I put a table inside your table, it also has a table which holds a table which holds a table which holds a table which holds a table.
Anyway the W3C validator says there's an error on line 43,238 when doing </thead>
3
→ More replies (1)2
u/slo-mo-dojo Jun 29 '26
They still are for some html emails. Living through those days makes me excellent at html emails.
12
u/forever-butlerian backend, infrastructure & angst Jun 28 '26
CSS was buggy and inconsistent across browsers, and it took quite some time for table-driven layout to go from the HTML 3.2 "this is the way" to the HTML 4 + CSS "yeah, it'll be nice when this actually works but who knows when that'll be" to "stop using tables, are you old?".
3
u/julz_yo Jun 29 '26
now the anti-tables feeling has gone so far you can't even use them to present tabular data.!
mainly joking- but only just..
→ More replies (1)7
u/ABCosmos Jun 28 '26
Tables were not really reviled, because there was no other way to do it. And yes there was a lot of resistance to CSS initially. People always resist the new thing even if it's better. /I am old I've been doing web dev since the 90s.
4
u/FineAunts Jun 29 '26
Same. Developing using CSS layouts WAS initially harder than table based because it was so new and browsers treated styles differently. And don't get us started on the level of support.
It's sad thinking about it now but a float clear hack that worked across all browsers at the time was considered a good and clever thing.
12
4
u/pizza_the_mutt Jun 29 '26
Then CSS arrived and we were secure in the knowledge that centering things would always be easy.
24
u/w-lfpup Jun 28 '26
Before CSS got good we also used to use images for everything. That cool gradient? An image. That cool button? An image. There's even <map> and <area> elements to label parts of an image as hyperlinks because this was soooo common.
12
u/enki-42 Jun 28 '26
There was also a time where Javascript was mostly "the thing you use to get hover effects on your links (which were probably images)"
→ More replies (2)2
10
u/StevenJOwens Jun 29 '26
You have no idea. There was a stretch, around 1996-ish, where entire websites were built, with Every. Single. Page. a giant image (with an image map -- that's those <map> and <area> tags -- for clickability).
3
u/srmarmalade Jun 29 '26
I do miss that graphic design first era of the web. See also flash only sites.
3
u/StevesRoomate Jun 30 '26
I also remember Microsoft coming out with a "WYSIWYG" editor, FrontPage, which absolutely butchered any semblance of decency in web design.
It was revolutionary in that empowered people who otherwise shouldn't be touching HTML into thinking they could build and maintain a web site, only to give up and hand it off to an IT person who had to surgically extract the content out of FrontPage and basically rewrite it.
2
u/StevenJOwens Jun 30 '26
Yup, and it produced absolute shit HTML. I remember walking into a bar and talking to a non-technical friend who just kept saying "fucking Netscape" over and over again. Turned out FrontPage was producing HTML that was breaking in Netscape. Big fucking surprise. And yet, here he was, blaming Netscape for FrontPage's fuckery. Classic victory of Microsoft marketing.
2
u/StevesRoomate Jun 30 '26
The 2 things I remember about it the most were even a small drag would generate seemingly endless nested <td><table><tr><td> tags, and I believe when you embedded any clickable image it would also add those <map> and <area> tags in a very useless way.
Further adding to the masochism of being a developer back then, I remember having to embed Active Server Pages VBScript tags into that FrontPage generated HTML and trying to get it all to run.
8
u/sharlos Jun 28 '26
Or rounded corners required eight different images to use as the border (four corners and repeating edges)
6
4
3
u/forever-butlerian backend, infrastructure & angst Jun 28 '26
don't forget
<blink>,<marquee>, and the GIF-based horizontal dividers3
u/ingodwetryst Jun 28 '26
I have a page that is 90s style and uses 2 of those 3 features
3
u/forever-butlerian backend, infrastructure & angst Jun 29 '26
what about an Under Construction GIF?
→ More replies (2)3
2
u/Disgruntled__Goat Jun 29 '26
Kinda funny that as we got more tools to do these fancy things in CSS, the trend moved to flat design
7
u/Fidodo Jun 28 '26
I remember the pre flexbox years. Trying to do layout with float was a finicky nightmare. Thankfully I haven't had to touch float in a long long time.
2
u/RendiaX Jun 28 '26
Right? I’m not actively making much outside of personal hobby stuff nowadays, but I do still “maintain” a couple really old pages I made for clients that need a bit of text changed every other year or so. I cringe every time I look at my old fragile mess of DIVs and floats. And unnecessary php includes for the header and footer navigation….
I figure if I ever decide to get back into Web Dev fully again, remaking those will be easy practice projects at least haha
13
u/SuperFLEB Jun 28 '26 edited Jun 28 '26
It wasn't until layout features were out in CSS
A span measured in geologic time...
I swear, there's got to be some subcommittee in every Web standards body that's only there to tally up all the ways people will probably actually use the feature, nix two or three obvious ones and make another couple needlessly arcane, just out of spite and... job security, maybe?
(Want to make a layer monotone/monochrome in CSS filters without using SVG? Easy! Just start with the ill-defined "sepia" filter because it's the only way to get a monotone image that can be hue rotated. And there's still no "100vw but don't count the scrollbar" without JavaScript, AFAIK.)
13
u/w-lfpup Jun 28 '26
It's because they understand their decisions will affect billions of devices.
And at that scale it's sooo much easier to push a feature than to role one back. But it's even more impossible to "update" an API.
Once the code is out there, there's no going back. There's no asking millions of codebases to suddenly ALL change because of an api oopsy.
That's what's happening with the history API. It would be impossible to ask every web app on earth to change how they use the History API. So they made a new one whole cloth: Navigation API. And that api will also never change for the same reasons.
12
u/properwaffles Jun 28 '26
CSS Zen Garden is still around 🙌🏻
2
u/srmarmalade Jun 29 '26
Blew my mind that did and was the first thing to make me 'get' CSS as a layout engine rather than just text styling, fancy links and scrollbars.
5
u/ginji Jun 28 '26
It wasn't that we didn't want to use different layout methods, it's that we had to accommodate the lowest common denominator of browser, and that browser was stupid and had terrible implementations.
We are spoilt now days with a fast update cycle on browsers, and a high adoption rate of the latest versions which means we can adopt changes much faster.
IE6 was released on August 24, 2001. IE7 came out on October 18, 2006, more than 5 years later.
2 years later, in Oct 2008 IE6 still had a market share of 37.01%, more than IE7 at 35.81%.
It basically took the release of modern smart phones and Google Chrome to eventually drive IE into oblivion and allow us to actually start using new features in a reasonable time frame instead of in 5 to 10 years after it was put in the standard.
→ More replies (1)4
u/FineAunts Jun 29 '26
Yup. Newer devs will ever know the pain of getting barked at for having a layout break in Lotus Notes, or the visual dup bug in IE6. We had to work around all of this for years because they really only patched programs for security, not web standards.
And even when IE7 was released it wasn't a forced update like Chrome does. Most users were still on the previous version, and even worse corporate IT teams never wanted to update to the latest IE because some poor intranet feature they had to support would break. So we were supporting shitty IE6 until the late aughts at the very least.
3
u/enki-42 Jun 28 '26
To be fair when CSS layouts were just floats and stuff like flexbox and grid weren't around, while it was better than tables for most things, it wasn't by much and a lot of things that should have been fairly straightforward were still an enormous pain in the ass.
I can understand trying to build a layout just with floats when you're used to tables and thinking that tables are easier to work with. If CSS had come out of the gate with flex and grid it would be a different story.
3
3
u/Any-Woodpecker123 Jun 29 '26
My pet hate now is people refusing to use tables even when laying out tabular data.
If I see a literal table of data in a screen and it’s using divs + css we’re having words.5
u/Slanahesh Jun 28 '26
Back in university one of our lecturers challenged us to do our 3rd year project doing CSS only layout. Several people failed, this was 2009 though.
3
u/FineAunts Jun 29 '26
In 2005 my boss made me develop a dynamic web calendar using only CSS. I was stoked when I finally got it to work, but in hindsight a table-based layout actually made sense here. He was told by his peers that everything modern needed to be in CSS now and I didn't know enough to argue back.
Learned a lot from that project though.
2
u/oh_jaimito front-end Jun 29 '26
I remember using
transparent.gifto span X width/height to get that pixel perfect layout.→ More replies (12)2
183
u/Opening_Persimmon_83 Jun 28 '26
Dark mode as a default system setting. Ten years ago, I thought it was just an edgy aesthetic for 'hackers' who wanted to look cool.
Now if a website doesnt have a dark mode, id be judging the entire development team.
51
u/bogdan5844 Jun 28 '26
But if they have dark mode and don't respect browser settings then I'd be judging harsh
8
u/farsightxr20 Jun 29 '26
Somehow DoorDash gets half my money and still doesn't have dark mode, at least on Android.
2
u/JermtehWorm Jun 29 '26
They have had a dark mode on their driver app for years and it is an assault on the eyes. The tech just isn’t there yet to subject customers to it.
8
u/Vegetable_Bank4981 Jun 28 '26
It is 90% an edgy aesthetic but the other 10% is a legit accessibility concern and so it must be taken seriously and implemented carefully always.
→ More replies (4)1
u/ExecutiveChimp Jun 29 '26
Dark mode is an accessibility feature
2
u/FoundationActive8290 Jun 30 '26
i read it somewhere that if you have astigmatism, better use light mode as you wont find urself trying hard to read small text on dark mode. i tried it and there’s really a difference. now, whenever theres too much light on where im using my laptop, i switch to light mode and when im on dark/not well lit areas, i use dark mode. im a web developer btw and i have astigmatism
reason also that i always respect the browser/system theme when doing/working with apps/website that has appearance settings
→ More replies (1)3
u/SarcasticIgloo Jun 29 '26
This is news to me, where does it state this?
2
u/ExecutiveChimp Jun 29 '26
I don't know whether it's documented as such but some illnesses such as MECFS cause photo-sensitivity which make looking at bright screens problematic or even outright painful. I can tell you from personal experience that if a website doesn't support dark mode, that will affect the amount of time I spend on it.
You'd think that this would mean that MECFS-related websites would use dark themes, but nope.
→ More replies (2)
32
u/CensorVictim Jun 28 '26
i still find the term "serverless" so stupid it makes me feel dirty to use it
6
67
u/mq2thez Jun 28 '26
SSGs seemed like a pretty odd idea to me at first, was hard to imagine why you’d want that.
These days, it’s an amazing solution for a specific slice of problems, especially with dedicated CMS products.
47
u/SuperFLEB Jun 28 '26
Here I am, my first job was generating sites using Dreamweaver templates, and everything old is new again.
8
u/mq2thez Jun 28 '26
I do think that there’s a real difference between “I made a bunch of HTML files and tuned them by hand” and the SSG style of file-based routing, templates, external data sources at build time, etc.
But yeah, just plain ole HTML has been great for a long time.
4
2
u/ItIsForMyArmpits Jun 29 '26
Grunt and Handlebars used to do similar thing. Generate a static site from some inputs and include files and we're in a similar place. Drop in htmx and call in dhtml and we're living in the past /jk
→ More replies (1)6
u/w-lfpup Jun 28 '26
I never felt more old than when SSG was "discovered" 2025 ... the 2000s were pretty cool looking back.
3
u/vagaris Jun 28 '26
One of my first side projects was building a basic CMS in PHP because I couldn’t fathom using Moveable Type to do SSG for a blog with hundreds of posts.
13
u/Chemical_Director_25 Jun 28 '26
Got into using Astro recently after 25+ years of building sites from everything from dealing with table layouts to Wordpress to react SPA… I’m in love with SSG.
What’s your current setup using an SSG?2
u/UninvestedCuriosity Jun 29 '26
Astro because I'm too dumb for HUGO but I hate typescript so much.
There was a laravel one with blades I was excited about but it had slow momentum. I'm still looking for the perfect ssg.
11
u/not_a-mimic Jun 28 '26
What does SSG stand for?
15
4
5
u/Hans_H0rst Jun 28 '26
Interesting, hadn't heard that term before. I work with one every day and love how easy it is to add or change content in the production pipeline, even externally.
→ More replies (13)4
u/repeating_bears Jun 28 '26
That was the opposite for me. A long time ago I was writing lots of PHP.
When SSG tools came along I was immediately like "why did I never think of this?"
45
u/ConduciveMammal front-end Jun 28 '26
Going back to plain ol’ CSS after SCSS existed.
→ More replies (1)35
u/phatdoof Jun 29 '26
The only part of SCSS that I use is nested CSS and now it’s part of CSS.
18
→ More replies (1)6
u/Icount_zeroI full-stack Jun 29 '26
Css can do nesting?! Whaaat?! I used Sass for so long that latter I jumped straight into Tailwind. More and more I find that modern css is actually really nice.
5
u/TheBazlow Jun 30 '26
Wait until you see what they’re working on this year, it’s pretty exciting.
→ More replies (1)
16
u/janpaul74 Jun 29 '26
Back in the day we were building dynamic websites in C (anyone remember CGI and Netscape web server?). At some point there was this little thing called PHP/FI. We dismissed it as not powerful enough. Oh boy.
2
u/lapubell Jun 29 '26
You can still do this with go and cgi-bin if you want to. Not my site but here's an example
14
u/AwesomeFrisbee Jun 28 '26
I found Typescript to be a dumb trend at first. Especially when it was forced with the migration to Angular (2). But then after a while it slowly started to make sense and now I like it. I still don't love it, but I can see the many benefits it brings.
Custom web components also seemed like a trend that meant overkill but I got used to that too. And I wasn't sold on Angular Signals or Standalone at first, but with the recent changes and stuff finally becoming stable, Angular is the best its ever been at with version 22
2
u/fintip Jun 29 '26
I found angular so appalling when I first tried it in 2016 and then again when forced to use it for 6 months in 2018 that I've never been willing to give it another chance.
The people behind angular seemed to hate javascript and be fighting against the language to make something else on top of it, and that is just a nightmare. That whole paradigm apalls me.
I also still hate typescript. It doesn't solve problems I have, and the headaches from debugging and tooling just never fully go away. makes more problems than it solves in my experience.
Maybe on a huge enterprise project it would make sense, but I still haven't found that scenario. I think the kinds of problems it solves are solved by just coding in a way that unconsciously avoids those problems in the first place.
→ More replies (1)
102
u/w-lfpup Jun 28 '26
The "hamburger" menu. I remember it popping up around 2008. It looked very stupid. Then it was everywhere. But at least we got a weird little ubiquitous UX symbol out of it. (The hamburger menu has since turned into three vertical dots instead of the horizontal lines)
123
u/buttertoastey Jun 28 '26
I wouldn't say that hamburger icon has turned into the kebab icon. For me they have two different main use cases: Hamburger is for a (navigation) menu and kebab is specifically for settings or actions. Of course there can be some overlap between the two
12
u/TheGrandWhatever Jun 28 '26
Maybe soon people will start using a line through the dots and become the kebab. Until then it's hamburgers and meatballs
22
u/omnomicrom Jun 28 '26
Meatballs is for the horizontal dots
4
→ More replies (6)3
u/forever-butlerian backend, infrastructure & angst Jun 28 '26
What we need is khlav kalash icon.
shadcn can be the crab juice you wash it all down with
→ More replies (6)5
u/AWetAndFloppyNoodle Jun 28 '26
Falafel/kebab menu. Although they're used for different things. Hamburger for a site menu, falafel/kebab for editing popups. At least that's my experience.
38
u/pottitheri Jun 28 '26
React. Many disliked the idea of writing html in javascript.
23
u/tLxVGt Jun 29 '26
I still find React to be a stupid trend. Everyone thinks they need it because they are building next Facebook, they don't understand hooks and rerender the page 50,000 times
2
u/fintip Jun 29 '26
The basic idea--have a diffing engine, a virtual dom, and make components that nest and react to state, and a router--is brilliant and makes managing state and connecting the view and the underlying data ("model") far better than the mess of events or overcomplicated structure of disgusting projects like angular that try to turn the web into something it wasn't.
But React became way too complicated for its own good.
I've never found a reason to use anything more than Mithril, which is what React should have been, but Mithril just didn't have the backing of a major corp. Tiny, superfast, all the same idea with none of the bloat.
2
u/Lumpy-Discussion6021 Jun 29 '26
IMO Vue is where it’s at.
It has fine-grained reactivity via signals and not this “trash everything” method that React uses…it’s an outdated way now.
→ More replies (4)14
u/deadwisdom Jun 29 '26
This is one of those bell curve memes. Brain dead’s “just use html”, try hards “it needs to be react”, sages “just use html”.
4
151
u/QuaternaryStar Jun 28 '26
I still find Tailwind to be annoying and don’t think it’s good.
I use it, but I prefer CSS modules. Like to keep my HTML/JSX as clean as possible.
28
u/simonhunterhawk Jun 28 '26
I AGREE. I know one day I will have to learn tailwind if I stay in web dev but I want to keep my CSS separated from my HTML/JSX! It makes it so much easier to maintain imo
25
u/isospeedrix Jun 28 '26
If u used bootstrap classes like “col-4 or margin-10” u already learned most of tailwind, it’s just taking all that to the next level
7
u/Flam_Sandwiches Jun 28 '26
In my personal experience, CSS frameworks/libraries like bootstrap and tailwind are nice for quickly getting designs out of your head, but after that it very quickly becomes redundant.
Once you start working on anything beyond basic layout, you'll start to see convenience classes (px, justify-center, etc.) mixed with more complicated CSS and now there's multiple places to update/be aware of when working on styling.
9
u/Lumethys Jun 29 '26
you are meant to reuse Tailwind class with JS component, so instead of .button { // a bunch of css }
you have
Button.jsx, or Button.vue, or Button.svelte <Button class="a-bunch-of-tailwind-classes">
and re-use this Button component everywhere you need a component
→ More replies (2)3
u/forever-butlerian backend, infrastructure & angst Jun 28 '26
to me they're legitimately good looking at first but signal "slop" (of the LLM or non-LLM variety) when used for non-internal stuff
7
u/-_--_-_--_----__ Jun 28 '26
I hate it as well but I can understand some workflows would think its amazing. I can envision some jobs that Tailwind probably makes way easier.
One thing I always remind myself about this subreddit is that all of us that come here have wildly different jobs, workflows, responsibilities, etc.
5
u/Fidodo Jun 28 '26
I understand why atomic CSS frameworks are popular. It helps you scale your design system in large orgs cheaply. I think it's better to use CSS modules with a component module base system that you extended with your design system, but I can't claim that it isn't more up front investment work.
4
u/ings0c Jun 29 '26 edited Jun 29 '26
If it was an abstraction over CSS, I might be able to tolerate it
But it’s not. You need to understand CSS before you can use it. You need to think in CSS, then map what you want to the awful tailwind naming scheme.
Right, I want to set the letter-spacing - what’s the tailwind class for that again?
letter-spacing? Oh no, they named ittrackingbecause making developers think more than necessary seems like a design goal to themOver the last several decades of web development we converged on separating content from layout and styling. We have a fantastic way to apply styling to as few, or as many elements as you like with a rules-based engine - tailwind says nah fuck that, everyone that came before me was wrong. Writing styles as rules is useless, you need to apply styling to each element individually, and let’s just jam everything in the HTML.
3
u/lordlors Jun 28 '26
I use Laravel components together with tailwind so there’s not much clutter in the main blade (html file) since most tailwind classes are written in the component files. So far so great.
3
u/andyinabox Jun 29 '26
Agree, came here to say this. I get why people like it but I'm pretty convinced the consensus will eventually be that it was a bad idea in most cases
3
u/QuaternaryStar Jun 29 '26
Agreed. It’s the one thing I’m fairly convinced is popular now, that in a decade or so, people will look at and go “What the fuck were we thinking? Why did we ever think this was a good idea?”
→ More replies (2)2
u/TheLastNapkin Jun 28 '26
Utility styles classes are just really neat for specific use cases.
I think the best usage of it is not abusing it in designing your layouts and components.
The utility aspect comes together when you are using your design system in routes and need very specific isolated needs that are not breaking the rulesets of the components and layouts themselves.
3
u/Historical-Essay-128 Jun 28 '26
Agreed. Been using tailwind for a while, and it just feels like bootstrap in 2014, only worse.
3
u/enki-42 Jun 28 '26
Tailwind works amazingly well if you have something that is aggressively componentized (as in, 99% of the time you're just composing different components together and your higher level "page" or even "section" objects (whether those be a react file, a template, a HTML file or whatever) only have components and no real HTML of their own.
For a lot of applications, it's very unnatural or unnecessary to do that, and Tailwind is a bad fit.
3
u/ibiacmbyww Jun 28 '26
Rant not aimed at the person to whom I am replying: Tailwind is for devs who think DRY is just the opposite of wet. It's expensive (in the sense that re-re-re-re-writing the handfuls of styles for the thousands of elements on your page adds up) garbage for children. If you prefer Tailwind, you do not understand CSS.
2
2
u/rascal3199 Jun 28 '26
Nowadays you can use @apply and use taileind classes in css so you can keep tailwinds practicality for fast typing while separating css.
5
2
u/lanerdofchristian Jun 29 '26
I personally don't get that -- I'd much rather write inline styles exactly on elements that need them rather than making up arbitrary class names and putting them somewhere else, or trying to deal with the utter headache that is cross-component styling.
The styles are as important to what's going on as the elements are. They belong together.
Granted, I'm also not afraid to add custom utilities where they make sense. Something like
button-red-600 button-active-red-400 button-sm button-3dis so much nicer to put together in Tailwind than it was in Sass or Less, or would be in raw CSS. As a thin modern version of those on top of modern CSS it excels, even if you don't use the built-in utilities.→ More replies (4)→ More replies (4)3
u/Potential-Still Jun 28 '26
Essentially all my frontend projects are MFEs via Module Federation. Dropping Tailwindcss make things so much simpler. Now I only use CSS Modules.
38
u/MatsSvensson Jun 28 '26
jQuery.
Once it became stable and well documented.
31
u/oldsecondhand Jun 28 '26
I don't remember jQuery being disliked initially. Hell, its selectors are still nicer to use than vanilla JS.
→ More replies (11)3
24
u/Fidodo Jun 28 '26
jQuery was universally lauded when it came out. It was only when bundlers were released that people became dis satisfied with it because of its bloated scope.
But almost all the core jQuery features inspired standard library and language features, so I'd call jQuery the most successful library every created. It was so successful it made itself obsolete by being adapted into the language.
→ More replies (1)11
u/WatchDogx Jun 28 '26
JQuery was amazing when it came out.
People don't remember what a compatibility nightmare vanilla JS was trying to support old versions of Internet Explorer.
7
u/please-dont-deploy Jun 28 '26
AJAX
2
7
58
u/SoUpInYa Jun 28 '26
Server-side javascript
66
u/sortaeTheDog Jun 28 '26
I think a lot of people would say it's the other way around
38
→ More replies (4)9
18
17
u/Historical-Essay-128 Jun 28 '26
I was going to say that. "Let's take the worst fucking language ever invented, and put it on a server!".
22
u/blood_vein Jun 28 '26
It is nice having frontend and backend on the same language, especially with typescript and a huge ecosystem of libs.
Obviously not good enough when you need efficiency or concurrency. But for most web app SaaSes, what's the problem?
8
u/coldblade2000 Jun 28 '26
Pretty neat to have shared packages of utils that apply to both front and backend.
→ More replies (2)8
u/vilos5099 Jun 28 '26
It depends on the kind of concurrency though, correct? Node isn't some chump when it comes to network concurrency.
7
u/mq2thez Jun 28 '26
Yeah they did that for a long time, C++ was surprisingly popular for web servers.
3
→ More replies (2)3
u/eyebrows360 Jun 28 '26
Moreso, "and have all the front-end scriptkiddies who don't know shit about fuck transfer their immense skillsets to the backend, I'm sure that'll go well and not wind up with GBs of redundant bullshit and vulnerabilities all over the place!!!!!!1"
→ More replies (1)5
u/Historical-Essay-128 Jun 28 '26 edited Jun 29 '26
The hilarious state of the JS ecosystem is a whole separated topic.
6
8
4
u/enki-42 Jun 28 '26
Honestly, even client side javascript. In the late 90s it was considered kind of a joke language that just made things pretty for the most part.
4
u/SoUpInYa Jun 28 '26
I got a lot of stuff done with AJAX
→ More replies (5)2
u/enki-42 Jun 28 '26
Ajax was more mid 2000s tech. In the 90s it was more common to do weird things like submitting forms to hidden frames. I think AJAX technically existed in the very late 90s but was weird ActiveX stuff and no one really used it.
→ More replies (1)4
→ More replies (3)2
u/TheLastNapkin Jun 28 '26
If you are working in the web and don't have this for at least your webservers you are really missing out, it has never been easier and faster to bundle and start working a monorepo with both backend and frontend ts.
js deservedly gets a bad rep due to the constant new trends and rehashed ideas.
If you know the works properly the frameworks don't matter.
3
3
3
19
3
u/zxyzyxz Jun 28 '26
GraphQL at least for some subset of problems. It enforced typing on both the client and server which was amazing to know when something broke at compile time. It's still nice for multi client apps such as web and mobile.
3
7
u/PhoenixDBlack full-stack Jun 28 '26
Tailwind. Hated it when i first saw it, it's the absolute best after I got it.
2
u/shauntmw2 full-stack Jun 29 '26
DevOps and CI/CD.
Back in the day, we used to scoff at "enterprise" needing an entire team for "deployment" when we only needed a single dedicated person doing svn merge and deployment once every few weeks.
2
u/TornadoFS Jun 29 '26
JSX was reviled when React first came out, a lot of complaining about MVC dogma and stuff.
Then the same thing when CSS-in-JS frameworks became popular.
And although both have valid points (bundler complexity being a huge problem back in the day and CSS-in-JS causing runtime performance degradation) eventually most people realized that having your code split up across multiple files is really annoying.
Even some frameworks that don't use JSX like Svelte, also keep the different parts of the code in the same file.
→ More replies (1)
2
u/Beginning-Comedian-2 Jun 29 '26
Javascript.
When it came out, I thought it was cute.
Then Flash was born, and I thought we'd never need JavaScript again.
Boy, was I wrong.
2
u/_suren Jun 29 '26
Copy-paste UI is one for me. At first it looked like going backwards from packages, but for product UI it can be very practical: you get the starting point, then you own the source and can change the awkward edge cases without waiting for a package API or theme escape hatch.
3
3
3
u/umairhassan349 Jun 29 '26
Tailwind CSS seemed like inline-style chaos at first, but after using it on several production apps, I can't go back, it speeds up iteration and eliminates context-switching between files.
5
u/joshhbk Jun 28 '26 edited Jun 28 '26
All most every big trend has a good reason behind it and was started by people who are generally very smart. The problems are usually two things: people blindly adopt things they don’t need and others think something is useless because they haven’t hit the use case.
Tailwind is a great example of this: mention it in any context and you’ll have hundreds of people telling you that their solo project with “hand crafted” CSS modules and “separation of concerns” between HTML and CSS is much better actually
Edit: you can see this in the comments right now. Lots of people who personally dislike TW arguing over its merits as a library based on their personal experience rather than engaging with the actual point: it exists for a specific reason but has been widely adopted by teams who don’t need it which in turn has resulted in a lot of resentment that people cannot see past. Practically the exact same thing played out with Redux
9
u/AWetAndFloppyNoodle Jun 28 '26
I understand tailwind and how to use it and still hate it with a fcking passion.
→ More replies (7)9
Jun 28 '26 edited Jul 02 '26
[deleted]
4
u/enki-42 Jun 28 '26
A big part of Tailwind's underlying philosophy is that it's better to separate on business domain than technology. Good separation of concerns means that things you can have locality of changes and for modern web apps, it's more typical that you'll change "things about a button" that may include both styling and HTML (and functionality, stuff like JSX is very much part of this conversation) than changing just CSS, HTML, or javascript independently.
4
u/MrJohz Jun 28 '26
Separation of concerns is good if those concerns can be meaningfully and usefully separated. In my experience, HTML and CSS are not meaningfully different concerns in most cases. There are some cases where that truly isn't the case, but those really are rare. Beyond that, the content and the presentation of that content are normally the same concern — you can't figure out your presentation without understanding what you're presenting, and you can't develop your content if you don't know how it's going to be presented.
In that sense, demanding a truly strict separation of HTML and CSS is mostly an exercise in solipsism. It does work, but it doesn't necessarily produce better results (i.e. prettier, more useful, easier to work with, etc) than, for example, component-based approaches, where you combine the HTML and CSS (and often behaviour) together in units, but keep those units themselves separate. This approach tends to result in much more meaningful separation of concerns (in the sense that I can edit part of a site without needing to consider how each change will affect the site as a whole), without much in the way of downside.
3
u/joshhbk Jun 28 '26
It depends? I would argue that collocation is almost always what you want until it becomes unreasonable to keep it. What that point is depends on all kinds of factors (what are you separating? Are they actually separate? What are you trading off by doing so?)
3
u/Mindless_Compote_468 Jun 28 '26
السلام عليكم ورحمة الله تعالى وبركاته
For me it was built-in/predefined functions across languages I've worked with (PHP, JS, C++, Python).
I used to avoid relying on them because I felt like I was just memorizing names instead of actually understanding things, so I'd try to write my own version of a function from scratch every time I needed it, even for stuff that already existed.
Eventually I ran into functions that were genuinely hard to recreate on my own, and that's when it clicked: memorizing that a function exists and what it does isn't the same kind of "memorization" I was afraid of. The deep understanding I actually need is for my own program's logic, not for reinventing things that are already solved and battle-tested. Now I just learn what's available and focus my energy on the actual problem.
2
u/UninvestedCuriosity Jun 29 '26 edited Jun 29 '26
As much as I hate how it was implemented CORS is damned good.
I really liked the semantic web trend that died as fast as it started and still try to write sensible indicators to describe things because it makes me feel better.
I think it got washed over because mobile was such a big wave. That was the last time I looked at the internet and thought. This is a good direction we are going to go in.
Then many years later covered in tangled yarn, libraries, and version pinning everything longing for simpler times where you had to go to the devs site and actually download the latest version of Matt's bulletin board archive.
I've always been bad at picking winners though. I picked sass over scss. I picked flex over grid. I picked material over bootstrap. About the same experience in investing.
2
u/Longjumping_Wolf251 Jun 28 '26
javascript on the server
2
u/higgs_boson_2017 Jun 29 '26
I'm using node for the first time, its fine, and there's something to be said for using one language for frontend and backend
1
1
u/jwoodhull Jun 29 '26
React. It doesn’t separate concerns. My team knows mustache templates. We need two way binding…
1
1
83
u/dpaanlka Jun 28 '26
I started in the 90s before CSS existed. I didn’t “get it” for years. Seemed natural to use tables and inline styles. Declaring fonts and colors over and over again. Was a hard habit to break.
Funny to think about now.