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

361–370 of 433 posts

Re: Breaking up with JavaScript front ends

#361

Post by cies »

vbezhenar wrote: post #290
throwaway999528 wrote: post #216

Earlier quoted context omitted.

Throwaway for anonymity. I work at a place that is mostly like this, I can tell you that using html/css/javascript raw, with a bit of bootstrap is a nightmare with a SPA. Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous. There are modern affordances in many of these frameworks others take for granted.

I agree. I like pure JS, but it just does not scale by default. You need to have awesome architecture skills and you need to constantly observe your codebase, you need to write half of framework if you want to avoid frameworks. Of course it's possible, but it's not possible for vast majority of developers, including myself. May be we need some education: how to write 100 kLoC pureJS WebApp and keep sanity. I didn't s…

Did you have a look at Elm? Even more easy to structure maintainable apps.

Re: Breaking up with JavaScript front ends

#362

Post by zelphirkalt »

What most people do not get is, that modern frameworks long have allowed for a mixed approach. One can easily render templates server side in a backend non-JS framework and merely use some VueJS or whatever for a really interactive component on one of those rendered templates. Can even have a noscript block. It will be easy to understand code, work without people having to trust JS code, except for those few interactive parts. No harm done. Instead people go all in and think that it will be better to have everything in JS as an SPA.

This SPA unnecessarily approach eats up so much time, it is not rare for things to take weeks instead of days compared to simply rendering templates on the server side in a better language than JS.

It should be a simple thing to understand: Use the right tool for the job. Not JS for everything, just because of hype. But I guess part of the issue is the mentality of some frontend people to only learn JS, so they are incapable to going for the mixed approach.

Re: Breaking up with JavaScript front ends

#363

Post by cies »

Aeolun wrote: post #303
CharlieDigital wrote: post #197

Earlier quoted context omitted.

