9 ms·

> With the web almost everyone has a machine that has a programmable environment by default again. I feel this is a very important and powerful advantage that’s

by mrec 7y ago

> With the web almost everyone has a machine that has a programmable environment by default again. I feel this is a very important and powerful advantage that’s often overlooked. As someone else who cut their teeth on an 8-bit micro back in the day, I agree with this 100%. And I think it's a large part of the reason I'm so suspicious of the stampede in webdev toward very heavyweight toolchains over the past 5+ years; while they may have had the best of intentions, I think they do end up putting gatekeeper-ey accessibility barriers around the web's original rough democracy. It's not that the underlying technology has gone away, more that when someone starts looking around the mainstream web to see how things are put together, that's not what they're going to find.

jaywalk 7y ago
Are you saying that we shouldn't have the advanced web applications that we do today?
- DougWebb 7y ago
  I would say that we shouldn't have an advanced web application unless we need an advanced web application. Most of the time, we really don't need it.
  - andai 7y ago
    You must enable JavaScript to view this static text blog.
- bdcravens 7y ago
  This presumes that heavy toolchains are a prerequisite of advanced web applications. The toolchains seem to be more about ergonomics than creating new capabilities.
  - WorldMaker 7y ago
    A large part of the toolchains are also bandaids on a lot of unnecessary friction caused by changing standards and moving targets. The web platform is almost to the point where a lot of those bandaids could just be ripped off: ES2015 modules are directly supported in most browsers today, same with CSS modules / syntax through ES2017 or more recent / and so forth, and protocol upgrades in HTTP2 and HTTP3 remove a lot of the performance-specific needs for things like bundling and minification. The biggest hurdle to ripping off the bandaids (as with so many things in software development) is the rough edges of the long tail of legacy code. The biggest example being that there's still so much code written for CommonJS (or AMD) that needs shims to play well in ES2015 module worlds. (Because no one wants to stop the Node world and rewrite everything all at once.)
    - fwip 7y ago
      pika.dev is coming really close to shimming a ton of existing libraries into module world.
- thrower123 7y ago
  I can't think of a case in the past decade where I've really wanted to have a web application rather than a proper native thick client. I understand the attraction, and I've had to build my fair share of them, but I don't like it at all.
- mrec 7y ago
  I'm not at all convinced that the heavyweight toolchains have led to any improvement in webapp quality. Maybe there are rockstar apps out there I just haven't seen, but for the most part the web these days is vastly more bloated and somewhat less stable than it used to be, without doing anything more that any user actually wants. This is not progress.
- pjmlp 7y ago
  Actually yes, we don't need SPAs to display basic blocks of text with some animation.
IshKebab 7y ago
I agree. Node, webpack, npm, babel, etc. all add a huge amount of friction to getting started. It doesn't help that they're all overly complex and every little thing has a different tool or configuration file. It's a huge complex house of cards that nobody really wants to have to deal with. Compare it to writing a Qt app, or even something like a Flutter app. You pretty much just install an SDK and go file -> new project.
- AnIdiotOnTheNet 7y ago
  Or compare it to something like Lazarus, where you install the environment (sadly it is not at all portable) and can construct GUI applications with a WYSIWYG editor that compile directly to native binaries for multiple platforms.
  - unlinked_dll 7y ago
    GUI editors always go in cycles, and we always come back around to writing code as the editors can't represent the things we want to do.
    - AnIdiotOnTheNet 7y ago
      Except for a huge number of use cases where they can, of course. Obviously not everything can be abstracted away, but things like Lazarus or HyperCard or even Excel offer a starting off point for people to build powerful tools to solve their problems without acquiring a traditional programming education, and offer a ramp into programming for when people need to do more with those tools.
- kls 7y ago
  Personally I would argue that it is no more complex than JSP/JSF/Spring or ASP.NET/Web Components / Web Forms, then you have to bolt on server side session management, state transfer and the other patterns that emerge from sending everything to the server. In my opinion doing all of the UI interaction on the client is easier to reason about and simplifies state management. Now I would tend to agree that classic ASP / PHP was conceptually simple and probably simpler than the current client side landscape, but they where beasts at scale. I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities into the mix that you circumvent with desktop where you are delivering from the run-time up. For better or worse, the browser, the webserver and the middleware stack all dictate how we get to go about building applications for the web.
xyz0 7y ago
Sure, modern JS tooling is complex, but a 14-year-old just looking to play around with programming isn't going to build a Facebook clone as their first project. You can always create a barebones HTML file and drop some JS into a `<script>` tag and be up-and-running in two minutes. If you don't want to use modern tooling that was designed for large-scale SPAs, then don't.
- GuiA 7y ago
  In my experience teaching 14 year olds, that is precisely the kind of thing they first want to build: the things they know and use everyday (in 2020 it’s more likely to be Snapchat/Instagram/TikTok than Facebook, but the point remains). And indeed, with a batteries included kind of solution like PHP/MySQL, one can build a basic Facebook like in a week long workshop or so. You won’t understand everything that’s going on under the hood of course, but the fact remains that it’s way more accessible than the webpack/Babel/react.js/etc stacks that web devs push these days (waiting for the inevitable “oh no one uses webpack anymore, it’s all about ChirpChirp.js these days!” :)
