Mentioned Glitch and Replit in the article - they're great and I love them but there's still something missing about relying on these platforms imho. I think cementing a default coding environment right into the browser would make it a lot more accessible - and actually be much closer to real coding where you're manipulating files and running code.
Plus: glitch/replit are quite slow to do any real coding inside of vs developing locally.
But maybe the future really is in the browser in this way.
But why stop there? Let’s bundle something like Excel or Powerpoint, or Photoshop or Final Cut.
If we’re deciding to bundle additional software with a browser, why would a programming environment (chosen based on someone’s favorite language) be top priority?
Imagine if there was some kind of runtime the browser shipped with that could let developers create all kind of applications that are downloaded and run on demand. That would be pretty cool.
With good reasons at the time -- browsers were slow and heavy. Now we have (among others) the V8 Javascript engine and insanely fast client computers (all of any recent desktop, laptop, and mobile device)
Already did. The author found that installing Node.js needs knowledge about the command line while Excel just needs a few clicks of "Next" (I just did it yesterday)
If you open the dev tools in your browser there's a full sandbox environment right there, not to mention the load of other sites available. I don't see why specifically Node should be installed.
I just wrote a bunch of code inside Chrome devtools to do some web scraping. It works pretty well, with a REPL, (overly aggressive) autocomplete, and good integration with the DOM, but it's also limited.
Saving and loading .js files uses a very non-standard flow. The editor is OK but I think basic operations like "find across files" are missing. It's very "canned" and not customizable.
In other words, it feels more like a debugging environment than a programming environment, which I think is basically what they were going for.
Agreed, the much stronger counterargument is that all major browsers already have JS development environments built in! I am curious to hear why this is not suitable for the author.
I think you're craving a 21st century version of Emacs, where the development environment is baked into the product. I agree it's awesome, and I think the browser comes the closest, but you're right, it's not there yet. I fear the reason is mostly security: browsers are used by billions, but Emacs benefits from relative obscurity.
Yeah I love Replit and Glitch (not used the others) but I still think there's something missing. They don't feel like standards that are easy and simple to use. Two more points:
> 1) offer native local speed - Glitch and Replit can still feel a bit slow on continual page refresh. 2) having your development files available locally - so that it's easy to take those files and upload to netlify etc or even edit using another app.
The solution to this is to use an actual native IDE, not try to shoehorn it into the browser, which is completely inappropriate.
I believe node itself s just an environment/blank canvas as well. What is this "standards" you're looking for? There are a million frameworks, templates, etc as well.
Secondly - I wish I could get ScrollToTextFragment to work reliably. I've tried integrating this into Quotebacks and every time it just works so sporadically that I roll it back. Somehow Google thinks this is robust and stable enough to put into production but my experience is very hit/miss.
Author here - thanks for all the comments and feedback. Lovely surprise to wake up to this on the HN homepage.
Some light additional context - this is part of my ongoing series "The Strategic Independent" which will eventually become a book sometime next year. All the posts in that series are catalogued here: https://www.are.na/tom-critchlow/the-strategic-independent
This post (and the whole series) is designed for independent consultants, free-agents and freelancers who have to navigate entering and exiting client environments often faster than full-time employees. Hopefully there's something useful in that context but many of these ideas could be applicable beyond that also.
Anyway - thanks for the love. If you have topic suggestions for future posts in this series would love to hear them! Thanks, Tom.
> Hopefully there's something useful in that context but many of these ideas could be applicable beyond that also.
They’re very applicable outside the context of consulting - they’re fundamental for any leader joining a new organization to integrate well and get things done. Consultants transition more often than most; the principles you’ve shared are a great reference for the rest of us on how to be effective in a new environment.
Author here: yes I have an email list here (infrequent) that I'll post a message to once chapters 3 and 4 are ready: https://tinyletter.com/tomcritchlow
Author here - Yes I would definitely recommend reading Impro over reading my blog post.
The basic premise for this series is inspired by the book and I definitely borrow more directly and heavily for chapters 3 and 4 (which aren't quite ready to publish yet!).
Author here - yeah I hear you. I love the hypothesis interactions when they happen on my site but the UI is a little aggressive (especially on mobile). All about tradeoffs unfortunately.
Hi, I'm Tom the author of this piece (thanks gk1 for submitting!). I'd love to hear what others here at HN have struggled with regarding labels and identity. I imagine there's a huge spectrum of possible labels for developer-types from "freelance python developer" to "software architect" to "engineering consultant"...!
Plus: glitch/replit are quite slow to do any real coding inside of vs developing locally.
But maybe the future really is in the browser in this way.