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

The Frontend Treadmill

polotek.net

Post reply on HN
Print view View original

671–680 of 722 posts

Re: The Frontend Treadmill

#671

Post by solid_fuel »

jmnicolas wrote: post #68
gtsop wrote: post #39

Earlier quoted context omitted.

This is exactly why I am a huge fan of ember.js Unfortunatelly it fell behind in popularity mostly due to some unimportant reasons (eg not being able to render 1M rows faster than react) and some important ones (load times), but boy did they build a stable ecosystem! I haven't seen such a commitment to stability and guardrail upgrades to this day on any other piece of front end library.

I'm thinking of building a long term living app (say an app that I will use the next 30 years). It has to be a web app so I was thinking of going pure JS. With that requirements in mind would you recommend ember.js?

I know this is kind of the contrarian opinion and I'm not trying to be "that guy", but if you want a web app that works in 30 years you would probably be best off building a server-side rendered application. You need a server, HTTP, HTML, and CSS for any web application, but you don't always need a lot of client side javascript.

The fewer things you have in your stack, the fewer things can change under your feet.

Re: The Frontend Treadmill

#672

Post by nullpoint420 »

sodapopcan wrote: post #620
nullpoint420 wrote: post #408

Earlier quoted context omitted.

> mostly with web standards IMO, the pain from "mostly" starts to show when integrating React Router v6 with legacy frameworks and applications. I'm sure if you go all in on React Router v6 it's great. At my $DAYJOB we are migrating to Remix w/ GraphQL Federation. It's been a pain. Especially because we haven't finished any of these migrations: * ExtJS -> JQuery * JQuery -> React class components * React class compon…

It's not that unique. The one enterprise app I worked on (that was started with Rails 1) had all of: Prototype, jQuery, Backbone, Angular, React, Handlebars AND mustache, vanilla CSS, SASS, CSS in JS (or whatever it's called). I wouldn't be surprised if they've introduced Tailwind at this point.

This is also a project started w/ Rails 1, so I feel our experiences may be similar.

To be fair to both code bases - it's very impressive that they're still running, right?

Re: The Frontend Treadmill

#673

Post by F-W-M »

folago wrote: post #391
evantbyrne wrote: post #243

Earlier quoted context omitted.

I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.

Maybe hire BE devs and use htmx.

Doesn't help. I just cannot center that div or make it look pretty.

Re: The Frontend Treadmill

#674

Post by adamtaylor_13 »

owebmaster wrote: post #604
adamtaylor_13 wrote: post #172

I have fallen in love with the simplicity of Rails recently. Sprinkle a bit of stimulus where you really need it. Hell slap a turbo here or there. And other than that? Pure HTML. It’s downright lovely. And it’ll still work fine 20 years from now.

> And it’ll still work fine 20 years from now. bold claim. A Rails project of 20 years would not work fine today without a lot of work.

Well not if you didn’t do occasion, very light maintenance lol.

It’s like a car. If you’re going to run it, you’ll need to do periodic maintenance.

I didn’t claim you could run it for 20 years without touching it.

Re: The Frontend Treadmill

#675

Post by adamtaylor_13 »

owebmaster wrote: post #605
adamtaylor_13 wrote: post #385

Earlier quoted context omitted.

Step 1: Resist the urge to overcomplicate. Step 2: Don't build multiple applications that need shared components. Step 3: Profit I slightly tease here, but really these are all leadership decisions that you can simply decide against. I would never implement those things because they're largely profit-less decisions. Having 2 apps that operate slightly differently is okay—even under the same brand.

your 3 steps can be summarized in just one? Step 1 - don't grow

Yep. That’s basically Basecamp’s philosophy and it’s worked pretty damn well for them.

Considering there’s a near-zero chance you won’t be starting the next Facebook or Stripe, “Don’t grow” is a great philosophy. If you do happen to hit that 0.1%, congratulations you’ve got money to tear everything down and rewrite it in the JavaScript framework du jour.

Re: The Frontend Treadmill

#676

Post by nullpoint420 »

nobleach wrote: post #612
nullpoint420 wrote: post #310

Earlier quoted context omitted.

But it _doesn't_ use web standards. It has it's own mental model and gotchas just like any other framework.

But it's based on the fetch standard and formData submission. You're literally running a server that handles those two things.

My point being, it's "based on" Web Standards, it is _not_ Web Standards.

What if I use `fetcher.submit(data, { encType: "application/json" })`? Why not just use fetch directly at that point? I believe it adds a layer of indirectness that just wasn't there before.

If web standards are so important, why don't we use `window.fetch` and `new FormData()` directly instead of wrapping it?

Re: The Frontend Treadmill

#677

Post by fragmede »

rclkrtrzckr wrote: post #311
coffeebeqn wrote: post #197

Earlier quoted context omitted.

Sorry, everyone’s on pyarn now and next month we’re deprecating that for pbun and then starting from scratch with taquito when that doesn’t solve all our perceived problems

Still using gnu make.

I'll concede that I've moved to bazelisk over make

Re: The Frontend Treadmill

#678

Post by nullpoint420 »

nullpoint420 wrote: post #676
nobleach wrote: post #612

Earlier quoted context omitted.

But it's based on the fetch standard and formData submission. You're literally running a server that handles those two things.

My point being, it's "based on" Web Standards, it is _not_ Web Standards. What if I use `fetcher.submit(data, { encType: "application/json" })`? Why not just use fetch directly at that point? I believe it adds a layer of indirectness that just wasn't there before. If web standards are so important, why don't we use `window.fetch` and `new FormData()` directly instead of wrapping it?

My favorite example of this being JSON gets converted to FormData on the frontend, which then gets POST-ed to the server, which then converts it to JSON on the backend.

Re: The Frontend Treadmill

#679

Post by cube00 »

lolinder wrote: post #478
cube00 wrote: post #449

Earlier quoted context omitted.

> This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed. Not in the current enterprise cyberops environment of needing to pass dependency security scans at all times.

It still works fine for end users, just not for the compliance department.

Depends on your SecOps. Ours shuts down apps with critical vulnerabilities if they're not patched within 48 hours.

Re: The Frontend Treadmill

#680

Post by moooo99 »

samspot wrote: post #640
moooo99 wrote: post #317

Earlier quoted context omitted.

> And Angular might eventually run out of steam, but it's been around even longer than React, if you want to count the Angular1 and Angular2+ days together. I think this is true but also misses some aspects. Take Angular as an example. Angular1 and 2 cannot be compared at all, they were basically nothing alike except for the name. This burned many developers. But Angular itself is also changing quite drastically. Not…

New Angular versions lose support so fast that they are already highlighted as risks in our TLM tracker on the first day they are released!

Yeah I also see that as an issue. 12 months for a supposedly LTS version really is not that long
Post reply on HN