- kart23 7y ago
  I was really turned off by react because of the necessity to use JSX, which in turn required me to use babel, its just adding too much complexity. So I'm still just using jquery.
  - hastes 7y ago
    I would look into CRA (https://github.com/facebook/create-react-app https://github.com/facebook/create-react-app). It handles all the Babel/Transpiling/Webpack mumbo-jumbo for you so you can focus on writing code. Although I would eventually recommend learning how to utilize Babel & Webpack yourself because knowing why and how it works is useful.
    - brlewis 7y ago
      If kart23's objection to complexity is how long it takes to get up and running, I agree about CRA. I agree about knowing the why of Babel and Webpack. But how they work isn't something everybody has to learn. If it's some other objection to complexity, I'd recommend learning modern web dev using https://mithril.js.org/ https://mithril.js.org/ which can use JSX, but in documentation the non-JSX form is primary.
spankalee 7y ago
Luckily you can now use standard JS modules and web components to nicely organize code and widgets without buying into any tooling or framework. Things are getting a lot better.
- lucasverra 7y ago
  do you have a sample app / repo to illustrate ? You can use repl.it to host
- Vinnl 7y ago
  But then you're buying into Web Components and their limitations instead. Luckily, whatever people could do in the pas, they can still do today, because the web is largely backwards compatible. Then at some point they'll run into some things that seem harder than they need to be, at which point they can start looking at the tooling that was designed to solve those exact problems.
divbzero 7y ago
> With the web almost everyone has a machine that has a programmable environment by default again. I feel this is a very important and powerful advantage that’s often overlooked. For this same reason, I’m disappointed that mobile browsers such as iOS Safari have yet to enable DevTools, e.g. a page inspector, network inspector, and JavaScript console. Especially for younger generations, there are many whose first computer will be a mobile device.
- pjmlp 7y ago
  They are enabled, kind of, you need to plug the device into its bigger brother. However, iOS more so than Android, has plenty of mature interactive code environments.
  - divbzero 7y ago
    > you need to plug the device into its bigger brother This exactly is the challenge. If your first computer is a mobile device, you would not have that “bigger brother” available. iOS does have Swift Playgrounds [1] and Android has the excellent Termux [2] but access to the built-in JavaScript engine would open a whole new set of possibilities. [1]: https://www.apple.com/swift/playgrounds/ https://www.apple.com/swift/playgrounds/ [2]: https://termux.com/ https://termux.com/ I was introduced to programming on a dinky little graphing calculator. My hope is that other “first computers” could offer similar opportunities for tinkering.
    - pjmlp 7y ago
      Agreed, but as mentioned there are also on device coding environments. On iOS you also have Pythonista, Continuous, Shaderific, Codea, all much better than learning FX-4500p, FX-850P Basic. Sadly on Android, most of the alternatives are quite lacking versus the iOS variants in capabilities and quality.

by mrec 7y ago

jaywalk 7y ago

Are you saying that we shouldn't have the advanced web applications that we do today?

DougWebb 7y ago
I would say that we shouldn't have an advanced web application unless we need an advanced web application. Most of the time, we really don't need it.
- andai 7y ago
  You must enable JavaScript to view this static text blog.
bdcravens 7y ago
This presumes that heavy toolchains are a prerequisite of advanced web applications. The toolchains seem to be more about ergonomics than creating new capabilities.
- WorldMaker 7y ago
  A large part of the toolchains are also bandaids on a lot of unnecessary friction caused by changing standards and moving targets. The web platform is almost to the point where a lot of those bandaids could just be ripped off: ES2015 modules are directly supported in most browsers today, same with CSS modules / syntax through ES2017 or more recent / and so forth, and protocol upgrades in HTTP2 and HTTP3 remove a lot of the performance-specific needs for things like bundling and minification. The biggest hurdle to ripping off the bandaids (as with so many things in software development) is the rough edges of the long tail of legacy code. The biggest example being that there's still so much code written for CommonJS (or AMD) that needs shims to play well in ES2015 module worlds. (Because no one wants to stop the Node world and rewrite everything all at once.)
  - fwip 7y ago
    pika.dev is coming really close to shimming a ton of existing libraries into module world.
thrower123 7y ago
I can't think of a case in the past decade where I've really wanted to have a web application rather than a proper native thick client. I understand the attraction, and I've had to build my fair share of them, but I don't like it at all.
mrec 7y ago
I'm not at all convinced that the heavyweight toolchains have led to any improvement in webapp quality. Maybe there are rockstar apps out there I just haven't seen, but for the most part the web these days is vastly more bloated and somewhat less stable than it used to be, without doing anything more that any user actually wants. This is not progress.
pjmlp 7y ago
Actually yes, we don't need SPAs to display basic blocks of text with some animation.

IshKebab 7y ago

I agree. Node, webpack, npm, babel, etc. all add a huge amount of friction to getting started. It doesn't help that they're all overly complex and every little thing has a different tool or configuration file. It's a huge complex house of cards that nobody really wants to have to deal with. Compare it to writing a Qt app, or even something like a Flutter app. You pretty much just install an SDK and go file -> new project.

AnIdiotOnTheNet 7y ago
Or compare it to something like Lazarus, where you install the environment (sadly it is not at all portable) and can construct GUI applications with a WYSIWYG editor that compile directly to native binaries for multiple platforms.
- unlinked_dll 7y ago
  GUI editors always go in cycles, and we always come back around to writing code as the editors can't represent the things we want to do.
  - AnIdiotOnTheNet 7y ago
    Except for a huge number of use cases where they can, of course. Obviously not everything can be abstracted away, but things like Lazarus or HyperCard or even Excel offer a starting off point for people to build powerful tools to solve their problems without acquiring a traditional programming education, and offer a ramp into programming for when people need to do more with those tools.
kls 7y ago
Personally I would argue that it is no more complex than JSP/JSF/Spring or ASP.NET/Web Components / Web Forms, then you have to bolt on server side session management, state transfer and the other patterns that emerge from sending everything to the server. In my opinion doing all of the UI interaction on the client is easier to reason about and simplifies state management. Now I would tend to agree that classic ASP / PHP was conceptually simple and probably simpler than the current client side landscape, but they where beasts at scale. I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities into the mix that you circumvent with desktop where you are delivering from the run-time up. For better or worse, the browser, the webserver and the middleware stack all dictate how we get to go about building applications for the web.

xyz0 7y ago

Sure, modern JS tooling is complex, but a 14-year-old just looking to play around with programming isn't going to build a Facebook clone as their first project. You can always create a barebones HTML file and drop some JS into a `<script>` tag and be up-and-running in two minutes. If you don't want to use modern tooling that was designed for large-scale SPAs, then don't.

GuiA 7y ago
In my experience teaching 14 year olds, that is precisely the kind of thing they first want to build: the things they know and use everyday (in 2020 it’s more likely to be Snapchat/Instagram/TikTok than Facebook, but the point remains). And indeed, with a batteries included kind of solution like PHP/MySQL, one can build a basic Facebook like in a week long workshop or so. You won’t understand everything that’s going on under the hood of course, but the fact remains that it’s way more accessible than the webpack/Babel/react.js/etc stacks that web devs push these days (waiting for the inevitable “oh no one uses webpack anymore, it’s all about ChirpChirp.js these days!” :)
kart23 7y ago
I was really turned off by react because of the necessity to use JSX, which in turn required me to use babel, its just adding too much complexity. So I'm still just using jquery.
- hastes 7y ago
  I would look into CRA (https://github.com/facebook/create-react-app https://github.com/facebook/create-react-app). It handles all the Babel/Transpiling/Webpack mumbo-jumbo for you so you can focus on writing code. Although I would eventually recommend learning how to utilize Babel & Webpack yourself because knowing why and how it works is useful.
  - brlewis 7y ago
    If kart23's objection to complexity is how long it takes to get up and running, I agree about CRA. I agree about knowing the why of Babel and Webpack. But how they work isn't something everybody has to learn. If it's some other objection to complexity, I'd recommend learning modern web dev using https://mithril.js.org/ https://mithril.js.org/ which can use JSX, but in documentation the non-JSX form is primary.

spankalee 7y ago

Luckily you can now use standard JS modules and web components to nicely organize code and widgets without buying into any tooling or framework. Things are getting a lot better.

lucasverra 7y ago
do you have a sample app / repo to illustrate ? You can use repl.it to host
Vinnl 7y ago
But then you're buying into Web Components and their limitations instead. Luckily, whatever people could do in the pas, they can still do today, because the web is largely backwards compatible. Then at some point they'll run into some things that seem harder than they need to be, at which point they can start looking at the tooling that was designed to solve those exact problems.

divbzero 7y ago

> With the web almost everyone has a machine that has a programmable environment by default again. I feel this is a very important and powerful advantage that’s often overlooked. For this same reason, I’m disappointed that mobile browsers such as iOS Safari have yet to enable DevTools, e.g. a page inspector, network inspector, and JavaScript console. Especially for younger generations, there are many whose first computer will be a mobile device.

pjmlp 7y ago
They are enabled, kind of, you need to plug the device into its bigger brother. However, iOS more so than Android, has plenty of mature interactive code environments.
- divbzero 7y ago
  > you need to plug the device into its bigger brother This exactly is the challenge. If your first computer is a mobile device, you would not have that “bigger brother” available. iOS does have Swift Playgrounds [1] and Android has the excellent Termux [2] but access to the built-in JavaScript engine would open a whole new set of possibilities. [1]: https://www.apple.com/swift/playgrounds/ https://www.apple.com/swift/playgrounds/ [2]: https://termux.com/ https://termux.com/ I was introduced to programming on a dinky little graphing calculator. My hope is that other “first computers” could offer similar opportunities for tinkering.
  - pjmlp 7y ago
    Agreed, but as mentioned there are also on device coding environments. On iOS you also have Pythonista, Continuous, Shaderific, Codea, all much better than learning FX-4500p, FX-850P Basic. Sadly on Android, most of the alternatives are quite lacking versus the iOS variants in capabilities and quality.