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

391–400 of 433 posts

Re: Breaking up with JavaScript front ends

#391

Post by antifa »

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've only used laraval and knexjs over the last 10 years and have no idea which ORMs people are complaining about because the ones I used do not have the issues they talk about.

Re: Breaking up with JavaScript front ends

#392

Post by antifa »

traverseda wrote: post #366
phist_mcgee wrote: post #327

Earlier quoted context omitted.

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

Unrelated to the debate at hand, my front-end team's junior members' only known design pattern is drop-all-state-on-refresh-driven-design and it pisses me off.

Basically every part of the website written before their time functions correctly.

Re: Breaking up with JavaScript front ends

#393

Post by CharlieDigital »

siquick wrote: post #273
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…

If those are the only complaints you have about Next then they’re doing great.

Those are on top of why React is not the way.

Re: Breaking up with JavaScript front ends

#394

Post by diroussel »

pjmlp wrote: post #63
strife25 wrote: post #56

Earlier quoted context omitted.

Labor wasn't the issue, it was UX. Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc. Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an i…

Ajax was created by Microsoft to show Outlook on the browser....

Not quite what I remember. XMLHttpRequest was invented by Microsoft and used in a outlook webaccess. This was only possible in IE6.

But Ajax is merely a pattern that was enabled by the ‘dynamic html’ that was made possible by having a DOM and JavaScript. It was possible in Netscape years before IE6. I did a production app with Ajax in 1999, using IE4. Before the term Ajax had been coined.

Re: Breaking up with JavaScript front ends

#395

Post by CharlieDigital »

arcturus17 wrote: post #212
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…

I don't understand the "right amount of control" bit, there are plenty of options to control what data moves to and fro in NextJS, but the CEO of Vercel has replied to you in a sibling comment; he's going to be able to address your technical concerns better than me. I'll just add that I'm not familiar with either of those sites, because I'm sitting in Spain and neither operate here, but on first inspection the UX has…

> I don't understand the "right amount of control" bit

Try Astro.js and you'll understand. If the data has been used to SSR and has no function on the client side, don't send it to the client.

If two multi-billion dollar, multi-national corporations with multi-million dollar project teams can't get it right in a space where every ms counts, then the average team has no hope.

Re: Breaking up with JavaScript front ends

#396

Post by mckravchyk »

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 use React and Svelte for different projects. I keep things really simple and it's rare that I need to rely on an external runtime dependency (build tools are another thing), if something is relatively small I will code it myself. I have also built my own state management library (not open sourced yet) that is literally exactly what I wanted out of state management, so I don't need to rely on gazillion plugins to make something possible, I just code it myself.

Re: Breaking up with JavaScript front ends

#398

Post by yencabulator »

thrdbndndn wrote: post #264
triskweline wrote: post #103

Earlier quoted context omitted.

Unpoly lead dev here Unpoly takes special care to always move the focus to the next relevant element in an interaction. E.g. when a link updates a fragment, the focus is moved to that fragment. Or when an overlay is closed, focus is returned to the link that originally opened that overlay. More details can be found here: http://triskweline.de/unpoly2-slides/#78 Feel free to install a screen reader and play with the d…

Probably the right place to ask this: The slide said > DEMO OF SERVER-SIDE APP ISSUES > Link to demo app ( https://demo.unpoly.com/ ) > (press Start Classic on first page) but there is no “Start Classic”?

The slides are out of date, both when they talk about the demo and in API details.

Re: Breaking up with JavaScript front ends

#399

Post by taeric »

johnthuss wrote: post #191
taeric wrote: post #184

Earlier quoted context omitted.

You didn't even mention GWT. I don't know what is causing it, but yeah, Google has dropped some turds over the years.

The original version of GWT was mainly about solving compatibility issues between browsers (of which there were many). Modern GWT/J2CL is all about leveraging the mature Java development tools, especially code completion. GWT can be used with just the standard DOM APIs very effectively these days via the elemental2 library.

Apologies on the slow response.

That makes sense, but I also recall it was about trying to use the same language on the server as the client. And it worked as well as the efforts to use JavaScript is the server. Which is not to say it can't work. There are a lot of traps there, though.

Re: Breaking up with JavaScript front ends

#400

Post by heather45879 »

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…

Yeah the frameworks do force a disciplined approach. It still boils down to separation of concerns like presentation from business logic etc. Historically the front-end computation existed on the backend but with NodeJS everything sort of mushed together (creating more complexity and possible architecture mistakes). Template libraries are great way to Split View from Model—but even that is taken care of in languages now like Golang templates and JavaScript template literals etc.

I suppose the question is: how much time does it take to master stock HTML5/CSS/JavaScript versus mastering a framework, through-and-through.

Frameworks are constantly in flux but the foundation they are built upon is a more lasting skill set. But the more we spend learning framework X we are spending time away from foundations.

Post reply on HN