I'm sure this has probably been posted before, but it never fails to drive me nuts, and customers never stop doing it, so:

Why do end users think "it's broken" is all they have to put into the support ticket?

It's a web app, not a goddamn pretzel.

If the turn signal on your car stops working, do you drop your car off at the mechanic, hand them the keys, and say "its broken, fix it!"?

While I'm on the topic, "I tried to do {x} and it gave an error" is better than "its broken", but still: why do you think what the actual error says would be completely irrelevant, especially when we put in the effort to give you relatively meaningful error messages?

I mean, is "there was a problem sending the email" so utterly gibberish to you that it is indistinguishable from "error: 0x000351e6"?

If so, I'm sorry, but you're too stupid to use a goddamn computer!

The brief history of Facebook open source:
- FB releases React under an oppressive licence that tells "woopsie, can't sue FB if you use React"
- a lot of money goes into making React popular to gain leverage from mass adoption
- VMware bans React in their company
- FB releases Flux to bring state management. It flops. Replaced by what some Russian student wrote in several evenings (Redux)
- Preact is released. It's faster than React, and it has MIT licence. Vue beats React in GitHub stars.
- Under mass pressure, FB changes React's licence to MIT. Initial plan to gain leverage fails spectacularly.
- FB releases Flow Types. It flops. Replaced by TypeScript.
- FB releases their own app market for React Native. It flops.
- FB releases Relay. It flops. Replaced by Apollo.
- FB tries to push React.Suspense for the whole JS landscape to obey and comply to how it works. Community says "Fuck You".
- FB releases react-native-web. It flops.
- Web Components are out in all browsers, adopted as a standard. React doesn't support them.
- Google releases Lit, a virtual DOM framework on top of Web Components to fuck with React. It's a massive success.
- React 18 is out. Still no Web Components support.
- (you are here)

One thing every junior web developer learns is how to implement a login system.
They may not make it the most secure, but it works.
It boggles my mind how Microsoft still don't know how to make a login that works consistently.
Every Microsoft login page requires like 30 redirections to work.
The Teams app on my PC fails to login at least once a week, just because another Microsoft app is logged in using the same account (usually office), but Windows is not.
Microsoft needs to take it's head out of it's ass and BEG Google to teach them how to make a decent login system.

Static HTML pages are better than "web apps".

Static HTML pages are more lightweight and destroy "web apps" in performance, and also have superior compatibility. I see pretty much no benefit in a "web app" over a static HTML page. "Web apps" appear like an overhyped trend that is empty inside.

During my web browsing experience, static HTML pages have consistently loaded faster and more reliably, since the browser is immediately served with content useful for consumption, whereas on JavaScript-based web "apps", the useful content comes in **last**, after the browser has worked its way through a pile of script.

For example, an average-sized Wikipedia article (30 KB wikitext) appears on screen in roughly two seconds, since MediaWiki uses static HTML. Everipedia, in comparison, is a ReactJS app. Guess how long that one needs. Upwards of three times as long!

Making a page JavaScript-based also makes it fragile. If an exception occurs in the JavaScript, the user might end up with a blank page or an endless splash screen, whereas static HTML-based pages still show useful content.

The legacy (2014-2020) HTML-based Twitter.com loaded a user profile in under four seconds. The new react-based web app not only takes twice as long, but sometimes fails to load at all, showing the error "Oops something went wrong! But don't fret – it's not your fault." to be displayed. This could not happen on a static HTML page.

The new JavaScript-based "polymer" YouTube front end that is default since August 2017 also loads slower. While the earlier HTML-based one was already playing the video, the new one has just reached its oh-so-fancy skeleton screen.

It would once have been unthinkable to have a website that does not work at all without JavaScript, but now, pretty much all popular social media sites are JavaScript-dependent. The last time one could view Twitter without JavaScript and tweet from devices with non-sophisticated browsers like Nintendo 3DS was December 2020, when they got rid of the lightweight "M2" mobile website.

Sometimes, web developers break a site in older browser versions by using a JavaScript feature that they do not support, or using a dependency (like Plyr.js) that breaks the site. Static HTML is immune against this failure.

Static HTML pages also let users maximize speed and battery life by deactivating JavaScript. This obviously will disable more sophisticated site features, but the core part, the text, is ready for consumption.

Not to mention, single-page sites and fancy animations can be implemented with JavaScript on top of static HTML, as GitHub.com and the 2018 Reddit redesign do, and Twitter's 2014-2020 desktop front end did.

From the beginning, JavaScript was intended as a tool to complement, not to replace HTML and CSS. It appears to me that the sole "benefit" of having a "web app" is that it appears slightly more "modern" and distinguished from classic web sites due to use of splash screens and lack of the browser's loading animation when navigating, while having oh-so-fancy loading animations and skeleton screens inside the website. Sorry, I prefer seeing content quickly over the app-like appearance of fancy loading screens.

