That is a really intriguing way to flip it do the opposite!,
True, sometimes creativity kicks in hardest when you challenge the status quo or deliberately break the pattern. That reverse thinking exercise can definitely stir up some unexpected brilliance.
Maybe adaptability and creativity are not as far apart as we tend to think? Like, if forcing creativity through constraints works, could creating intentional discomfort or new challenges be a way to nurture adaptability too?
…more of “breaking pattern of thoughts” by thinking “what happens if?”. Doing the opposite without thinking can be harmful. Look at the world right now. Creativity may be harmful without any thought about the consequences. Just thinking the opposite may be enough to start a creative process IMO. Thinking is healthy, but doing may be harmful.
It is like a creative web site that may be stunning, but unreadable for many disabled. And hide the message behind too much creativity can be bad for business.
Yes, thinking outside the box is creating discomfort. Not thinking the “normal” way. And necessity or poverty is the mother of creativity and invention, As laziness is its father.
Such an important point,
Creativity without awareness can lead to real-world harm. & appreciate that adding here => it’s not just about flipping the script for the sake of it, but doing so with intention. Doing the opposite might be a good starting point, but what really matters is what we do next with that spark of thought. That moment of discomfort can either ignite thoughtful innovation or reckless disruption, depending on how it is handled.
The example about web design is perfect. Creativity should enhance access not obscure it. & that ties beautifully to your point about necessity and even laziness being drivers of invention, sometimes the smartest creativity is the most invisible kind.
Could the key to future-ready creativity be balancing disruption with empathy?
& when it comes to teams, how do you personally encourage this kind of thoughtful creativity without stifling risk-taking?
Creativity is just a process to find other angles of the problem. It is about implementing new ideas or framework that must be carefully considered.
It is like framework (original question). How will a framework affect the maintainability when the foundation of the framework version may change maybe once a year? Thinking about using framework is healthy, but implementing may add extra work to keep your code following the changes of the framework.
A lesson I have learned the hard way. The magic that framework creates has a price tag where the bills comes several years later. Big bills.
So creativity (or framework) may create revenues in short term, but what happens in long term? Can you find any historical evidence that any framework is truly “Future-Proof”?
Thank you for sharing your experience so candidly,
You have hit on something that many developers only realize after the fact about frameworks, while magical at first, can become maintenance traps if not chosen carefully.
& you are absolutely right about creativity & frameworks both need to be paired with foresight, not just excitement. The short-term wins are tempting, but sustainability is where the real payoff lies. that makes sense.
Do you think we are too quick to adopt new frameworks because of developer FOMO? & if so, how do you personally evaluate whether a framework is worth investing in beyond just the buzz?
I cannot speak for others, but I think there are more talk more about frameworks than about the first layer - languages.
But for me personally, once trapped into a framework. I will never look at any frameworks at all. I have spent months to figure out how to find workarounds for all magic bugs that appears after a year or two in a new version of the framework…
On the other hand, I might try some libraries for solving specific problem. Sometimes you can switch to an equivalent library if the first library turns out to be hard to maintain.
Getting trapped in a framework feels like trying to redecorate a house where the walls move every year! I have also been burned by updates breaking things I spent ages patching up. The temptation of magic is real but the long-term maintenance debt can sneak up fast.
Also, picking tools for specific problems instead of locking into an all-encompassing framework. That feels like a more modular.
do you think the same risk applies to language-level trends too? Like, could chasing newer languages (instead of frameworks) come with similar long-term trade-offs in team knowledge, community support or tool?
Yes, I once were investigating Python, but I realized that the difference between version 3 and 4 was significant and most of the “libraries” was at the moment still in version 3. And reading about all PHP versions in forums may also create headaches for PHP developer (I suppose).
So one big advantage of Python (a rich standard library and many third-party libraries) can overnight become a bottleneck. Or at least cause a delay when trying to adopt new features.
Hence I choose Go as my primary tool. As they have a commitment (close to promise) to never break any old code. Still after almost 10 years I have not experienced any big changes in the code that “breaks” my code.
Ohh great Choice of Go Shows,
Solid perspective, it’s real discipline in resisting the shiny new thing trap & instead prioritizing stability. I think a lot of developers underestimate just how exhausting it can be to maintain codebases that are constantly breaking from upstream changes. Go’s backward compatibility ethos definitely gives it a kind of quiet strength that feels increasingly rare.
In a world that is obsessed with developer speed and AI-assisted code generation, could a slow-moving language like Go actually become more attractive not less? Like, instead of riding every wave, it lets you build solid foundations while automation handles the rest.
Do you see Go’s philosophy influencing how you evaluate front-end frameworks too? favor something like Svelte or Solid.js (minimalist & predictable) over Angular or Next.js?
My decision to avoid frameworks has nothing to do with Go. Living in a “magic” world for a couple of decades, this “maintenance hell” was the cause of my framework aversion. The fact that Go could be used without any framework was to me as a “fly towards the light”.
I started to evaluate Angular 6, but found that I again was trapped into a framework. I was forced to think in a certain rigid way.
Svelte, Solid and Next I have no clue what they are, but I assume they are based on Javascript. As Javascript is almost mandatory in web development, I can cope with it. But if it is possible, I move the code to Go web server instead, to make the client even more lightweight.
Absolutely, Avoiding frameworks due to past experiences with maintenance hell is entirely valid. Go’s philosophy of simplicity & minimalism indeed offers a refreshing alternative that allowing developers to build applications without the overhead of complex frameworks.
This minimalist approach in the realm of front-end development is echoed by frameworks like Svelte. unlike traditional frameworks, Svelte compiles components into highly optimized JavaScript at build time also eliminating the need for a virtual DOM & reducing runtime overhead. This design aligns with Go’s principles that providing a lightweight & efficient solution for building user interfaces.
Tools like htmx offer a way to enhance HTML with dynamic capabilities without relying heavily on JavaScript frameworks also enabling server-driven UI updates through HTML attributes & htmx allows for interactive applications while maintaining simplicity.
Have you explored integrating tools like htmx or Svelte into your projects? They might offer the balance between functionality & simplicity that complements your Go-based backend.
I do not consider either React, Svelte or htmx as “frameworks” that force you to think in a certain way. Rather a collection of “components” that can be reused (like Web Components). But my goals is both to understand and get things done. These two goals contradicts each other, but gives a better understanding how to maintain in the long run. Correct me if am wrong…
An alternative question is, what will increase in popularity in the future? Instead of asking what is currently popular that will remain popular, if it is possible to choose something that will increase in popularity then that could be more useful.
WebAssembly is likely to increase in popularity.
Originally HTML had no scripting. It was initially designed basically for just documents. In my opinion at least, use of HTML as an application front end is cumbersome. The bleading edge or unknown edge is a front end that might not yet exist but will inevitably, that will be more like desktop front ends. If someone with creative, logical and technical skills can imagine the future then they can be the most future proof.
It is possible for someone with relatively no technical skills to design something that increases drastically in popularity. PHP is an example of that.
Right now I am testing a “safeboxed API” solution. Which means that the API is not reachable through external internet. Only by internal network. It is harder to attack the internal IP than an external IP.
Hence I have an open “bridge” to reach the API. In my case all traffic pass a traditional SPA web app that calls the API via internal IP. Safer IMO.
So a potential drawback with WASM may be “back to old client-server” technology as you do not use a web server. Which means that you must send the url request directly to the API or database over internet (possible vulnerability). When the browser (client) directly contacts backend services (API) is like in the old days.
WASM out of the box seems to me a step backward. In order to make the API more safe you must add several security levels, a bridge or create a hybrid solution WASM + Web app IMO.
Please, correct me if I am wrong!
https://orca.security/resources/blog/10-ways-to-manage-api-security-risks/
I guess 99% of Business Web applications are running in the companies intranet. Which means you have server, but you are not connected to the internet. So there is not the one or the other like you explain.
So you mean that Salesforce, Jira, Microsoft 365, Google Workspace, Zoom and countless industry-specific tools are running on the company’s intranet?
IMO a vast number of business web applications are now delivered as SaaS. These applications are hosted in the cloud and accessed by employees over the public internet. WASM or not.