Breaking up with JavaScript front ends • Hacker News Board

Re: Breaking up with JavaScript front ends

#171

Post by arcturus17 » Sat, Dec 10, 2022, 10:25 PM UTC

ostenning wrote: post #120

The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "librar…

I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing.

I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable.

Perhaps that's one dependency too many for some?

Re: Breaking up with JavaScript front ends

#172

Post by [deleted] » Sat, Dec 10, 2022, 10:27 PM UTC

artursapek wrote: post #46

You should break up with web based front ends and write them in Rust. :-) https://iced.rs

[deleted]

Re: Breaking up with JavaScript front ends

#173

Post by sheerun » Sat, Dec 10, 2022, 10:27 PM UTC

rawrenstein wrote: post #123

artursapek wrote: post #46

You should break up with web based front ends and write them in Rust. :-) https://iced.rs

> It is inspired by Elm, a delightful functional language for building web applications. That killed my interest instantly.

For me it's TODO all over

Re: Breaking up with JavaScript front ends

#174

Post by quonn » Sat, Dec 10, 2022, 10:28 PM UTC

PKop wrote: post #94

tobr wrote: post #90

Earlier quoted context omitted.

That might sound convincing to someone who already prefers working on the backend, but you can basically invert your statement to describe a typical serverless setup: “You need a frontend anyways. Shifting to a client-side codebase is eliminating duplication, and arguably browsers have better DX so win win.”

You still have to connect with data somewhere which often means running an api server connecting to database. There's certainly options to outsource this to managed services, but "serverless" and distributed systems can often be "more complexity" unnecessarily, without any corresponding productivity or functionality gain. There's a clear trend back to the server to some degree , so on the margin what I'm saying seems…

> or lack of expressiveness of writing so much app code in javascript,

???

Modern SPAs are typically written in TypeScript which is very expressive and using frameworks to structure them.

One may like or not like the tooling around it, but the language and code is just as robust and clean as any backend code.

Re: Breaking up with JavaScript front ends

#175

Post by mtoddsmith » Sat, Dec 10, 2022, 10:36 PM UTC

Problem: we hate frameworks Solution: creates new framework

Re: Breaking up with JavaScript front ends

#176

Post by 0xblinq » Sat, Dec 10, 2022, 10:38 PM UTC

aristofun wrote: post #97

Breaking up with JavaScript frameworks by creating another JavaScript framework, really?

C’mon, put a minimum effort to understand what it’s all about before making useless comments.

It is not a framework to organize your own JavaScript (like react, vue, etc). It is a framework so that you don’t have to write JavaScript in the frontend.

Of course it is written in JavaScript, because that’s the only thing that can run on the browser.

Re: Breaking up with JavaScript front ends

#177

Post by Aaronmacaron » Sat, Dec 10, 2022, 10:40 PM UTC

Micro dependencies and dependency hell are two of the Javascript ecosystem's most frequently mentioned issues. Anyone aware of any initiatives to lessen dependencies in important projects? For instance, the typical number of dependencies in a JS project would probably decrease significantly if large libraries and frameworks like webpack, babel, react, etc. all stopped using dependencies like left-pad or is-boolean (and also a bit more sophisticated ones). It would probably be sufficient if the top 1% of packages tried to remove as many dependencies as they could, because those are the dependencies that 90% of developers use. Additionally, large packages likely have the resources to implement helper libraries on their own rather than relying on them.

Re: Breaking up with JavaScript front ends

#178

Post by matchagaucho » Sat, Dec 10, 2022, 10:48 PM UTC

Web front ends have been expanding, per Parkinson's Law, to fill the bandwidth allotted.

If it's not an explosion in JS/CSS from frameworks, it's the content image/video size.

Upside is that a "fast" user experience is easily achieved by defaulting to first principle JS capabilities of the browser, and delivering compressed content from the CDN edge.

Re: Breaking up with JavaScript front ends

#179

Post by seandoe » Sat, Dec 10, 2022, 11:00 PM UTC

Welp, I couldn't back out of that site after making 100 url changes. Your argument would be a lot more convincing if you addressed that issue. That's such an old issue, please don't bring that back with your new throw-back style.

Re: Breaking up with JavaScript front ends

#180

Post by koonsolo » Sat, Dec 10, 2022, 11:00 PM UTC

The biggest problem with front-end development is that it goes all the way from static websites to complex web apps, and developers can't tell the difference.

Everyone jumps on the latest hype, going from either server to front-end, or nowadays front-end to server side, without thinking where your application resides on that scale.