Arguably, another supposed benefit of "web apps" is that there is no blank page when navigating between pages, but in pretty much all major browsers of the last five years, the last page observably remains on screen until the next navigated page is rendered sufficiently for viewing. This is also known as "paint holding".

On any site, whenever I am greeted with content, I feel pleased. Whenever I am greeted with a loading animation, splash screen, or skeleton screen, be it ever so fancy (e.g. fading in an out, moving gradient waves), I think "do they really believe they make me like their site more due to their fancy loading screens?! I am not here for the loading screens!".

To make a page dependent on JavaScript and sacrifice lots of performance for a slight visual benefit does not seem worthed it.

Quote:

> "Yeah, but I'm building a webapp, not a website" - I hear this a lot and it isn't an excuse. I challenge you to define the difference between a webapp and a website that isn't just a vague list of best practices that "apps" are for some reason allowed to disregard. Jeremy Keith makes this point brilliantly.
>
> For example, is Wikipedia an app? What about when I edit an article? What about when I search for an article?
>
> Whether you label your web page as a "site", "app", "microsite", whatever, it doesn't make it exempt from accessibility, performance, browser support and so on.
>
> If you need to excuse yourself from progressive enhancement, you need a better excuse.

– Jake Archibald, 2013

So here's my problem. I've been employed at my current company for the last 12 months (next week is my 1 year anniversary) and I've never been as miserable in a development job as this.

I feel so upset and depressed about working in this company that getting out of bed and into the car to come here is soul draining. I used to spend hours in the evenings studying ways to improve my code, and was insanely passionate about the product, but all of this has been exterminated due to the following reasons.

Here's my problems with this place:

1 - Come May 2019 I'm relocating to Edinburgh, Scotland and my current workplace would not allow remote working despite working here for the past year in an office on my own with little interaction with anyone else in the company.

2 - There is zero professionalism in terms of work here, with there being no testing, no planning, no market research of ideas for revenue generation – nothing. This makes life incredibly stressful. This has led to countless situations where product A was expected, but product B was delivered (which then failed to generate revenue) as well as a huge amount of development time being wasted.

3 - I can’t work in a business that lives paycheck to paycheck. I’ve never been somewhere where the salary payment had to be delayed due to someone not paying us on time. My last paycheck was 4 days late.

4 - The management style is far too aggressive and emotion driven for me to be able to express my opinions without some sort of backlash.

5 - My opinions are usually completely smashed down and ignored, and no apology is offered when it turns out that they’re 100% correct in the coming months.

6 - I am due a substantial pay rise due to the increase of my skills, increase of experience, and the time of being in the company, and I think if the business cannot afford to pay £8 per month for email signatures, then I know it cannot afford to give me a pay rise.

7 - Despite having continuously delivered successful web development projects/tasks which have increased revenue, I never receive any form of thanks or recognition. It makes me feel like I am not cared about in this business in the slightest.

8 - The business fails to see potential and growth of its employees, and instead criticises based on past behaviour. 'Josh' (fake name) is a fine example of this. He was always slated by 'Tom' and 'Jerry' as being worthless, and lazy. I trained him in 2 weeks to perform some basic web development tasks using HTML, CSS, Git and SCSS, and he immediately saw his value outside of this company and left achieving a 5k pay rise during. He now works in an environment where he is constantly challenged and has reviews with his line manager monthly to praise him on his excellent work and diverse set of skills. This is not rocket science. This is how you keep employees motivated and happy.

9 - People in the business with the least or zero technical understanding or experience seem to be endlessly defining technical deadlines. This will always result in things going wrong. Before our mobile app development agency agreed on the user stories, they spent DAYS going through the specification with their developers to ensure they’re not going to over promise and under deliver.

10 - The fact that the concept of ‘stealing data’ from someone else’s website by scraping it daily for the information is not something this company is afraid to do, only further bolsters the fact that I do not want to work in such an unethical, pathetic organisation.

11 - I've been told that the MD of the company heard me on the phone to an agency (as a developer, I get calls almost every week), and that if I do it again, that the MD apparently said he would dock my pay for the time that I’m on the phone. Are you serious?! In what world is it okay for the MD of a company to threaten to punish their employees for thinking about leaving?! Why not make an attempt at nurturing them and trying to find out why they’re upset, and try to retain the talent.

Now... I REALLY want to leave immediately. Hand my notice in and fly off. I'll have 4 weeks notice to find a new role, and I'll be on garden leave effective immediately, but it's scary knowing that I may not find a role.

My situation is difficult as I can't start a new role unless it's remote or a local short term contract because my moving situation in May, and as a Junior to Mid Level developer, this isn't the easiest thing to do on the planet.

