51–60 of 69 posts
Whatever happened to the interest in static site generators a few years back? It seemed like we were finally going to move away from heavy javascript just to show some text and images, and yet the javascript seems to be getting ever heavier.
The stack is not te problem, the problem is people using the incorrect tools and doing over-engineering. React and others are simply a tool to pass the logic to the client. Useful in situations like apps that can run almost completely without the server or it can manage the offline situations. All the related tools are only optional things to improve something: • transpilation for older browsers • talwindcss to manag…
This is text-book idealism.
What I did, is I removed all linters, like eslint, prettier etc, because they did disagree about syntax. Point is to make to code minimal change, that fixes something, or adds some feature. Not that most commits would be about fixing syntax.
I also merged all branches to one main branch, because merging between branches did take a lot of time.
What if there would be no build step? DHH has some nice ideas about that:
https://world.hey.com/dhh/you-can-t-get-faster-than-no-build...
Let's make progress towards less complicated stacks.
I don't understand why so much of the static web is a mess of javascript anyway. So many pages can be served as static content that I don't understand why they need javascript at all Whatever happened to the interest in static site generators a few years back? It seemed like we were finally going to move away from heavy javascript just to show some text and images, and yet the javascript seems to be getting ever heav…
1. Encapsulated GUI components are a non-negotiable requirement for most projects, even apparently "static" stuff like technical manuals (e.g. search widgets), but there is/was no widely accepted standard for server side UI components. The closest was things like JSP taglets, but that is now considered legacy technology, gone in favor of React SSR. Why? Well, because components are most useful when you can instantiate and mutate them, which means they're most useful on the client, but server side tag libraries lost all the componentization when crossing the wire leaving you with a "tag soup".
2. HTML and CSS, being as they are committee driven and implemented multiple times in security sensitive C++, evolve very slowly. In practice people's ideas about how to present content, even so-called "static" content, change faster than the standards can keep up, so people fall back to JS to cross the gap. But then you get the impedance mismatch that comes from mixing several different programming technologies together (HTML, JS/TS, CSS, C++), and the DX goes to hell.
3. Why is it a "mess", well that's mostly an unarticulated social preference. Developers seem to prefer open source bazaars on the frontend, even if it means a horrific DX in which solutions have to be stitched together out of lots of tiny half-abandoned libraries. This is probably a legacy of the churn of the 2000-2010 era in which many large, well thought out proprietary frontend app frameworks ended up being abandoned by their owners or experiencing severe strategic product management errors. Delphi, VB6, Flash, Silverlight, .NET WinForms, .NET WPF, Java Swing, JavaFX, GTK, (to some extent) Cocoa and Qt and so on ... these all provided much more seamless and coherent platforms for writing apps but ended up leaving stranded user bases behind after the backing companies didn't execute properly on sandboxing/security/deployment/cross platform support.
Or to put it crudely, a part of the reason people target the web is the lack of product managers involved in defining the platform. Chrome has them in theory but in practice a lot of stuff they add to the platform is deliberately unambitious incrementalism, and the web's enormous base of valuable but unmaintained content means they aren't able to break backwards compatibility on the core tech despite having huge budgets. The downside is that anything not provided by the base platform experiences the opposite effect where the gaps get filled by enthusiastic volunteers who don't plan together or even stick around very long.
There's nothing fundamental about this choice, as the wholesale adoption of iOS and cloud tech shows. Devs will buy into fully proprietary platforms in a heartbeat if it's convenient to do so, but this is partly because those vendors have proven to be quite good about backwards compatibility and incremental development: there has never been an "AWS 2" effort and Cocoa's evolution has been quite smooth from the NeXTStep days.
One way to escape the complexity of front-end development is to write for non-HTML platforms instead. Historically this was quite painful because most work gets done on desktops, but whilst desktop development could be quite pleasant desktop distribution was extremely painful. I've spent a couple of years working on that problem and it's now way easier than it once was (check out [2]) so deployment complexity for devs is increasingly no longer a concern. If you want to write in Jetpack Compose or JavaFX or Flutter, or indeed Electron, then you can do that and the whole deploy/update story has got nice and easy. The big gap that remains is certificate cost, but we're looking at fixing that by signing for you if your app fits inside a sandbox. We're scouting around to understand demand at the moment.
[1] https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI...
Earlier quoted context omitted.
As an interesting contrast, I work on a WPF app professionally that has been around for sure since .NET 3.5 (with references to .NET 2.0 DLL's at times) - at least 12 years - and as much as we give MS crap for abandoning WPF, I can still crank the project open in the latest Visual Studio, probably transparently upgrade to .NET 6 - and everything just works. There are a lot of advantages to web-based frontends but som…
Windows native desktop apps are OK in some controlled (or mandated) environments. For example, 20 years ago I was working for a large company that handed only Windows XP laptops to every single employee. But what if the customer has a mix of Macs, Windows, Linux laptops? Or if before even getting there, they think that they want a web app so they engage only companies that build web apps? A native desktop app will ne…
One of the popular features of the desktop deployment tool I like to shill here sometimes is web-style "aggressive updates", which basically means synchronous update checks on every launch. If the user starts the app and there's an update available a delta is downloaded, applied and the app then launches all without any prompts or user interactions required. As long as users restart the app from time to time it means they stay fully up to date and so bugfixes can be deployed very quickly. This isn't quite as fast a deployment cycle as a multi-page web app, but is comparable to a SPA as users can leave tabs open for quite long periods.
Weirdly, AFAIK no other deployment tool has a feature like that. It's unique to Conveyor. Desktop update tech is pretty stagnant and is optimized for a world where updates are assumed to be rare and optional, so support for fast delta updates or synchronous updates are often rough/missing. When your frontend has a complex relationship with a rapidly changing backend / protocol though, that isn't good enough.
Also we made it from the start be able to build packages for every OS from your dev laptop whatever you choose to run, no native tooling required. So you've got a deployment process very similar to an HTML static site generator. Hopefully this closes the gap between web and desktop deployment enough for more people to explore non-web dev.
I don't understand why so much of the static web is a mess of javascript anyway. So many pages can be served as static content that I don't understand why they need javascript at all Whatever happened to the interest in static site generators a few years back? It seemed like we were finally going to move away from heavy javascript just to show some text and images, and yet the javascript seems to be getting ever heav…
I'm still interested... I forked the pug templating language in order to write my own tools since the existing ones didn't do what I want. Have been working on it on my free time.
"No universal import system" - Rust has it's own module system and Cargo is used for managing dependencies, no need to worry about different module systems.
"Layers of minification, uglification, and transpilation." Just compile Rust to WASM file for the browser, same as using any other compile target.
"Wildly different environments." Something that you'll still need to deal with. Some runtime dependencies are system-specific (code running on the browser usually needs access to Web APIs, and JavaScript, code running on the server can't access WebAPIs but can access the system clock and filesystem. Sometimes separate libraries or separate runtime configs are needed (e.g. configurable time source)
"Overemphasis on file structure." Not a problem for imports, but you may still have file structure dependencies things like CSS, image resources etc.
"Configuration hell." Pretty much non-existent once you have your Rust compiler setup locally.
"Development parity." Just use trunk: https://trunkrs.dev/, to watch, build and serve, config is minimal.
It is rather simple why: Frontend is not linear programming, most backend actions are single-flow (on A do B), in frontend at any point the user can interrupt things, which calls for state management. Most backend applications are stateless and state management is outsourced to a database which does the heavy lifting. So the complexities are in scaling. Maintaining a complex frontend application is akin to maintainin…
There is nothing you can do in the front end that a .NET Forms application from a few years ago could not also easily handle. And the .Net forms application would be immeasurably simpler in terms of complexity and as a bonus, would have the backend thrown in almost for free as well. I deliberately picked .Net forms because despite being much simpler than today’s front end stacks, it was still, much like any MS produc…
many applications are much more complex than some simple forms.
It is rather simple why: Frontend is not linear programming, most backend actions are single-flow (on A do B), in frontend at any point the user can interrupt things, which calls for state management. Most backend applications are stateless and state management is outsourced to a database which does the heavy lifting. So the complexities are in scaling. Maintaining a complex frontend application is akin to maintainin…
Earlier quoted context omitted.
It's still ridiculously complicated in so many other ways, ignoring backwards compat completely. I wish I could describe my most recent attempt at migrating our app to the new Next 13 app router for an audience, on camera, on stage. The levels of confusion and dead ends, and configuration, and error screens, and the need for truly expert-level knowledge just to get things working as one would expect made me realize t…
The app router is definitely not a valid alternative for my current projects on page router. I'm glad I'm old enough not to jump on shiny new things and burn myself in the process. I would actually like to take a step back from Next.js and move to something more simple. Ideally still server side rendered .TSX but with some jQuery like interactivity sprinkled on top on the client.