HN user

toadkicker

102 karma
Posts1
Comments32
View on HN

PAP is a protocol for zero trust AI agents. It features several examples including e-commerce transactions. Built on existing standards.

We Hire Old People 5 years ago

"Have you worked at a FAANG or on FAANG level problems?"

"I have not, do you have those problems with 10k users too?"

Ironically Apple is also the ones who kicked off the entire PWA race because of the lack of an SDK when the iPhone launched. The messaging then was "build for the web, that is better than native" and now its "native or gtfo" and web apps are not preferred. The last 5 years that I've built web versions of apps first, the client told me "look the web app is great, hard to tell its a web app honestly. Except when I want to..." and you all know the rest of the conversation from here.

Firefox, I love you, but you're bringing me down. We need a powerful, semi-native, offline capable architecture for the web. I don't care about the PWA spec, it's quite messy handling the implementation of one. But I do think it has always been the vision that the web is accessible regardless of physical connection to it.

As long as I can remember in this industry we've swung back and forth between "thin" and "thick" clients as if one way is the right way. Microservices over monoliths, etc. It's all the same symptom that naturally we don't want to grapple complexity. This announcement is yet another entry in the cannon of thin vs thick. It's a hard problem and any PM who only cares about optimizing time spent will say everything they can once they've zeroed in on the perceived waste.

One of things I absolutely despise about the JS community is this obsession with build tools. JS is meant to be a runtime language and the amount of transpilers, minifiers, uglifiers, obfusicationifiers, is absolutely endemic to the messy state of change the language is undergoing.

However with this release I'm excited to start deleting a bunch of ridiculous build code to make Webpack work. Really a build tool is a tool, it should never be in the way of developing features. I haven't enjoyed using webpack until now. No sensible defaults, poor documentation, and no standard conventions. This release changes all of those complaints. A boost for productivity is a win in my book.

Their QA department has been in a downward spiral since 2014. I would love to name some people who were doing a fantastic job running the place until then, but I'll spare the embarrassment. This really isn't about some mega company not caring as much as one of their cornerstone departments being unable to function effectively.

I just wanted to add some positive comments here complaining the state of the web as we know it today vs. the people who are working on the solutions to the problems. There are well defined paradigms for building distributed systems. While much of the web was built in the belief these distributed systems would take root, lots of engineering went into client-server configurations. There are a ton of psychological reasons why these decisions were made. They don't have to keep being made though. We can all embrace distributed applications (some call them serverless applications) and free the web once again. Here's a lot of great projects that are trying to do just that: http://github.com/toadkicker/awesome-ethereum

In the second article the author explains what a 'JSON pure' api would function. It completely throws out the OSI model and provides no way for the application layer to react to transmission errors, which HTTP codes provide.

It's really silly that is how the culture behaves. The right tool for the job is a common moniker in other industries, yet in ours its the source of heated debate and hipsterdom.

This is the way good things get done. New ideas should come from anywhere they can and the best ones bubble up into the product. Always reset expectations if anything that does get said ends up being misread. Let's face it; text is a horrible medium for communicating complex ideas. Open the communication channel accepting things at face value.

So what exactly is your point?

Our designers strive to create layouts that best fit the business and shouldn’t be limited by what framework we choose to use on the front-end.

Name any framework that doesn’t have an opinion about how to do something. A good developer is also one that sees a design and knows what tool fits it best.

To use Bootstrap efficiently and understand it well you need to dedicate time to reading through the documentation, digging into the source code and figuring out how to customise it for your requirements.

Again, name a framework that requires 0 documentation reading time on the part of the user.

Bootstrap doesn’t follow best practices or good semantics

This is an opinion best served by backing up what you feel good semantics or best practices are, because often times frameworks define what those best practices are.

I didn't want my comment to devolve into an argument about the merits of static vs. dynamic. My comment is really to ask why would I use Typescript for web programming? Where does it fit? It doesn't seem to fit in or fill a need that isn't already possible with any combination of static and dynamic languages used separately. In fact I feel it blurs the separation of concerns between static vs. dynamic.

All the same that Wordpress could easily adopt using environmental variables for configuration values to achieve this and simply use a heroku-ified version of config.php. I've used this approach for scaling wordpress sites and its never failed me.