Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

Post reply on HN
Print view View original

231–240 of 433 posts

Re: Breaking up with JavaScript front ends

#231

Post by tartoran »

eloff wrote: post #228

I was just building a very light version of this today. I'm just a backend developer sick of the bloated crap I have to maintain in my day job with React. I'm going old school, and going back to server side templates. Native compiled jinja2 templates using askama in Rust, tailwindcss, Postgres, and a little JavaScript magic to do things like server side form validation without refreshing the entire page. I'm loving i…

It’s wonderful to build this for yourself. However, when working on our larger projects or with larger teams, they’d have to learn all the random things you came up with, in your own way of thinking and so on. That doesn’t go well sometimes but sometimes it does work out. But if you leave the project, your favorite creation could become a newcommer’s nightmare that being a reason why we need to standardize quite a bit. If someone had to maintain your code, would they feel the same way you do about the code you hate maintaining now? If the answer is a resounding no then you most likely are on the right path.

Re: Breaking up with JavaScript front ends

#232

Post by eloff »

tartoran wrote: post #231
eloff wrote: post #228

I was just building a very light version of this today. I'm just a backend developer sick of the bloated crap I have to maintain in my day job with React. I'm going old school, and going back to server side templates. Native compiled jinja2 templates using askama in Rust, tailwindcss, Postgres, and a little JavaScript magic to do things like server side form validation without refreshing the entire page. I'm loving i…

It’s wonderful to build this for yourself. However, when working on our larger projects or with larger teams, they’d have to learn all the random things you came up with, in your own way of thinking and so on. That doesn’t go well sometimes but sometimes it does work out. But if you leave the project, your favorite creation could become a newcommer’s nightmare that being a reason why we need to standardize quite a bi…

It's literally a hundred lines of JavaScript, they'd take more time to learn the changes in a point release of React. I think it's a non issue.

But the bigger thing is it's just for me, because I'm the only one working on it right now. If the project is successful and I hire people one day, they'll put up with it because I'm the boss :) Meanwhile I'll enjoy working on frontend again, something that hasn't happened in years.

Re: Breaking up with JavaScript front ends

#233

Post by poulsbohemian »

So if one were starting a project in 2022, what recommendations would one recommend in terms of framework, tooling, and/or the key questions to ask to determine the right frameworks and tooling?

(I'm using Nuxt on a project, but not finding v3 to be as stable as I expected...)

Re: Breaking up with JavaScript front ends

#234

Post by debacle »

poulsbohemian wrote: post #233

So if one were starting a project in 2022, what recommendations would one recommend in terms of framework, tooling, and/or the key questions to ask to determine the right frameworks and tooling? (I'm using Nuxt on a project, but not finding v3 to be as stable as I expected...)

If you ever intend to have more than 1 developer working on the project, just use React.

Re: Breaking up with JavaScript front ends

#235

Post by tartoran »

eloff wrote: post #232
tartoran wrote: post #231

Earlier quoted context omitted.

It’s wonderful to build this for yourself. However, when working on our larger projects or with larger teams, they’d have to learn all the random things you came up with, in your own way of thinking and so on. That doesn’t go well sometimes but sometimes it does work out. But if you leave the project, your favorite creation could become a newcommer’s nightmare that being a reason why we need to standardize quite a bi…

It's literally a hundred lines of JavaScript, they'd take more time to learn the changes in a point release of React. I think it's a non issue. But the bigger thing is it's just for me, because I'm the only one working on it right now. If the project is successful and I hire people one day, they'll put up with it because I'm the boss :) Meanwhile I'll enjoy working on frontend again, something that hasn't happened in…

Nice. Keep up then! Stay simple and nimble

Re: Breaking up with JavaScript front ends

#236

Post by hoistbypetard »

sph wrote: post #30
qrohlf wrote: post #11

Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke ro…

Unpoly is pretty good, and operates on a slightly different level than htmx, which is all about AJAX. Also, this slideshow is from 2016, when htmx was pretty much unknown.

> Also, this slideshow is from 2016, when htmx was pretty much unknown.

HTMX 0.0.1 was released as "kutty" in May 2020. That was its first release. It wasn't a thing in 2016.

Re: Breaking up with JavaScript front ends

#237

Post by runarberg »

nicoburns wrote: post #134
t8sr wrote: post #126

Earlier quoted context omitted.

Yeah, I agree - the old version of gmail was perfectly reasonable. But the current version is IMO representative of trends in web dev. Google is both influential and tends to follow the recent trends. Gmail is by no means unique - every web app created in the past few years is the same insane jumble of frameworky js code and a DOM 100 layers deep, just because someone can't be bothered to learn CSS and plain JS.

Google's frontend engineering tends to be pretty poor and out of step with wider industry practice in my experience. They have created not one, but 3 of their own frameworks (Angular, Angular 2 and Polymer), two of which (Angular and Polymer) were rather poorly performing, and the third of which is kinda ok but doesn't seem to be that widely used internally. They tried to create their own frontend language (Dart), wh…

Material Design is also Google’s fault. Regrettably a pretty sizable chunk of the industry either uses it directly or—worse—incorporates elements of it in their design.

I also have a pet peeve with the Roboto font family developed by Google and used everywhere on the web. But I’ll admit that it is a fine font face for its purpose, just very boring and used way too much.

Re: Breaking up with JavaScript front ends

#238

Post by riversflow »

0xblinq wrote: post #146
nicoburns wrote: post #113

Earlier quoted context omitted.

Gmail is just poorly written. The old version of Gmail was still an SPA, and it was perfectly quick.

Well, get ready for it. GitHub is moving towards React, Next, etc. I bet it will be another disaster like Reddit.

I’m actually happy about how garbage reddit is. I considered installing a redirect plugin to send me to the old.reddit subdomain[1], but ultimately decided I shouldn’t encourage myself to use Reddit, having it load into that dumpster fire of a front end has really helped discourage me from using or interacting with it. I can happily report my reddit usage is at an all time low!

[1] fun fact, you can shorten this to “ol.reddit.com” which is nice because it only requires one hand to touch type “ol.” and get an autocompletion. I always thought reddit was a great name because for right handed users, “redd” could be typed with the hand that would typically stay on the keyboard and would 100% get an autocompletion. Alas, most users are now on mobile.

Re: Breaking up with JavaScript front ends

#239

Post by aussieshibe »

quickthrower2 wrote: post #164
aussieshibe wrote: post #151

Maybe it's just me, but needing to press "back" twenty or so times to get back to HN after viewing some of this presentation really made me question the author's authority when it comes to "how the web should work".

Not sure. Does everything on a public url need to be friendly to random forum shares? Maybe this is good enough for the people who needed to see it.

It doesn't need to be, but it certainly undercuts the message a bit if it's not.

Re: Breaking up with JavaScript front ends

#240

Post by ducharmdev »

boxed wrote: post #122
qrohlf wrote: post #11

Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke ro…

I've tried to use htmx exactly two times. Both times it just ran directly into a brick wall, because it's so limited and has no escape hatch where you can put your own logic. Their solution to this is their half baked new language, which isn't ready, a new language, and seems very much unclear. All they needed was proper hook points.

I had this same experience. I thought it sounded like an interesting idea, but in practice I didn't think it lived up to some of the hype it often gets on HN.
Post reply on HN