Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

71–80 of 433 posts

Re: Breaking up with JavaScript front ends

#71

This 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 hotw…

I don’t see the difference. Isn’t backend code code you have to maintain too?

Re: Breaking up with JavaScript front ends

#72

This 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 hotw…

The project is originally from 2014 and the presentation seems to be from 2016.

Re: Breaking up with JavaScript front ends

#73
post #71

This 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 hotw…

I don’t see the difference. Isn’t backend code code you have to maintain too?

You need a backend anyways. Shifting to a server-side codebase is eliminating duplication, and arguably server languages have better DX so win win.

Re: Breaking up with JavaScript front ends

#74
post #27

Earlier 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 see this “AWS for everything” Well-Architected stuff everywhere. AWS benefits greatly from inserting itself in between all our architectural layers.

There’s nothing stopping companies from using the cloud for its primitives (compute and storage), maybe with managed FOSS services (RDS Postgres). We don’t _need_ to go all in on AWS to build a ‘modern’ web application. Yet somehow much of the industry dances to AWS’ tune on how to architect software.

Re: Breaking up with JavaScript front ends

#75

Warning: if you want to look at the content of this page, say goodbye to your back button.

This is not a website. It's a presentation made with reveal.js framework. This has been made as slides for a talk. It is very much feature that people accidentally don't back out of their presentation while they are doing it.

Re: Breaking up with JavaScript front ends

#77
post #45

Why can't anybody talk about the fact that HTML was not designed for being dynamic? Isn't there any format that is a real alternative to HTML, which is truly interactive, lighter than the DOM, use text as a mediu, is multi usage and platform agnostic, can use whatever scripting language, and be easily rendered? It's not another new format, it's just that a new format is needed to make things simpler. I have zero pati…

Whenever I build something on the web, I can't help but feel like I'm dealing with a word processor. A very advanced one, but nevertheless still a word processor at its heart. Coming from native apps, I despise the idea of text just being out there without a TextView or something.

I also miss Flash.

Re: Breaking up with JavaScript front ends

#78

Warning: if you want to look at the content of this page, say goodbye to your back button.

yeah, this was particularly ironic. The back button has evolved alongside SPAs, and users mostly don't expect or want their back button to take them back through the hundreds of small state changes they've caused by interacting naturally with a UI.

Because it's not website. It's a reveal.js presentation. It's on purpose so you don't get out of it when presenting.
Post reply on HN