Next.js is really bad, IMO and perpetuates more bad practices. Both Target.com and Walmart.com are Next.js apps. Both utilize SSR to render the pages (view the markup in the network tab). Both then STILL send the full data model to the UI (check the `__NEXT_DATA__` on Walmart.com and `__TGT_DATA__` on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to A…

Next.js is really easy for developers of all levels to work with though. It’s main benefit is the ease of use, not the optimized client side data transfer. What I see from Astro.js is a lot of magic. This is great if it works, but chances are it won’t for a lot of people.

Did you try Qt and QML for creating a GUI? It's soo much easier on the brain its not even funny.

Re: Breaking up with JavaScript front ends

#364

Post by cies »

JackMorgan wrote: post #354
jiggawatts wrote: post #298

Earlier quoted context omitted.

"I haven't died playing russian roulette, you should try it too." The general experience across the industry in a statistical sense is that JavaScript frameworks are a tyre fire best avoided. I'm yet to see a JS app that doesn't need constant maintenance to remain compilable. Meanwhile, the ASP.NET ecosystem had like one significant breaking change since like... 2002.

JavaScript itself is entirely backwards compatible back to 2002. If anything, I'd argue raw .NET is far worse than raw JS for backwards compatibility, because .NET has depreciated entire languages like VB6. To compare something like React to .NET, let's look at .NET libraries and frameworks. For example: Sliverlight, WebForms, WPF, WCF SOAP, old versions of EF, or old versions of MVC. It's not been pretty for .NET, a…

Now lets compare it to Qt and QML? They seem to be pretty stable GUI libs

Re: Breaking up with JavaScript front ends

#365

Post by traverseda »

kaba0 wrote: post #334
heather45879 wrote: post #277

Earlier quoted context omitted.

The underlying issue with web applications is that it’s like a square peg going in a round hole. Remember, HTTP is designed traditionally as a stateless protocol delivering static web pages, more or less. But here we are, with stacks-on-stacks-on-stacks of layers emulating what truly should be a native application. “Web Application” should not be a thing. HTML/CSS were supposed to be for content and presentation; Jav…

Things change. Just because it was originally made for documents doesn’t mean that it hasn’t undergone such huge changes that it can literally drive FPS games at 60fps without a sweat. And I say that as someone who really doesn’t like many of the underlying abstractions, imo CSS+HTML are just thoroughly badly designed, none of them would be whole without the other resulting in extreme close coupling (layouting for ex…

Ordering a pizza can be done with static pages and some forms.

You want to make photoshop or a CAD program? That is an app. You want to order a pizza? Just use html and forms, maybe javascript to reload the progress page once per minute. (You don't need websockets or SSE or anything to check pizza progress)

Re: Breaking up with JavaScript front ends

#366

Post by traverseda »

phist_mcgee wrote: post #327
throwaway999528 wrote: post #216

Earlier quoted context omitted.

Throwaway for anonymity. I work at a place that is mostly like this, I can tell you that using html/css/javascript raw, with a bit of bootstrap is a nightmare with a SPA. Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous. There are modern affordances in many of these frameworks others take for granted.

Everyone's a "pure html/css/js" gangster until they have to maintain state.

Put your state in your urls, or in the user's session model, that's the only place state should be allowed to live :p

Re: Breaking up with JavaScript front ends

#367

Post by zelphirkalt »

krapp wrote: post #15
ramesh31 wrote: post #12

Earlier quoted context omitted.

Yeah, perhaps if only there were a structured markup language that could be used to provide this information in an accessible manner with separation of concerns between content and display.

impossible!

Frontend guy: I've heard about a new framework, which dynamically loads content from APIs!!11 With that we can surely manage to do this!

Re: Breaking up with JavaScript front ends

#368

Post by heather45879 »

llanowarelves wrote: post #222
throwaway999528 wrote: post #216

Earlier quoted context omitted.

Throwaway for anonymity. I work at a place that is mostly like this, I can tell you that using html/css/javascript raw, with a bit of bootstrap is a nightmare with a SPA. Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous. There are modern affordances in many of these frameworks others take for granted.

It's like ORMs and game engines. Many times when people try to forgo them, they end up making their own poorly specified and half-baked version of it that only some people (who may leave the company) understand.

I don’t think ORM is the same since it’s more of an API than a framework (in my mind). ORM also falls into the platform-abstraction arena because it typically has multiple backends which provides other benefits. It also is served as a wrapper library converting from one language to another (SQL).

Web frameworks are more like… clever hacks to HTML to wedge in a “new way to do it” more clever than the last attempt.

Game engines are also somewhat different because the level of abstracted complexity there is vast and heavily domain-specific. It targets multiple platforms like ORMS and multiple GPU backends as well. It provides physics APIs and other heavy maths capabilities too.

But the browser standards-bodies provide that for us now. HTML5/CSS3/JavaScript will run well across all modern browsers.

Re: Breaking up with JavaScript front ends

#369

Post by sir71 »

This dance, shuffling code between backend and frontend, has been happening for a long time. It's not the first and not the last time someone claims to have found a solution (not even the best, just a solution for certain scenarios). That is fine until the client comes up with a new requirement that completely demolishes your assumptions, or some new awesome JS API appears, and then we're back to SPAs. Ups, who could have known, right? A couple years later, browsers adapt and a bunch of people, again, come up with a revolutionary idea: if we squint a little we can just about squeeze that code on the backend and save a bunch of work. Until new big products come out that change what users consider state of the art and...

It's a never ending cycle.

SPAs are a pain in the ass, like all distributed systems are, but they're also the most flexible and you don't need to reinvent half your framework or use dirty hacks if you have to do something slightly out of the beaten path. They're not the problem.

The real friction comes not from where you put the code but from the fact that you have to use different languages with different ecosystems. I'd claim most of the arguments against SPAs would suddenly disappear if one could write most of the code in whatever, compile to WASM, and slap a generic JS bridge on top.

Post reply on HN