[pyromaker]

I'm definitely getting too old. Back when I was just learning Backbonejs, I gulped up every single framework that came out, tried them all, every language, every variation, server side, client side, mobile, hybrid.

In the end, after all that journey, I settled into Laravel Backend and Vue3. Every app I create now is just a copy-and-paste of what I've done before. The tech stack disappears into the background and I try to actually build the features that I want to build.

I'm definitely old because I see this great work called "one" and I look at the video and I get immediatey turned off by so many "new things". It's me - definitely me. It's maybe for a different generation of devs.

[bob1029]

I've reduced my stack to C#, raw HttpContext middleware and string interpolation (aka poor man's PHP). Multipart form posts and full page reloads are my bread and butter these days. I'll still reach for Ajax and websockets if need be, but it's not the default. The entire site doesn't have to be one gigantic fucking SPA. Targeted application of the distracting shiny tech will take you so much further.

The problems themselves are way more interesting to me now. I get very upset when the tech gets in the way. I'll happily pay for licenses, fees, royalties, etc to clear the path.

It wasn't always this way though. The first decade of my career I didn't really care for the problems I was working on, so theorycrafting the tools all day was a nice respite. Coming up with principled clean architectures is a lot easier when you don't have to answer directly to the customer.

[jfengel]

Programmers love programming for other programmers. We most respect the writers of operating systems and languages. We hold them as having the deepest wisdom. But really, it's just because their target audience is us.

Doing stuff for actual customers is seen as grunt work. Their interests aren't ours, and we can't share what we learn with our peers.

So we end up reinventing the wheel just because it's more fun. And it is fun, and that's ok. Sometimes it's even useful. You just have to figure out what your real goal is, and not spend your whole life polishing your craft for its own sake.

[Vampiero]

Nah you just realized that CRUD has been the same since the 90s and that everything that gets reinvented isn't actually in the path between the problem and the solution, but pure architectural masturbation that wouldn't be necessary if web devs didn't come up with new designs for the wheel every 5 minutes.

You don't see the same bs in other areas of computer science.

[pas]

> You don't see the same bs in other areas of computer science.

It's not like databases haven't been reinvented every time there's a new fancy startup.

MySQL the OG "but web scale" DB (even with InnoDB because consistency level set to - you guessed it - "web scale"), then all the NoSQL kids because of course "web scale", then SSD/NAND write-amplification and LSM and LevelDB and whatnot and nowadays RocksDB. And there's the memcached/Redis/Valkey.

It's not like networking is not doing the same. HTTP2, HTTP3. DNS over HTTPS, how amazing it is to establish a TLS connection just to send a base64 encoded DNS question. WTF. And there's a myriad things in eBPF land, all the kubernetes-related CNI providers, and during the OpenStack years we had new overlay networks every year (VXLAN, Geneve, and I forgot the name of the other stuff), and if you go a bit closer to datacenter networking and peek into the firehose of 802.1 of new protocols you'll drown from the constant buzz over which variation of the same thing is the obviously best one! (I still remember when people started to realize that maybe there's a better and cheaper way to avoid VLAN and spanning tree problems than "just buy Cisco forever and don't forget to enable rapid STP (802.1w)" ... and then for a while there was MSTP (802.1s), TRILL, and SPB (802.1aq) and now it's managed networks all the way down, I guess)

[jeltz]

While I agree with you in general I have to disagree about HTTP3. The reason we got it is because of middleboxes preventing the adoption of SCTP. And SCTP and QUIC solve very real needs in a good way, things which we could not solve with TCP.

Maybe Google instead should have used their politucsl clout to push for Http over SCTP. But it is not like there was a suitable predecessor to HTTP3.

[pas]

One, Zero, NextJS and so on all solve real problems on the level similar to what SCTP/QUIC does. That's my point. The seemingly endless churn has very good reasons. But of course the cost of the churn is still real too.

[simianparrot]

I too am getting older (nearing 40), but I attribute this in myself to just improved pattern recognition with the now two decades plus of experience I’ve had. I don’t get excited by most new frameworks because I’ve seen it before in a shape similar enough to not waste energy on it, and know much quicker whether it’s practical for my uses or not.

[esperent]

Being around the same age as you, I agree. But also, there's a slim line between this and becoming a jaded old asshole. Very slim. I'm noticing it happening to friends of my age.

I'm trying to work to ensure that doesn't happen to me. What I've realized is that I need to take breaks - of at least months or even years - and come back with fresh eyes to the things I know well.

And I need find new things to be a beginner at so that I don't forget what that's like. I'm trying and mostly failing to learn guitar over the past year. I've taken up resistance training in a semi-serious manner in the last few months, and that's going much better than the guitar.

[Aeolun]

I think it just means I don’t jump on things any more. Certainly not if they claim to be the one true solution.

If it’s still around 5 years down the line, it might be worth investigating.

[al_borland]

