DSteinmann's comments

In the first article you raised two issues about REST: Developers disagree on what it means to be "REST-ful", and HATEOS never took off, despite being the feature that distinguishes REST from other APIs.

In the second article you explained that HTML could implement HATEOS.

In the third article you argue that GraphQL is the natural progression of REST but its security model is complex to the point of being unsafe.

---

The first article, in my opinion, consisted of straw men arguments.

The second is understandable.

The third made no sense to me. With a system like GraphQL you can use a declarative column-based security model. This is, in my opinion, easier than the imperative stuff you're probably using to make your HTML endpoints secure. With GraphQL you need to set up your security constraints once. With HTML endpoints you need to remember to toggle off certain blocks of HTML for every single request. Is that what you're doing?

This has been reposted so many times by the author and by others that I can't help but finally ask.

What's the point? This would lead to your API being comprised of blocks of HTML which are probably only useable for one product. Why not just use REST + JSON? It would take no more than five minutes to set up client-side rendering, and you could even make it attribute-based like this with barely any more effort. Is it really not worth spending the extra five minutes it takes to set things up in a way that is reusable and standard? All I see is piles of legacy code being generated where it hurts most - in the backend.

This took me 10 minutes to cook up. It would have taken about three if I hadn't forgotten the jQuery and Handlebars APIs. This allows you to POST to a JSON API using two attributes. Untested of course, but you get the idea:

    Example: <button ic-post-to="/api/resource" ic-template="#a-handlebars-template" />

    $('[ic-post-to]').click((button) => {
        fetch($(button).attr('ic-post-to')), { method: 'post' })
        .then((result) => {
            let templateText = $($(button).attr("ic-template")).html();
            let template = Handlebars.compile(templateText);
            let resultHtml = template(result);
            $(button).replaceWith(resultHtml);
        });
    });

They can only reuse the same tropes so many times. Season 3 takes most of the "mind blowing" ideas from the first series and repackages them in a weaker presentation. The first episode was a weaker repackaging of Fifteen Million Merits (intrusion of social media rankings). I think there were two rehashes of White Christmas (protagonist being in an alternate universe where time moves slowly, which is always revealed a the end of the episode). White Chrismas did this much more effectively. Season 3 is just a thin shell around the same tropes.

For anyone reading this thread, using a 60W cabled for a >60W load is NOT FINE.

Quote: "60W is fine unless you're pegging your CPU/GPU constantly."

Translation: Your house will only burn down if your laptop goes into a busy loop.

It's not just change. It's difficult to make it work for a single version. It was difficult back when the build tools were a handful of powershell scripts. It was difficult when they moved to the dotnet tooling.

Microsoft shouldn't push out an RTM product and call the broken bits "Preview" to absolve themselves of the responsibility to deliver a reliable product.

I was evangelical about .NET Core. I stuck with it for years. I stuck with it when Damian admitted that he "doesn't build web apps". I stuck with it during the Release Candidates. It's only when they pushed this out the door and called it RTM that the penny dropped and I accepted the project had been mismanaged.

Yes, Really, and I am sure there are some people who have had no problems. That doesn't invalidate the countless hours I spent making this dreadful system work. Did you put it on your build server without installing Visual Studio on it?

What a disaster. The tail wagged the dog in the .NET Core team. Every step of the way it became clearer that this was a pet project of some ivory-tower programmers and that we would be left to patch together this mess. Try adding a .NET Core project on your build server. You'll hate yourself by the time you get it building.

> How quickly should it be doing the loading of that specific set of files

Sub 500ms? Read the solution, read each project file, read the first level of file and folder names in each project, then show the solution explorer. Anything else can go in a background thread which doesn't block building, running, or opening individual files.

I would like to see where the other 29,500ms are going.

I know that. I wouldn't touch node with a 10 foot pole (after past experiences) and since the parent comment's framework is integrated with Node it's a non-starter.

> CrocodileJS is a Node MVC framework that lets you chew apart JavaScript

Four words in and CrocodileJS is already lumped onto the 4/5ths heap of unusable frameworks (Node is an immediate non-starter in the same vein as MongoDB). Just to give you some perspective and perhaps help you see the irony.

I doubt any competent developers are even considering Angular for new projects. Not just because of 1.x but because it's not a relevant technology anymore. Everywhere I look cyclic data is the way forward. Using Angular now is like using Backbone in 2014.

> but based on what you've said, especially "I don't fancy the new and shiny. I just get things done fast and done properly", would be enough for me to label you a senior programmer.

I think that's wild speculation. That phrase could mean a number of things.

It could mean they engage in the industry, explore new technologies and make educated decisions which balance the risks associated with adopting new technologies and, in some cases, choose to use technologies that are fit for purpose but are not necessarily bleeding edge.

On the other hand it could mean they have failed to keep up with technological advancements and are using the wrong tools for the job, tools that can't deliver a modern web experience. He might be churning out shocking legacy code that someone else will have to clean up one day. Perhaps his employers are none the wiser and don't realize a different developer could deliver a better quality product in a much shorter time using the tools available today.

Given OP's examples of not knowing "Amazon" or Java Spring, both of which are ancient technology in web years, I would speculate the OP might fall into the latter category. Another strong indicator of this: OP has been doing web development "as long as [they] can remember". You'd think his coworkers or employers would have told him he was a senior developer if he hadn't figured it out himself.

Overall, insufficient information in the OP to make an assessment, but I would be very wary of pandering to someone's ego as it can do more harm than good.