171–180 of 192 posts
old man alert Back in my day, we wrote ASP.NET that was all server-side-rendered HTML. Once in a while we got REAL FANCY and used JQuery to make PARTIAL HTML requests and update only FRAGMENTS of the page. Hooboy I knew that fashion was cyclical but not tech!
That’s exactly what we are still doing in our bootstrapped SaaS tool! Using asp.net mvc though, not web forms.
> Even if you use React in small areas where it pulls its weight but generally try and stick to simplicity of sending plain ol' HTML The reason why so many apps use React/Vue/whatever for everything is because this hybrid setup is far from simple. It leaves you with two different ways of rendering views, which creates unnecessary context switching for developers, and the interface between the two is often ugly and co…
Earlier quoted context omitted.
We do browser based end-to-end testing which tests the frontend and backend at the same time using a single tool (Capybara in our case). We take snapshots at various points during the test runs which are then compared to previous runs for visual regression testing. Nothing is isolated so it's probably slower. The tradeoff is that the tests are really simple for how much they cover, and they're entirely separate from…
How do you test cases like, "the app should show an error screen when an error occurs in the database or server-side application layer"? In the SPA approach, I find these things quite easy to model with a service worker; just mock JSON API with the non-200 response code with body. I do see the merits of end-to-end testing but I've found it quite simple to mock the interface rather than ensure the database is primed w…
You're right we have to know something about the system to know where to inject the stub, and in fact it makes the test brittle in case that implementation detail changes (which has actually happened and failed these tests before), but it doesn't really matter where we inject the stub to cause the error response, so it's not as bad as it sounds. I think it might be pretty analogous to knowing where to mock the JSON API w/ a non-200 response code.
We very rarely stub anything and consider it a code smell, this is one case where we made an exception though because there is otherwise no way to generate an error message via the user interface.
https://www.otto.de/ I used them this week for the first time and was impressed by the responsiveness on my phone. I looked into the network tab and what I saw was an over-the-wire solution. However, I'm sure that you can also achieve responsiveness this without HTML over the wire. I scimmed a few blog posts, and it seemed to me like they use Java EE, although I'm not entirely sure.
https://builtwith.com/?https%3a%2f%2fwww.otto.de%2f Ablecommerce (asp.net) What led you to think it was Java EE ?
[1] https://www.xing.com/profile/Guido_Steinacker
[2] https://www.otto.de/jobs/de/jobsuche/-java/index.php
[3] https://github.com/orgs/otto-de/repositories
[4] https://www.stepstone.de/cmp/de/Otto-GmbH-Co-KG-28607/jobs.h...
Earlier quoted context omitted.
I wonder how much visitors you have, i.e. how much popular is it? If its not a secret of course. I couldn't imagine any web developer need such kind of tool [knowing curl by heart], but obviously I'm in my own bubble and I'm wrong on my assumptions.
70,000-90,000 unique monthly visitors, according to client-side analytics. Someone wanted to buy the site so we added client-side analytics in August to December 2022 https://plausible.io/curlconverter.com?period=custom&from=20... We also moved the site from GitHub Pages to Cloudflare Pages just for August 2022, to run server-side analytics to count the people that block ads and that said 116k "visits", compared to 6…
That's my understanding what is meant to be web developer.
I'm correcting my understanding of reality with comments like yours, thanks!
I'm building a webapp[0] for turning Clickup docs into static sites, using CF Workers. There isn't a framework for Workers that has the flexibility I need, so I home-rolled one that only sends rendered HTML over the wire. Async components are supported too, so if I have a particularly data-intensive component the renderer just inlines a tiny JS script that sends a request to the worker again, which then returns just…
I'd be happy to learn of other Go tools using this.
It depends... are you delivering mostly static content or creating and interactive application front-end? Most sites are somewhere in the middle and so should the responses. For me, if it's an application ui/ux, then the rendering should be almost exclusively on the front-end. It's just delivered via a web server instead of installed. Yeah, it's larger than server-sent. It's also emphatically not tying up server reso…
I wouldn't assume building the html on the server uses any more server resources than building JSON. Either way you are just building a giant blob of text. With html fragment caching the server could easily be doing less work this way.
It's not a crazy amount of overhead... and even then, it's a matter of how interactive the site/application is or needs to be. You can have a horrible or great UX in either direction in different use cases.
When I use apps like this - GitLab - I am struck by how much wasted user time such an approach leads to. Everything is a page refresh Send me some counter examples? Im a big SPA fan and there’s lots of good examples
Everything in a page refresh typically only happens with these solutions as a fallback when Javascript is disabled. And if Javascript is disabled, what do you really expect to happen other than everything is a hyperlink?