This is how I look at things. I’ll let other people dance on the bleeding edge. I know enough to get my job done and if I spend the time to bring something new into the fold, I want it to be worth my time, being used for the next 5-10 years, not 5-10 months.

Chasing trends in web dev looks exhausting.

[simianparrot]

I keep myself in check by exploring software -- and most things in life -- from a first-principles perspective.

Last few weeks I've been writing a software 3D renderer from scratch not because there isn't countless of great engines out there ready to use, but because I need to understand the base principles of 3D rendering much better than I did before I tackle the technologies that have presumptions and bias towards specific problems baked in.

For my intended use case, my own 3D software blitter in JS is probably going to be good enough, but if it isn't, at least I know why it didn't work for me and I can make a much more informed choice.

This is how I approach programming as a senior developer at my job as well. And I find that asking the right questions and reframing problems before looking for technologies to solve them is one of the key benefits of age and experience. It's also why the last few places have hired me, specifically because I reframe questions and break down assumptions before I start typing away at the keyboard.

[InsideOutSanta]

I'll use whatever the client wants me to, but for my own projects, it's PHP, htmx, Postgres, Shoelace, and plain HTML and JS for everything else.

It's 10× faster than in any modern approach, there's no build step, I can sync it to any server and it just runs, the code is simple, the end result is snappy, it loads immediately, it has great UX, and I don't need to scale to a million users anyway.

[delijati]

40+; python sever side rendering + sprinkels htmx where needed; all works is fast and yes you can post forms without JS :D edit: and is still use bootstrap css because it works

[WesleyJohnson]

40+ as well; Django server side rendering and larger doses of React where we need more interactivity; but absolutely no SPA, client-side routing, etc. It's too much. And yes, bootstrap CSS (3.3.7 even!) because it still works.

[slowtec]

40-1; I use Rust for almost everything. For smaller projects I always test SPA approaches (with Rust and WASM of course), but for long-lasting important projects I would always go for boring, reliable, server-side rendering. Other client-side things remain optional (keyword “Progressive Enhancement”).

[spencerchubb]

I don't think it's an age thing. I'm 22 and I agree that I can't be bothered with learning javascript frameworks. There are too many other things to learn in our limited lives

[_1tem]

Same except for me it’s Laravel and Livewire. Not having to build a separate app on the frontend and backend dramatically simplifies development. And Livewire now has a proper component library (Flux).

[Krei-se]

custom php backend and vite with vanilla ts / fetch mostly here.

It's fast, it's secure, i implement everything myself -> it's flexible.

It's great that vite does the bundling, but it's the only job it does.

My page is now down to 2 ms response time, i don't see a reason to go back to the symfony/laravel days.

[krsdcbl]

I'm familiar with the feeling of "old, not keeping up", but rest assured, there's also other very important factors at play here:

Simply put, stuff gets much more much quicker compared to 5, 10, 15 years ago.

Not being quite able to keep up with any and all frameworks popping up and being overloaded with the size and speed of current web ecosystem is a struggle for younger peers aswell, and the days of "you even COULD check out every other new framework" are long, long gone

[coolThingsFirst]

has nothing to do with your age even at early 20s I was sick and tired of constant new frameworks in web dev.

[olavgg]

Spring Boot, Thymeleaf and vanilla HTML,CSS and JS here. I do not feel I am missing out on anything, and it is simple and easy to maintain. For dynamic content I just implement websocket and models with publish subscribe pattern.

[sunrunner]

> I'm definitely getting too old

Is it really an age thing or actually an experience thing? I see the same sentiment in a lot (though not all) of the replies here and I think the fatigue that people feel from announcements of new tools is really down to having seen the same promises of 'simpler' and 'better' before in hundreds of other tools, with none of them ever really playing out or lasting.

The simple answer as to why these tools don't last is that everything builds on and improves on everything else, but genuine 'improvement' is hard to quantify here and what we really have is changing abstractions, with the underlying contraints (browser environment) not changing as quickly due to the need for standardisation.

Web/cloud in particular is particular bad for churn in 'tools'. It seems surprising, as open source projects with no expectation for monetisation don't have a financial incentive to succeed, only the personal satisfaction of tool development and perhaps (cynically) a sort of online celebrity type of success that comes with being a known creator and maintainer of a well-used project.

For people that feel excited to learn new tools and techniques, when they stop feeling excited at this week's new shiny tool, I don't believe that's because the excitement of learning has gone, but the realisation that the new shiny is another thing operating at the same level of abstraction. Personally, new frameworks operating at the same level bores me, but deeping my understanding of the layers below is still exciting, and I personally think should have more emphasis on importance.

This doesn't mean people should feel discouraged from exploring new ideas and approaches, but it's important to realise that the cost to a creator of releasing anything into the web is virtually zero (essentially just development time), while the cost of adoption is high for every person that needs to learn yet another idea of how to structure their application and the abstractions that someone else came up with.

