5 ms·

This article is dated because these days, even the people who exclusively use vim are mostly "tool mavens" - because most people are driving the Web, and the on

This article is dated because these days, even the people who exclusively use vim are mostly "tool mavens" - because most people are driving the Web, and the only way to make the Web bearable is to load yourself up with huge toolchains. 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 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 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! [1] https://anvil.works/blog/python-autocompleter-pycon17 https://anvil.works/blog/python-autocompleter-pycon17

dgb23 6y ago
I think this is the right approach. Use one language to rule them all, integrate the whole UI related stack into it, from backend to frontend, and drive the integration by well defined protocols (data/types). 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.
- boogies 6y ago
  I think the Nim devs want it to work for this too: https://news.ycombinator.com/item?id=24805006 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.
part1of2 6y ago
> because most people are driving the Web, and the only way to make the Web bearable is to load yourself up with huge toolchains. 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
- oblio 6y ago
  Yeah, but show HN to regular users. Most of them would be appalled by the looks, the way it is structured, the simplicity. 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.
  - swiley 6y ago
    I really don't think so. The reason other sites look so bad is more marketing/AB testing centered around engagement, not because users like it. Most users hate or fear what software does but don't think things can be better.
- charrondev 6y ago
  IDK, I started a blog recently with server rendered react and the thing builds on <15s for a production build (from the time the GitHub we hook runs a push to me seeing the new site deployed), and in ~2s for a local dev build. It also loads lightning fast. https://charron.dev https://charron.dev This is using next.js and preact.
  - istjohn 6y ago
    The menu is broken for me on Android Brave.
hobby-coder-guy 6y ago
Why python?
sevensor 6y ago
Not all programming is web programming, and not all users of text editors are trying to turn them into IDEs. I think the article itself was insightful in identifying two camps of programmers with minimal overlap. Most of the discussion I've seen since we all got trolled by StackOverflow a couple of days ago has been members of the two camps talking past each other. More than anything else I've read lately, this article has helped me understand how the other side sees the world.
localhost 6y ago
While I love Python, and I love the idea of autocomplete everywhere for everything, I'm curious why not do the same thing, but for Java/TypeScript? 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.
- meredydd 6y ago
  1. The people who are most "shut out" by the complexity of the web do not, by definition, speak Javascript. These are the folks who need Anvil most! Most people who speak JS already know web-dev (why else would you learn JS?) 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 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!
  - localhost 6y ago
    Good on you for focusing on establishing a beachhead customer! Hope things work out with that initial cohort.

dgb23 6y ago

I think this is the right approach. Use one language to rule them all, integrate the whole UI related stack into it, from backend to frontend, and drive the integration by well defined protocols (data/types). 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.

boogies 6y ago
I think the Nim devs want it to work for this too: https://news.ycombinator.com/item?id=24805006 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.

part1of2 6y ago

> because most people are driving the Web, and the only way to make the Web bearable is to load yourself up with huge toolchains. 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

oblio 6y ago
Yeah, but show HN to regular users. Most of them would be appalled by the looks, the way it is structured, the simplicity. 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.
- swiley 6y ago
  I really don't think so. The reason other sites look so bad is more marketing/AB testing centered around engagement, not because users like it. Most users hate or fear what software does but don't think things can be better.
charrondev 6y ago
IDK, I started a blog recently with server rendered react and the thing builds on <15s for a production build (from the time the GitHub we hook runs a push to me seeing the new site deployed), and in ~2s for a local dev build. It also loads lightning fast. https://charron.dev https://charron.dev This is using next.js and preact.
- istjohn 6y ago
  The menu is broken for me on Android Brave.

hobby-coder-guy 6y ago

Why python?

sevensor 6y ago

Not all programming is web programming, and not all users of text editors are trying to turn them into IDEs. I think the article itself was insightful in identifying two camps of programmers with minimal overlap. Most of the discussion I've seen since we all got trolled by StackOverflow a couple of days ago has been members of the two camps talking past each other. More than anything else I've read lately, this article has helped me understand how the other side sees the world.

localhost 6y ago

While I love Python, and I love the idea of autocomplete everywhere for everything, I'm curious why not do the same thing, but for Java/TypeScript? 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.

meredydd 6y ago
1. The people who are most "shut out" by the complexity of the web do not, by definition, speak Javascript. These are the folks who need Anvil most! Most people who speak JS already know web-dev (why else would you learn JS?) 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 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!
- localhost 6y ago
  Good on you for focusing on establishing a beachhead customer! Hope things work out with that initial cohort.