The IDE Divide (2004)
blog.osteele.com
blog.osteele.com
It's the worst of both words: Even if you're using vim, you spend an awful lot of your time using (or debugging) tools like webpack, minifiers, live-reloaders, and of course the in-browser dev tools.
BUT, you still don't get the benefits of an old-school IDE, because no IDE can reason about a modern web stack reliably! Take something basic like click-to-code: "where is this attribute defined?" The web is such a Turing Tarpit[0] that, if that data comes from the backend, that question is literally undecidable. Between the database and that JS object are ORMs, backend frameworks, REST requests, microservices, JS frameworks, templating engines, and possibly CSS frameworks as well. At best, you can build good IDEs within one layer of the stack (I love WebStorm, and the VSCode+code-server stuff is cool - but they break down completely at stack boundaries).
[0] https://en.wikipedia.org/wiki/Turing_tarpit
And it's been like this for so long that new web developers don't even remember what it was like to have full autocomplete, everywhere in your project!
I have a dog in this fight - I founded a startup (https://anvil.works) to make web-dev tools, and we realised that to reason automatically about a web app you basically have to replace the whole stack. We went with Python - by doing Python front-end and back-end, replacing REST calls with function calls, and building a UI toolkit rather than generating HTML, it turns out you can have actual, real click-to-code, across your whole program. And full-stack autocomplete (I gave a talk about that one[1]).
If the Web is going to turn us all into tool mavens, at least we should do it right!
Python seems to be a sensible choice. Others, that are already almost there, would be JS, Rust, Clojure, and I think people do similar things in Haskell as well.
https://news.ycombinator.com/item?id=24805006
> Both the servers and the client running in your browser is written in Nim. The client uses Nim's JS backend and the server Nim's C backend. The two share code to ensure the game simulation is the same across both. Communication happens over websockets.
> It's been a lot of fun working on this and I cannot imagine another language being as flexible as Nim to make something like this possible.
Are you talking about browser app toolchains? If so, I disagree. HTML and CSS are all you need, with some vanilla JS. For example, HN users love the fact that it’s fast and responsive. It doesn’t use huge toolchains of React or whatever
Using huge tool chains is making the internet slower and more painful for devs & users.
But if you’re talking about dev tool chains for templating, I follow the “less is more” here too. Some templating tools can speed a dev up, but learning a dozen tools is really a waste of time
Users say they want simplicity like they say they want to start diets: everyone says they want it but when they're actually forced to do it, nobody wants it for more than 5 minutes.
Most users hate or fear what software does but don't think things can be better.
It also loads lightning fast.
This is using next.js and preact.
It can be that because it is downright ascetic.
It's easy to be fast and responsive and at the same time eschew all the fancy toolchainy stuff when you have very few features.
For a modern web application?! Absolutely not, the things the OP mentioned (webpack, 1000 node packages etc) are essential.
Even on the IDE side, I have...100 extensions installed?
Till this very day I can count a handful of devs who can give me a reasonable use case for react and why evey website should be a webapp. Im bad guy uno at every dev meeting because I have the audacity to suggest that not every webapp is facebook or something similarly complicated.
God bless NPM but Ill be damned if I dont get heart palpitations at the node modules ever increasing bundle. Its all magic or filth under the carpet. Magic is good when sprinkled and self contained but not when its all made of magic.
So Im detoxing and going back tk life without node modules and using jquery a lot more.
PS I really like the layout of your transcript. I would imagine that was done by hand? It would be especially cool to auto-generate transcripts like this. Suggestion - making the images clickable so that we can see the code frags better.
2. Python is the most popular language that isn't JS. It's used for teaching almost everywhere, it's used for data science, it's used on the back-end, even embedded code...
3. We wanted to start with an "island of sanity". If you google "how to do X in JS", you'll find StackOverflow and end up tweaking a DOM node, or making an HTTP request, or grabbing something else that breaks the abstraction and brings back the traditional Web hairball.
We want to make it easy to escape, of course (I wrote an whole essay about that[0]), but not so easy that you wander out of it without realising, and then find that the autocompleter no longer understands all of your project.
[0] https://anvil.works/blog/escape-hatches-and-ejector-seats
4. People who speak JS have already invested in the web - they've paid the price, got the scars, and probably have more than a little of their professional capital invested in "being a web developer". We want to win them over in the end, of course, but they would have been a very hard target market for an MVP!
However, nobody has said that the world has to end there. What about, for instance, declarative languages, domain specific languages, logic programming, computational notebooks? We still have special purpose tools for that, something which you typically don't see in a standard IDE. (Of course you could argue that IDEs as modular software just integrate all this special purpose stuff)
For my perspective, one best works with an IDE if one is d'accord with all the core principles of the IDE and software ecosystem it proposes. Whenever you want to do something out of the box, the IDE reduces to nothing more then a bulky text editor. That's why I think real innovation doesn't happen in IDEs.
"The Language Server Protocol (LSP) is an open, JSON-RPC-based protocol for use between source code editors or integrated development environments (IDEs) and servers that provide programming language-specific features. The goal of the protocol is to allow programming language support to be implemented and distributed independently of any given editor or IDE."
The standard is very OOP centered. It's not much that it won't work on other paradigms, but that it's limited to what is useful for OOP, so it won't lead to a perfect IDE to them.
The only thing I can think of is that a given language may not have suitable representation in the IDE, eg a data-flow visual language when most of the IDEs features are centered around text.
For a statically typed language an IDE makes much more sense than for a dynamically typed one.
When PHP got more static typing features over the years I switched to an IDE and it was awesome. When I started using JavaScript in 2011, an IDE didn't help that much.
You can be a maven for both, but I don't think you can be a complete language expert for multiple languages. Then again, perhaps you don't have to be, just a solid grasp without knowing the dark corners is quite sufficient to get real work done.
Edit: emacs has omnisharp which provides some instant feedback and some refactoring, but it's a lot better in VS.
Every now and then I see emacs features that I wish existed in VSCode, and often I feel like VSCode extensions are reinventing the wheel but less well and more expensively...and yet, I’ve mostly given up and just use VSCode, because what it does right is make it relatively easy for anybody to write whatever feature they might want to exist, for the most part in whatever language with a small adapter to JavaScript, and package it as an extension.