Web and cloud in particular seems to have a 'tools' problem, where every 'problem' that could be solved by simplifying or reducing (as general approaches) ends up just getting more tech 'solutions', but more tech to solve tech problems only serves to bury complexity.

Unfortunately it always ends up as the easier option to simply build new tools or build on top of what exists instead of developing a deeper understanding of the problem. It's also genuinely incredibly difficult to make sigificant changes to browsers as a target environment, so naturally all the tooling falls to things that can be done at development time or on-request.

Just my 2p.

[fHr]

I just spent almost a week battling with node, webpack, npm dependencies, electron. I once again don't want to touch js/ts, any fancy new framework and any FE for the coming years....

[bartread]

I feel the same. My immediate reaction to this wasn’t excitement but, “Oh fucking hell, not another one.” It’s so tiring and demotivating. Most of the cycle burning problems I deal with day to day are workarounds for quirks in the framework du jour (currently NextJS for me), and aren’t directly related to the actual interesting, value-adding problem I’m trying to solve.

I am so fed up of this churn. It is boring. It is uncreative. It is uninspiring. It is a waste of the limited time I have left it my life. All it achieves is to keep me shackled to the fucking hamster wheel and I am so tired of it.

[the_sleaze_]

I feel this perspective every single day, but then I recently went to get my old tires replaced. The people there's days are 8 solid hours of taking tires off, putting tires on, driving the vehicle over to the alignment rack and gluing weight onto wheels. All day. And they get paid pretty well all things considered.

I'm happy learn some new things even if there's resistance.

[bartread]

Yeah, I get where you're coming from. For me, though, the interest comes from the different problems we're trying to solve within the domain we're working in, not from learning yet another front-end framework.

(EDIT: Here's a great example of the kind of quirky bullshit I absolutely hate dealing with in JS frameworks: https://www.propelauth.com/post/getting-url-in-next-server-c.... Why do I have to jump through so many hoops just to get the pathname of the URL within a server component? Seriously, why are you making me write all this bullshit unnecessary code that adds no value to my end user to achieve something so simple? Absolutely ridiculous.)

I don't mind picking something up where it makes sense: over the past year I've found myself using Python fairly regularly for more data science type tasks, but in that case - again - it makes sense for the problems I'm trying to solve. It's the right libraries, the right ecosystem, the right tooling, and it's pretty stable and mature. I feel like anything I learn there is still going to be useful in 5 or maybe even 10 years.

The thing with JS and even TypeScript is that they're no longer immature technologies. Yet within the broader ecosystem around the languages we cannot seem to move beyond endlessly reinventing the wheel in very much the way we were already doing a decade ago. And, yes, there is progress, but the benefits versus the costs - to me - seem so minimally incremental nowadays as to be not worth the disruption. And the balance has tipped enough that it seems like really a lot of this churn is simply wasting peoples' time.

Like, if I'm going to learn something, I want it to really transform the capabilities at my disposal. The Python ecosystem is a great example of this but it's not the only one: I've never been a Ruby guy but I'm seriously considering picking up Rails 8 for my own interest simply because it streamlines and simplifies so much and the emphasis on realising and shipping the idea (or the value) is built-in.

[songbird23]

same, laravel and vue is best

[steve_adams_86]

Though I don’t use it regularly, it does sound like an incredibly productive combo.

I really like vue. Laravel I don’t so much, but I appreciate how boring yet well designed it is.

I often wish the js ecosystem had real counterparts to laravel. We have too many ways to do things.

[yurishimo]

Be the chance you want to see in the world! JS has all the tools required to build its own Laravel; it just takes someone to actually put them all together and do it.

[steve_adams_86]

I actually think about this quite often, but I can’t imagine myself creating something better than Adonis for example. I’m not sure I necessarily have better ideas, or equivalents which are worth sharing.

Unfortunately it isn’t a framework I enjoy using much either. There aren’t any kitchen sink frameworks which seem to cover bases quite as well as the MVC frameworks I used earlier in my career (Symfony, Laravel, Rails, Django, etc).

[redbar0n]

If only there was One.

[topnde]

AdonisJs gets pretty close to Laravel.

[nnurmanov]

Is Laravel used for backend?

[JodieBenitez]

I'm a bit old myself, I can share the same feeling and what I would call my "base tools" have been stable for more than 20 years now. But I don't have a problem adopting "new things", as long as they solve problems I actually have. If you're turned off by what is shown in the video, maybe that's just because this framework does not solve anything for you. Another reason could be that it does not fit well in your current, battle-tested, stack. Let the new generation try these new things if you don't want to, it will always be possible for you to adopt these when and if (and that's a big if !) they stand the test of time. No need to always stay "ahead of the curve", as an experienced professional, you have other qualities.

To whoever posted the video accelerated: don't do that. It's very difficult to understand what the man in the video says unless the YT speed is down to 0.75. What is the point of that ?