This article definitely captures the general joy I get being able to work with the web. I understand it has its warts, but there's something really magical about having one ecosystem where you can so seamlessly play with user input, network requests, audio, graphics, and it can be shared or deployed on basically any consumer hardware.
I recently have undertaken a little side project that at first I assumed I was going to need to pick up an Arduino and hack together some physical inputs, LEDs for an interface, and a speaker. It wasn't until I started shopping around for pieces and learning about the tech stack that I realized I could just take my old phone, pop open a browser, and prototype it that way.
There's a lot of complaints that not everything should be in the browser, and that's very true for a lot of cases, but it's extremely empowering that anything _could_ be in the browser, at least for your MVP.
> there's something really magical about having one ecosystem where you can so seamlessly play with user input, network requests, audio, graphics,
It seems that that was the experience Smalltalk was aiming for back in the 1980's with it's totally integrated development environments (integrated to the point that it was basically its own operating system).
One could argue that the modern web browser with its integrated tooling for javascript is a reasonable modern interpretation for this. Note the similarities that the web-browser is almost its own operating system in this scenario as well
> We could view my investigations of Cookie Clicker’s mechanisms as ‘basic research’, i.e., research without an immediate application in mind.
> But perhaps the simplest way to view this episode was as a playful, recreational activity which through sheer dumb luck gave me the skills needed to solve an important problem in my work life.
I see it capturing my joy of using GPT-4 on ChatGPT, with its cap of 25 messages every 3 hours. There's a joy in exhausting the limit for each session (may be that's what gamification is). Not able to do for full day, as got to sleep for >3 continuous hours, but exploring topics besides day to day work as a result :)
Learning I am doing, how much useful - not sure.
It really doesn't. It's much harder in every ecosystem except the web. Just shipping software to people at all is harder on every other platform, before even discussing how it's built.
Some platforms seem to require a large amount of effort to ship on by design (iOS being an obvious example), but if by the "web" you mean client side (server-side I agree is easier, but at some level any system where most of the work is done remotely/outside user control is easier to work with than one where users have control), then the web has its own issues with shipping software (e.g. bundlers, API support), and lacks support for really digging into the device/platform (for good reasons).
Depending on who you're targeting (in terms of both users and developers), the web may or may not be easier than "native" (e.g. R solves problems for users that the JS ecosystem can't solve).
Well, fine, but from the developer's point of view dealing with obsolete versions is a nightmare. It's bearable if the software is offline only, but most isn't.
For businesses the two are rarely mutually exclusive depending. It’s obviously a little different for your personal life, because you’re going to have to spend resources to “self-host” but for a business those resources aren’t going to be too different from buying “classic” software.
What we often do is to buy development, rather than buying a SaaS product. With the right setup, and this is easy to do with OSS as well, you can buy the development as needed from any of the software houses which specialise in this. You can then run things yourself, or buy the maintenance as well. This lets you control what happens with the software on the server and the server itself, and it’s frankly often a cheaper option than buying a SaaS solution for things that are vital to your business. At least in the long run. That being said, even with SaaS solutions you’re rarely at the “whims” or somebody and their server in enterprise SaaS solutions. I think Figma might be the only service we use where we’re at the “whims” of change that we aren’t able to control, and we do use quite a lot of SaaS software for things that are “less” important to us.
As a private user you’re right though. You won’t be able to do those things. But the flip side is that you’re probably not going to find a lot of non web-solutions that don’t sort of work similar. Even with something like an e-mail client, you’re going to see updates, and you’re not going to be able to influence them anymore with a local program than you are with a web-based program. I guess you can continue to use an old version of something, but what then you’re using unsupported software, and eventually, you risk that it might not even run on your Operating System without massive amounts of efforts. Like, I have X-Com: Enemy Unknown on 3 floppy disks, even if I had something that could read floppy disks, I’m not sure how I’d even install it on windows 11 or my Mac.
That has as a prerequisite that the software is available as OSS. Compare Figma with OSS. Why would anyone in their right mind not go the Figma way, if they actually have to offer something valuable?
I agree with what you're saying, but I meant more if the developers opened up an API a bit too much. They can close that up and make their client software more stable.
You can easily package your webapp with an integrated server or electron, if you don't want to provide a server. Or simply put it on the source code platform of your choice and let users figure out hosting on their own.
Plus, you get all of that for (basically) free, at the same time with hardly any extra effort! The web really is the most versatile of platforms.
Back in 1990 I was several years into a PhD in neural networks, having
fun, but not really making especially useful progress. I spent a lot
of time trying to get some simulated bugs to learn to move around,
find food, and generally learn how to be better bugs. To help me
understand why my learning algorithms didn't work, I'd written a nice
graphical user interface, and generally camped out on a lovely Sun
workstation belonging to some defunct research project, at least whenever I got
to it first.
About that time, the Bank of England issued a new five pound note and
made huge claims that it could not be scanned. Supposedly they had
designed in loads of high detail textures that would show weird
aliasing artifacts on the 300 dpi colour scanners that were state of
the art at the time. Challenge accepted! The Sun workstation I camped out on just happened to be connected to a nice 1200 dpi monochrome scanner. I
went to my friends at the university theatre and returned with a whole
stack of different coloured gels from the theatre lights. Then I took
a whole series of scans of a £5 note through the various coloured
gels, and wrote software to combine multiple monochrome scans into a
colour image and re-align all the layers properly. As a result, my
screen background was a perfect image on a supposedly unscannable £5
note.
Six months later, I ran out of funding for my PhD without very much to
show for it, but didn't fancy joining the real world. There were two
research projects needing people, and I very much liked the idea of
one on surgical robotics for neurosurgery, but I guess that was too
ambitious and didn't get funded in the end. The one remaining project
was on multimedia conferencing. Now, as an undergrad I had avoided
all the classes on networking as I thought they would be boring, so I
was spectacularly unqualified to do research on networked multimedia,
but I applied anyway as I didn't really have any alternatives left.
Of course the first question at interview was ``So, what do you know about
multimedia?''. The honest answer would have been that I didn't know
much at all, but that didn't seem to be what the Professor was hoping to hear. I
couldn't think of anything else to talk about, so I told him all about
faking £5 notes.
A couple of days later I was really surprised to get offered the job,
and a decade or so later, it was me that became Professor of Networked Systems.
All because I couldn't resist the challenge to copy a £5 note.
Did you ever do anything with the £5 story at the time? I can imagine just that project would be enough material for a paper that you could at the very least send to the Bank of England to show their premise was false.
Good question - I guess at least I showed I could figure about for myself how GIF images work, and showed some initiative. I never asked the Professor if he actually had any other qualified applicants for the job - maybe I was the only one - but if so I'd rather not know.
If someone is vaguely smart and has the right morals and virtues you will likely be better off with them than someone who doesn't but is otherwise more skilled at the moment.
I've never played cookie clicker, but I have a hard time imagining that it can hold a candle to universal paperclips. Never has such a pointless game made its point so well.
Universal Paperclips has the best story out of all the idle games I know, but it's not the best game. For one thing, it has very limited reset/prestige mechanisms, and the expansion mechanism in the final phase is very opaque and can mislead players into frustrating dead ends.
> For one thing, it has very limited reset/prestige mechanisms
Are those considered good things now? In all the games where I’ve seen them implemented, they haven’t increased fun at all, just prolonged the grind. I actually like universal paperclips more for being relatively grind-free — there is just enough boring time-consuming manual-labour to get its point across, and then it moves on
They can be good if they unlock significant new game mechanics.
The most extreme example (I know of) in that regard is https://pmotschmann.github.io/Evolve/ which has, at last counting, 12 different ways to reset, many of which are not accessible until you have done dozens if not hundreds of others. Exploring the entire game takes years of play.
Obviously, there's still lots of grindey repetition, and it's only something for people who find slow progress towards optimizing grind rewarding.
Yeah I got past it pretty much as soon as I posted, which is kind of a pity. I like the idea of playing as a plant buying amino acids from the mycorhizae with hexose. The whole coal mining fungus with banking problems thing feels a bit too rooted in the human world.
Poking through the code though, I can see that that's probably not a problem that I'll have for long.
I was never able to go past the universe exploration step, nothing I did made significant progress past that and I couldn't find a way to speed things up. Is there a way to win or reach an end? (Which I assumed was consuming all of the universe?)
There is an end, yes, and it happens a little bit after consuming all of the universe. You'll know that you've reached it when you are offered the option to delete all of your progress and restart.
As with many of the better-designed incremental games, there are moments in UP where you might get the impression that the way to continue is to just do more of what you've been doing, but actually the way to continue is to do something slightly different. I think you're referring to the starkest of those.
The trick is to get the right balance for your von Neumann probes such that they survive long enough to propagate (hazard remediation mostly) while also not bottlenecking on a resource. Iirc you can harvest so much so fast that it's easy to be set for the foreseeable future. I would occasionally just stop mass/wire production to get my fleet going strong and it would take a long time before I needed to restart it. Meanwhile trust stacks up and probes get better.
It's been a while since I played it, but the key is to allocate as many of your resources as possible to reproduction rather than exploration, because that leads to exponential growth.
It's possible to complete the game in around 2 hours of active play, IIRC.
Ah Cookie Clicker's got fancier graphics (although they're kinda heavy, I'd turn them off) and it goes... eldritch at some point. It's definitely the longer of the two to play, I recall finishing Paperclips in about three slow workdays.
There's one, I don't think Cookie Clicker has an ending. It's got countless multipliers, but eventually you're completely out of upgrades and achievements and it just sort of peters out in diminishing returns.
One remark though: if you've been playing for a while, save & back-up your save games. It stores progress in a cookie (I think) and they have a tendency to expire / get lost after a while. I just opened it up (it seems I last played a year ago) and it started a new game, but I had it backed up. Save before you stop playing.
When I first played paperclip I didn't know it was based on that thought experiment. I felt silly a year+ later when someone made the connection for me.
ugh... I can't remember the name someone posted a game here before web-based, you're in a terminal/folders structure, as an AI trying to escape into the net
Huh - as I recall, that was blanked out/unavailable. But it looks like progress isn't saved across page-closes, so it'll be a while before I can test that again. Regardless - thanks!
EDIT: Oooooh - you can (ROT13) punatr gur nepuvgrpgher bs lbhe pberf gb "zngpu" erdhverzragf gb Sbepr Nofbeo.(/ROT13). I'd assumed that (ROT13)n terlrq-bhg bcgvba zrnag vg jnf fvzcyl haninvynoyr(/ROT13). Cool, thank you!
> Previously, this might have taken me weeks. With JavaScript, I built the prototype in hours.
I really like web/html/javascript for building UIs for this reason. It's really fast to prototype and get something decent looking/working, it has a very fast edit-compile-run loop (if you don't use any fancy tooling, as fast as you can press CTRL-S, Alt-Tab, F5), great debugging tools, and in the end, your product immediately works cross platform, both on desktop and mobile!
How is this in any aspect better than Delphi from the ‘90s? And you get about the same performance with JavaScript on a modern CPU as ObjectPascal on an old Pentium.
Instant global distribution, to anyone with a computing device who enters the name of your app in a text box. Developers all over the world are paying billions per year in lost productivity for that killer feature. It's so easily worth it.
I still force XHTML-style markup for HTML5 applications. Maybe it's my experience that is the real problem-solver, but I feel sticking to very strict markup reduces a number of bugs that are extremely hard to solve.
I played Swarm Simulator on iphone for a good while, it's a pretty compelling idle game.
I'd say my main issue with idle games is how much they reward you for active play. In Cookie Clicker's case, at random, golden cookies will appear that when clicked apply a random boost, e.g. a 7x multiplier. Eventually you unlock upgrades so that another one may appear while the boost is active, leading to a double boost. The ultimate combination involves a multiplier, a boost to cookies per click (again active), then selling a lot of buildings for an additional short-lived bonus, then clicking like mad.
You can earn a year's worth of idling / not playing within a minute then. If it's not more.
Semi-related, I was idly wondering the other day why we don't see more "F12 Zines" like the "BASIC Zines" of the 70s and 80s. You could collect all sorts of neat little bits of JS that run easily in the browser's Dev Tools (F12) and introduce simple programming concepts from whatever browser they already have available on their machine. Dev Tools have gotten to be impressive REPLs with surprisingly deep IDEs. There's probably an interesting "punk" experiment in trying to open that to people of all ages interested in exploring it.
Imagine the wonder of introducing the right sorts of curious people to the magical world of "about:blank" and from there hitting F12 to go on a journey of making it not quite so blank anymore.
My guess is the lack of income from providing this information from a browser vendor (who are all mostly Chromium based, so there's no reason to offer anything that makes it easier to use their specific browser), and the number of companies that have popped up offering to sell you tutorials on web development.
I am in my almost mid-40's, so I got to watch the web grow, and have my skills grow with it. Reading uncompressed source code from libraries like PrototypeJS/Scriptaculous, and early jQuery, along with the custom code per website, definitely made me the developer I am today (in regards to web development, although desktop tools have definitely gotten better, as well).
Most of the people writing "BASIC Zines" weren't BASIC vendors. Some were code-inspired journalists doing it for "real" magazines that wanted "hip" computer content. (The brief period where BASIC was hip computing content was brief.) Some were "hackers" of various sorts doing it for fun and maybe a quick dollar, cheaply photocopied, pamphlet style for the cheapest racks in book stores or software stores (remember those?) or viral distribution in schools. I'm sure most of the original Zines didn't make that much income.
It was thought that the latter sorts of "cool hackers" sending photocopied pamphlets to schools or book stores (or software stores) stopped doing it as much when BASIC stopped being the "operating system" of home computers (the Commodore 64 was one of many that booted directly to a BASIC REPL; the early IBM PCs either booted to BASIC or had a BASIC interpreter close to hand) and BASIC interpreters stopped being "everywhere".
Now the web browser is the modern OS and Dev Tools are ubiquitous and a single button press away (almost universally F12). JS REPLs are right there for immediate use and ES2020+ is the friendliest JS has ever been. I think all we're missing are the "hacker teachers" with the right punk attitudes, an access to a Xerox, and the right sort of store willing to sell home made zip lock bags full of photocopies again.
(Or I don't know, a cheap webpage could be cool too. Make it Geocities-esque with lots of classic Under Construction GIFs and encourage people to fork it and construct it themself.)
Well, the problem is rather, that JavaScript is a pretty bad language (nobody claimed otherwise, when it was designed in 10 days), so that using something like TypeScript makes it much better. Unfortunately your browser understands JavaScript, not TypeScript.
That's the immense tragedy of web development: It's a giant pile of excrement, because it's built on several things that were never meant to be what they are used for today.
It's also why I left a long time ago, and never looked back.
This is what I'm saying though. Typescript is just a hack on top of Javascript. The same engine is going to run your code in the browser.
For the record, I think Javascript is fine (with some nasty warts), and Typescript is a great addition. The idea that TS is great but JS sucks is silly.
> The idea that TS is great but JS sucks is silly.
Just to be clear, I absolutely did not say that. Instead, I'd rather agree with your statement that TS only makes things better. But there is only so much it can do in that ecosystem, even if a good type system does notably improve things.
Everything that's below that is still what it was.
There's no accounting for taste, but... aren't we still taking about polished turds on top of a pile of excrement? "Palatable" is not the word I expected to see in this subthread.
> The idea that TS is great but JS sucks is silly.
Actually... typescript's type system could work quite well in other languages and is in fact in some fashion being ported over to multiple, Python's great turnaround on type hints a few years ago was obviously inspired by it.
So, I disagree. The type system makes a wart of a language into something passable, which is a great achievement.
> The idea that TS is great but JS sucks is silly.
Isn't all programming just layers of abstraction that make the layers underneath it more usable?
If you view Typescript as a standalone language that is another abstraction -- just like every other programming language -- that may make it more palatable. Yes, it's technically a superset of JavaScript, but I don't think anyone uses it that way. It would defeat the purpose, like buying a car and then tearing out the seats, air conditioner, and sound system.
Just curious, is there a way to define typed DTOs or things like Pydantic models, and then parse blobs of JSON into said classes, all leveraging the type annotations?
I know it all gets compiled away in JS and all, but Pydantic is surprisingly ergonomic to use and type hints are sort of a suggestion, albeit available at runtime.
Closest I've seen is Zod, but the syntax looks horrendous IMO. Maybe you look past it eventually though.
Assuming I understand you question: you can define an interface to describe what an object parsed from JSON contains, and then cast your raw JSON-parsed object into that type.
The casting doesn't guarantee the JSON from your server fits the interface, but it WILL ensure any downstream use is correct, and also enable auto complete for its fields (assuming your IDE supports it).
I've been using JavaScript on and off for nearly 20 years, and TypeScript is a massive improvement.
I didn’t leave it because of the compile steps, but because the extra layers, despite all their downsides, were far from able to hide the underlying impedance mismatch.
I left over a decade ago and went back to low level kernel programming.
It’s good for everyone that different individuals have different likes and resulting priorities. Good that you found the one that makes you happier. And with any luck your preferred niche isn’t too overcrowded, so you don’t suffer from those negative side effects.
I did not intend to shit on web developers, by the way. It's not their fault, they just have to live with it. I just lament the history that lead to what they ultimately have on their plate. Early "web development" went tremendously wrong, owing partially due to the fact that the "hypertext" markup protocol and markup language were meant to be used in an entirely different way, and partially due to early hacks leading to early results in terms of "web applications". But those hacks came at the cost of making this layer sandwich in any way sane to begin with.
In my opinion, everything else since is an attempt to find a way out of that mess.
I was there when the web happened, though only watching from the side lines. I also remember that there were more fitting approaches early on, but a lot of them suffered under the Internet's explosive growth: Some of the "sane" stuff at least would have needed concerted efforts for plans that have to be executed over time. But the web was already a thing, and people desperately wanted to do certain things with it. The quick hacks for that were available immediately, and they were cool: "Hah, look what I can do. You can now get a travel itinerary through your city's public transport system from the World Wide Web. Isn't that amazing?" (At the time, it was.)
I'm not saying you cannot have joy in web development. As you say, it just wasn't for me. For the reasons above.
Interpreted languages are so improved by lengthy build processes involving compilers, linkers, transpiration, and sixteen different kinds of incompatible package formats, I don’t know why anyone would eschew them.
Node? Who uses Node for anything serious in 2023? Real backend coding today is done using Bun. And yeah, you can write something in JavaScript, but it definitely won't scale and will constantly throw errors. Pretty much all serious frontend code today is written in Typescript across the board. /s
I very often write little scripts that I can just copy and paste into the console in dev tools. Sometimes I even do this in customer demos to show what our product would look like in their web pages. To many people it really seems like magic.
The title is a bit hyperbolic but I enjoyed the sentiments nonetheless.
I definitely remember as a kid learning Lua scripting because of video games. Just going over forum posts trying to make my own games or break other games.
Definitely gave me the basis to rocket ahead when I took a formal CS class.
When I was in college, there were basically two completely separate tiers of people in CS classes: People who knew how to program already, and people who didn't
It was pretty nuts. The class was tuned to make it possible for non-coders to learn coding basics along with basics about data structures, compilers, blah blah blah. So for people who could already implement something like fizzbuzz, the class was a joke. We'd get an assignment to store something in a linked list and print it out, and some of the students made fully 3D animated demoscene demos out of it.
(It just goes to show that treating college degrees like job programs is a terrible idea, if you ask me..)
This is why I like that Northeastern does their intro class in a Racket / Scheme dialect. (plug for https://htdp.org/ as IMO the best way to learn computer science)
The goal is to learn how to think about problem solving and program design, not simply to make the computer do what you want. I found that (myself included) people who came in with experience in imperative languages, etc. had a harder time than people who came in fresh. But the takeaways around functional programming, data structure design, testing, etc are far more important for a career than the ability to make some arbitrary program do some arbitrary thing.
Maybe, but the ability to make some arbitrary program do some arbitrary thing is the exact experience that lead many of us to fall in love with computing.
Oh, my point was that the parent comment was being obnoxious by calling out the hyperbolic title (which is a totally normal place for hyperbole) when they themselves used hyperbole to tell their own anecdote. Like it was just a dumb thing to call out.
I do agree that students who come into college often have an advantage, but they often have less of an advantage than they think, and it costs them because they end up not actually learning some of the less obvious skills that are being taught in a course setting. I found that the _best_ students in my cohort were those who started college with almost no programming experience but put in a lot of work. The next batch were those who came in with significant experience but were willing to reflect on it and adapt to the new information. Then kind of everybody else was mixed in depending on how they had taken things individually with no clear distinction between those with prior experience and those without.
I think for vanilla GUI where you only need readily available vanilla components, Java is fine. But I suppose you would be in for quite an adventure if you intend to do a lot of highly customized user interfaces. The curse of JavaScript is that you can readily devise newfangled componentry so easily that as a user, you end up with all sorts of unpredictable things where straightforward tasks become much harder thanks to endless gadgetification and whizbangery. The idea of "standard" flew out the window long ago.
It would be exaggeration to say QWOP has become the new normal, but only by so much...
Eventually we'll get tired of this and straighten up, I'm sure. Maybe menu mnemonics will make a comeback (they really are a good idea).
I'd love to try to prototype a GUI that harmonizes GUIs with keyboard accessibility; bring back some external component model to script them again, put some sort of effort into making that scriptability discoverable for users and easier to maintain for developers than Applescript was, make it easy to give and surface expert-level shortcuts, make it so keystrokes are buffered across contexts so you can develop expert-level skills in pre-keying what you want the UI to do even before it pops up (one of the reasons why you had to pry the console-based point-of-sale software out of customer's services hands at gunpoint), and just generally make something useful for experts again... but it's years of effort to even prototype such a thing to the point where it's useful for anything. GUIs are stuck in the 20th century because they're just so big.
Maybe JavaScript is actually what saved your PHD, although cookie clicker was what pointed you in that direction.
Certain people love to talk trash on JS for many different reasons, some probably valid ones too, but you can do so much with just a basic understanding.
I've probably never felt as empowered in my entire life as when I learned a bit of HTML CSS and JS; it was like I l suddenly had the tools to make tons of new projects. I didn't feel this way using Python or C (those had felt very command line oriented the way I had learned them), but when I saw how easy it was to use JS and make an interactive web page I felt like I could make full applications, games and toys and whatever else I wanted to. Having the browser to draw images and UIs and access to built in features like the HTML canvas or web audio APIs made dream projects feel much more achievable.
> Maybe JavaScript is actually what saved your PHD, although cookie clicker was what pointed you in that direction.
I think you're basically saying the same thing as the article, except their emphasis is on that they learned the skill they ended up needing while doing silly things for fun rather than trying to be productive:
> But perhaps the simplest way to view this episode was as a playful, recreational activity which through sheer dumb luck gave me the skills needed to solve an important problem in my work life. My colleague Titus Barik analysed how programmers talk about programming as play, involving ‘spontaneous and creative expression’, ‘experimentation’, and ‘purposeless, ludic activity’. He found that many programmers reflect on episodes of playful programming as joyful experiences that catalysed learning.
> I’m extremely grateful to Cookie Clicker for the journey it put me on, but even if I hadn’t ended up learning JavaScript because of it, I still wouldn’t regret, and would cherish, the many many hours I spent tinkering and clicking away in my college dorm bedroom.
I read the article as less about touting the benefit of some specific technical tool but more about the value of time spent purposely _not_ being productive. It's a counterpoint to the "cult of productivity" that espouses the important of maximizing efficiency and "hustling".
Well that is more or less what I meant. The author put most of their emphasis on playful exploration leading to learning an unexpected skill (and the moral of the importance of play in learning). On the other hand, the usefulness or ease of use of the JavaScript ecosystem played a big part and maybe the moral could have been that JS is underappreciated and saved the author regardless of their path to learning it.
I don't mean to devalue play or passion projects, that is how I learn most. But JS itself played a big role and I wanted to share my perspective on it.
Ah, makes sense. JS and its ecosystem do have a bit of a reputation in the tech community, but I suspect that you're right that even the complaints that have merit might not really matter much to someone not as worried about the finer points of professional software architecture. It's easy as a software engineer to get caught up on something like a giant node_modules folder that we forget that someone looking to write a visualization for their PhD research probably doesn't care at all about that (and rightly so!)
A couple months ago I tried to do a quick hack project where I could get the computer to play a sound and render an image when there was a keystroke.
Turns out with python, without additional libraries, you had to read from stdin which requires the user to end the input with newline before python could read the char. (2 keystrokes, not 1)
But I switched to JS where it’s trivial to intercept single key strokes and finished my script in ~30 minutes
I couldn't agree more. The browser has everything you need to make an insanely wide array of rich and dynamic applications with just HTML, CSS, and JS.
Learning that a browser and a notepad are all you need to have a basically zero second feedback loop in an iterative development experience was pretty breathtaking the first time I press reload and some stuff moved around.
> Maybe JavaScript is actually what saved your PHD, although cookie clicker was what pointed you in that direction.
Yes the article strongly implies this with some added nuance:
> I’m extremely grateful to Cookie Clicker for the journey it put me on, but even if I hadn’t ended up learning JavaScript because of it, I still wouldn’t regret, and would cherish, the many many hours I spent tinkering and clicking away in my college dorm bedroom.
Related to this, Eve online opened the door for me to learn a ton about markets and economics I didn't even know I wanted to know, but it fascinated me. Traded my way into free-play before my grades started to slip so I quit.
> One of the peculiar and interesting aspects of this game is that it rewards you for not playing it. Often, the next cookie purchase requires several orders of magnitude more cookies than you are currently producing, so you have no option but to leave the game alone, sometimes for days, before your cookie factories churn out enough cookies for you to unlock the next level of progress.
A mechanic all too often ruined by desperate monetization.
The paragraph you quoted isn't really true for Cookie Clicker nowadays. It's true that the next upgrade may require several orders of magnitude more than you have. But it's never necessary to leave the game alone for days; you can get those orders of magnitude much faster by stacking up buffs and combos with all the minigames (pantheon, garden, magic grimoire) and actively clicking all the golden cookies.
It seems like 1. they did something to prevent abuse 2. it gets more effective to use instruments provided by the game pretty fast (than scripting clicks)
I recently have undertaken a little side project that at first I assumed I was going to need to pick up an Arduino and hack together some physical inputs, LEDs for an interface, and a speaker. It wasn't until I started shopping around for pieces and learning about the tech stack that I realized I could just take my old phone, pop open a browser, and prototype it that way.
There's a lot of complaints that not everything should be in the browser, and that's very true for a lot of cases, but it's extremely empowering that anything _could_ be in the browser, at least for your MVP.