I've got a few interviews lined up (one of which was a final interview which I completed on Friday) but its still scary knowing that I may not find a new role within 4 weeks.

Advice? Thoughts? Criticisms?

Love you DevRant <3

TLDR: There's some days where the Gods of IT are not with you. Just lost a whole day of work.

So this morning, we (me and my team) big performance issues with our web app. Lot's of requests time out, big latency, etc

Try to ssh to VPS, latency of 10 seconds between user input and output.

Usual checks: RAM ok, Proc ok, hard drive ok, reboot server (20 minutes), update/upgrade

We decide to call OVH. After 15 minutes call, we try to reboot in rescue mode. Reboot fails at 60% + everything freezes.

After an hour, OVH opens an incident ticket on +200 vps instances (including mine) everything is down during +1h

Finally everything is okay ! Even had time to migrate my new database schema.

Still, quick heavy on the mind but feels good to go home with everything working out correctly

Work! Terribile doubt about our project 😭i will leave this company if we do not come up with an adult solution 😔

We are working for another Company, they asked to add a web app to their project.

We made frontend and backend, we make user auth to their api, then call their api (place order, get orders etc), passing their auth token to their services.

Which Means that our endpoints are not really protected (i think) and if we add an endpoint that does not use their api, the only way to secure them Is to take the token, validate It by calling for example get /order of the api and if It fails just discard the request....too slow?

my colleagues do not want to put a serious auth they Just want to use the company api and leave the rest open...

And the customer Just asked to use some other api functionality, but that api has another auth... How do we pur them togheter? The last api want the id of the user to do machine ti machine auth

It Is my 6th month here no one thaught me anything, i think i'll Just leave ..or am i Just experiencing the developer Daily work?😔

This is a question and a rant

I have to get temperature readings from an andriod app written in ionic angular to a webpage written apache wicket... No, I don't have any control over either stack.

The kicker is the wicket app isn't even run properly attached to a domain, it's just run from a box at the client and then the client machines connect through <server ip>:8080/appname

Which means I can't solve my problem by simply having the website and app on the same domain and then use local storage...

I have tried

Ionic
window.postMessage({ type: 'temperatureData', data: tempFormatted }, '*');

Test it from this page
<!-- index.html (web page) -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Web Page</title>
</head>
<body>

<h1>Temperature Data</h1>
<p id="temperatureData">Loading...</p>

<script>
// Listen for messages from the Ionic app
window.addEventListener('message', (event) => {
if (event.data.type === 'temperatureData') {
// Update the temperature data on the page
document.getElementById('temperatureData').textContent = event.data.data;
}
});
</script>

</body>
</html>

Which does not work, the page fails to pick the data.

So my rant is the situation. M question is does anyone have any ideas?

Following some new nextjs tutorial to learn how to efficiently build a web chat app, the guy built it very solid, but is it efficient?

Im having mixed feelings about this approach. The way he did it is, for example when you click on a user (imagine it as a list of users from your contacts), it actually calls a route, which stores that in database, and once its done Then the route triggers lets say socket.io event to notify the frontend to update the UI.

Not only that but each new message that gets sent it actually calls a route which stores that message in database and once that's successful Then it emits a socket.io event to the frontend to fetch that message.

As you can imagine constantly calling routes like this Does induce small delays. Creating conversations, navigating, opening someones profile and especially sending messages, is NOT instantaneous. When you do it theres a small delay, giving the impression as if the app is SO large that it lags

But it doesnt lag, it just needs a few ms to store that in db so it can return the socket.io bidirectional message event. Which does make sense because what if the internet broke and the user immediately gets sent a message, but the message fails to get stored in database? Or db storage gets fucked or something else fails but socket.io works while db doesnt? The data then may be inconsistent. This approach fulfulls the single source of truth principle

So thats why im having mixed feelings about this approach particularly because of small delays. It is not instantaneous like whatsapp discord telegram signal viber etc the input UI freezes until the message is successfully sent

---

Of course this can be a UI/UX decision and can be handled differently even if the backend works like that.

My concern is is this approach valid?

My question is... I had an idea what if i emit socket.io event to send the message while in the background also call the route to store that message in db? This way not only would it work asynchronously but the message gets sent instantaneously, and if the backend fucks up to store it in db then the UI gets updated with message failed to get delivered, switching the socket.io into polling state. Is this a good (proper, efficient, better) way to do it or not?

Can your web app do this? create read update delete search sort filter copy paste.

Similar to that, here is a quick acceptance test which every business system I can think of fails- Find Records Created By Me. Maybe in JIRA it works but none of my work’s 3 or 4 systems that come to mind can do it. To be clear, even my product I code at work cannot do these things in a practical sense.