What an annoying website to navigate. Almost unusable on an iPad.
Breaking up with JavaScript front ends
51–60 of 433 posts
Re: Breaking up with JavaScript front ends
#52Needs a (2016) in the title. The situation is even worse now.
At this point web development has become so complex and fast-changing that by the time you're done explaining how everything works the whole world has moved on to the next generation of complexity. We're almost at the point where web development is becoming "unknowable"; like knowing the position of an electron... You can know where it was at some point (maybe) but really the best you can do is estimate its rough position in the cloud.
Re: Breaking up with JavaScript front ends
#53Warning: if you want to look at the content of this page, say goodbye to your back button.
This was pretty brutal.
Re: Breaking up with JavaScript front ends
#54If this page is a demonstration of what a future without JavaScript would look like, it's an unintentional advertisement for sticking with JavaScript.
I can't tell, because their site won't render without JS enabled, and I'm not willing to enable it for them.
The title is poorly chosen at best and misleading at worst. They’re not abandoning JavaScript, they’re just abandoning client side rendering (angular, etc)
Re: Breaking up with JavaScript front ends
#55Earlier quoted context omitted.
SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.
We use SPAs and a pretty strict typescript/react stack. And I still have to know: Cloud Tech (AWS) which also includes, lambdas, Iam management, dynamoDB, cdk or serverless, API gateway, S3, secret managers etc. Add to that list the technologies that often get thrown in for extra monitoring testing etc. Jest or mocha/Chai for unit tests. Dynatrace for monitoring. Kibana or something for logs. Some tool for analytics.…
I wouldn’t say modern web dev is simpler, I just think it is more decoupled. This helps with training for & staffing the more specialized roles that emerged.
Re: Breaking up with JavaScript front ends
#56Earlier quoted context omitted.
>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, What's old is new again. There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no…
SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.
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 issue anymore. Rendering a bunch of HTML is as quick as rendering JSON.
As a vet of the IE7 days, I love this trend. Leveraging the best of server compute and browsers is going to simplify web app development a LOT.
Re: Breaking up with JavaScript front ends
#57You should break up with web based front ends and write them in Rust. :-) https://iced.rs
That's the correct answer!
Btw, client can run rust in WASM, so no reason to keep javascript in there either!
Re: Breaking up with JavaScript front ends
#58This is so overdue. I'm ecstatic to see this finally happening. The frontend framework bloat trend honestly went on ten years too long. It was like the thin client and thick client debate turned into the thick client and thicker client debate.
People will roll a gigantic create-react-app mess for the tiniest of frontend projects. Yes, it's an instant codebase! But that's all code you have to maintain. Stuff like hotwire and htmx can't come fast enough.
Re: Breaking up with JavaScript front ends
#59Needs a (2016) in the title. The situation is even worse now.
Is it really worse now though? As a full-stack developer since 2013 (Django on backend since the start, React on frontend since 2015), I think it's finally getting better in the past couple of years, and I think it was worst between 2016-2019...
After years of not knowing what to use because the libraries I've used 2 years ago are no longer maintained or their APIs changed 3 times since then, there's now Next.JS which seems like a well supported, batteries included, opinionated framework with good documentation...
with vite and esbuild on the rise, the days of fiddling with webpack and other complicated build configurations may soon be behind us...,
typescript vs. flow seems to have ended with typescript being the clear winner and having great support in most libraries, frameworks and IDEs... (although I'm a bit scared that the JS native type annotations proposal may again fragment the typing world here...)
browser-side APIs are no longer evolving so rapidly, IE11 & EdgeHTML are dead and there aren't that many features/bugs specific to Firefox/Chrome/Safari anymore...,
Re: Breaking up with JavaScript front ends
#60Probably worth mentioning that the submitted link is just the presentation by the author of Unpoly, with some history and reasoning, but the better explanation of Unpoly itself is on their website:
Essays on HTMX website also help a lot: