241–250 of 433 posts
So if one were starting a project in 2022, what recommendations would one recommend in terms of framework, tooling, and/or the key questions to ask to determine the right frameworks and tooling? (I'm using Nuxt on a project, but not finding v3 to be as stable as I expected...)
If you ever intend to have more than 1 developer working on the project, just use React.
Earlier quoted context omitted.
I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing. I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable. Perhaps that's one dependency too many for some?
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 is nothing more than yet another bloated collage of poor ideas with poor execution, but they have marketing going for them.
We started before Promises were standard, before composer and NPM. Before Virtual DOM. Back when we started, there was CodeIgniter and Kohana and jQuery (anyone remember?)
Along the way, we kept the vast majority of our code in-house. We didn’t want to pull in libraries or updates unless we understood their code.
Looking at the latest and greatest, we were often wondering if we did the right thing. Some developers (especially JS) used to chastize us for not using the latest techniques like “two way bindings” of Angular 1.0 or JSX of React
Then - lo and behold - Angular 1.0 is totally rewritten and all those concepts are redone. Over and over. And people come around to our way of thinking. Web Components and Templates appear. Shadow DOM.
Our way of thinking is: use standards for HTTP/REST, HTML, HTTP, JS, CSS as they were intended. Every concept should work well with all the others.
Result is at https://github.com/Qbix/Platform if you want to give any feedback. We have been using it for ALL our projects since 2011.
Earlier quoted context omitted.
Yeah, I agree - the old version of gmail was perfectly reasonable. But the current version is IMO representative of trends in web dev. Google is both influential and tends to follow the recent trends. Gmail is by no means unique - every web app created in the past few years is the same insane jumble of frameworky js code and a DOM 100 layers deep, just because someone can't be bothered to learn CSS and plain JS.
Google's frontend engineering tends to be pretty poor and out of step with wider industry practice in my experience. They have created not one, but 3 of their own frameworks (Angular, Angular 2 and Polymer), two of which (Angular and Polymer) were rather poorly performing, and the third of which is kinda ok but doesn't seem to be that widely used internally. They tried to create their own frontend language (Dart), wh…
Is there a tool for this? I’m kind of wanting to check my site now…
So if one were starting a project in 2022, what recommendations would one recommend in terms of framework, tooling, and/or the key questions to ask to determine the right frameworks and tooling? (I'm using Nuxt on a project, but not finding v3 to be as stable as I expected...)
2. If you’re already familiar with Vue, and have no problems with it, the only reason I’d stray is because stuff in JSX-land is getting around to addressing many of the problems people (rightly or wrongly) complain about here. Weather React Server Components, Qwik which ships minimal JS bundle and data by design, or Solid with recent support for partial hydration… the component story being good for UX is increasingly compelling for JSX. I wouldn’t recommend any of these in particular unless you share more about how you’d prefer to develop.
3. If I were to recommend any meta-framework it’d be Astro. I’d have stronger recs for Solid Start but it’s explicitly not stable at present. Astro also has the benefit of being UI library agnostic which is a good gradual story.
4. Take literally all of this with a grain of salt. Part of the reason all these tools have a bad rep is from trying stuff when existing tools are imperfect but serviceable. Happy to share some ideas of where to look, but if I’m choosing anything for my current projects under maintenance I’m starting with how they can be adapted and reconfigured to solve whatever problems they don’t already solve. I’m only even looking at other tooling because there’s serious gaps in the existing setup.
1: Porting a legacy XML-centric project away from proprietary server dependencies which take ~8 min to build and has gobs of incidental complexity and tons of performance problems… to run in a browser really fast. It took a few minutes to figure out how to set up the project to load static XSLT assets as ESM modules, as well as dynamically loading XML payloads both from local fixtures and as library input. Builds are instantaneous and runtime is fast enough I can sell running it in a headless browser as a major incremental improvement. I can probably also sell scrapping a whole server target, or at least its persistence layer, because it’s fast enough the primary responsibility (caching) is either moot or solvable in the browser.
Earlier quoted context omitted.
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’ t…
Maybe it's just me, but needing to press "back" twenty or so times to get back to HN after viewing some of this presentation really made me question the author's authority when it comes to "how the web should work".
Earlier quoted context omitted.
Unpoly is pretty good, and operates on a slightly different level than htmx, which is all about AJAX. Also, this slideshow is from 2016, when htmx was pretty much unknown.
> Also, this slideshow is from 2016, when htmx was pretty much unknown. HTMX 0.0.1 was released as "kutty" in May 2020. That was its first release. It wasn't a thing in 2016.
intercooler.js started in 2013
https://github.com/bigskysoftware/intercooler-js/commit/62d3...
Seems like a half-baked agency-built version of htmx[1], no? 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, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke ro…
I've tried to use htmx exactly two times. Both times it just ran directly into a brick wall, because it's so limited and has no escape hatch where you can put your own logic. Their solution to this is their half baked new language, which isn't ready, a new language, and seems very much unclear. All they needed was proper hook points.
it does, however, have an extensive event model to hook into, including pre and post request processing:
https://htmx.org/reference/#events
as well as an extensions API:
https://htmx.org/extensions/#defining
for client side scripting, I think you are talking about hyperscript, which is definitely more speculative than htmx, but I wouldn't call it half baked: a lot of people are using it successfully in production
a less-esoteric alternative would be to use alpine.js, which is similarly embedded but uses plain ol' javascript (and offers reactivity as well, hyperscript is more of a pure event-driven language)