4 ms·

It is so much easier and faster to build web apps using TypeScript, Vite and React (or any other similar stack) rather than vanilla JS. I find this “leveragin

It is so much easier and faster to build web apps using TypeScript, Vite and React (or any other similar stack) rather than vanilla JS. I find this “leveraging the extreme simplicity” effort wholly misguided. It’s neither “enjoyable” nor “seamless” to manually synchronise the backend, the frontend logic and the DOM of your app without frameworks. And maybe the trite talking point of helping young developers by sending unoptimized unminimized comment-rich source code directly to end-users held at least some weight in the 00s; nowadays we have an abundance of tutorials, courses, conference talks and open source projects that can help autodidacts to learn anything related to web development.

dartos 3y ago
It depends, I think. For “apps” vanilla js isn’t enough. But for a blog with some animations or simple validation, things like next or gatsby is WAY too much
- treyd 3y ago
  My rule of thumb is that if you're building something sophisticated enough that you want to reach for more "advanced" js frameworks then you shouldn't be building it as a webapp.
  - dartos 3y ago
    Why? The web has moved far beyond a document sharing platform. It’s the largest, easiest (for users,) and most compatible software development and publishing platform ever. By far. It’s not good for everything all the time, but it is good for most UI focused software most of the time.
    - zlg_codes 3y ago
      Is there no appreciation for using the right tool for the job? When you build an app on Electron, you're forcing the client to run another browser, alongside whatever other browsers they're running. Due to the complexity of the Web, running a browser now takes hundreds of megabytes of RAM, sometimes a gig or two. Now imagine you have 8 different Electron apps you use. You have the system resource use of 8 separate browsers now. Congrats. Secondly, there's no integration between Web apps and the OS. Only recently did things like light and dark mode get OS-level support, so there's that much, but long story short, Web apps don't integrate well with the system. They tend to be shipped in containers, too, so while it may be "good security" it results in a worse runtime environment and uses more resources. The Web is a document platform, first and foremost. The building of V8 and Node.js, the myriad frameworks, etc, are the result of companies trying to turn an existing protocol into a moneymaker. Tim Berners Lee never intended the Web to be an application platform or a vector for DRM. For-profit interests created all of that extra complexity, and took over standards committees to push their ideas through. Web apps work best when they take advantage of some of the Web's strengths. If your program needs to talk on the network a lot and it's already working with HTML, then yes maybe it should be a webapp. The problem is everyone's ignoring the complexity, resource use, and tangled knot of abstraction on the client's end. It's "not a big deal", until it is, then we'll go back to rediscovering how easy native development is with a smart enough Makefile. All the major UI toolkits are cross-platform, there's little excuse.
  - ativzzz 3y ago
    I think you are totally correct- we should we building them as electron apps instead :)
deleted 3y ago
[deleted]
jonkoops 3y ago
I agree in principle that HTML is the best option for a good user-experience, but it quickly breaks down in terms of developer-experience and maintainability. However, we don't need to compromise on either by using a solution like Qwik[1]. Where the page progressively becomes more interactive with JavaScript, and doing as much work as possible on the server beforehand. 1. https://qwik.builder.io/ https://qwik.builder.io/
zlg_codes 3y ago
> nowadays we have an abundance of tutorials, courses, conference talks and open source projects that can help autodidacts to learn anything related to web development. That method was horrible, as someone who struggled with poor knowledge sources until HTMLDog and MDN became a thing. ...Conference talks? lmao your class is showing, the average self-taught hacker can't afford to go to those. Anyway, View Source is a good way to learn how to do something you see for the first time. It's a necessary feature to double-check what's being sent to the browser when you're developing, too, and keeps website operators honest by giving you a way to inspect how they build their site. Personally I think webapps are the wrong solution for a ton of problems, but the industry won't accept that until the bottom line is affected. I'm waiting for native apps that communicate over the same commercialized protocol. QUIC but its own piece of software instead of co-opting the Web.
- LudwigNagasena 3y ago
  > That method was horrible, as someone who struggled with poor knowledge sources until HTMLDog and MDN became a thing. But they are a thing now. > ...Conference talks? lmao your class is showing, the average self-taught hacker can't afford to go to those. An average self-taught hacker can afford YouTube. That’s why I explicitly mentioned talks and not conferences per se. > Anyway, View Source is a good way to learn how to do something you see for the first time. It's a necessary feature to double-check what's being sent to the browser when you're developing, too, and keeps website operators honest by giving you a way to inspect how they build their site. Opening up source code is a choice. And if a creator wants to open-source their app, I would rather look at it in GitLab rather than in production.

dartos 3y ago

It depends, I think. For “apps” vanilla js isn’t enough. But for a blog with some animations or simple validation, things like next or gatsby is WAY too much

treyd 3y ago
My rule of thumb is that if you're building something sophisticated enough that you want to reach for more "advanced" js frameworks then you shouldn't be building it as a webapp.
- dartos 3y ago
  Why? The web has moved far beyond a document sharing platform. It’s the largest, easiest (for users,) and most compatible software development and publishing platform ever. By far. It’s not good for everything all the time, but it is good for most UI focused software most of the time.
  - zlg_codes 3y ago
    Is there no appreciation for using the right tool for the job? When you build an app on Electron, you're forcing the client to run another browser, alongside whatever other browsers they're running. Due to the complexity of the Web, running a browser now takes hundreds of megabytes of RAM, sometimes a gig or two. Now imagine you have 8 different Electron apps you use. You have the system resource use of 8 separate browsers now. Congrats. Secondly, there's no integration between Web apps and the OS. Only recently did things like light and dark mode get OS-level support, so there's that much, but long story short, Web apps don't integrate well with the system. They tend to be shipped in containers, too, so while it may be "good security" it results in a worse runtime environment and uses more resources. The Web is a document platform, first and foremost. The building of V8 and Node.js, the myriad frameworks, etc, are the result of companies trying to turn an existing protocol into a moneymaker. Tim Berners Lee never intended the Web to be an application platform or a vector for DRM. For-profit interests created all of that extra complexity, and took over standards committees to push their ideas through. Web apps work best when they take advantage of some of the Web's strengths. If your program needs to talk on the network a lot and it's already working with HTML, then yes maybe it should be a webapp. The problem is everyone's ignoring the complexity, resource use, and tangled knot of abstraction on the client's end. It's "not a big deal", until it is, then we'll go back to rediscovering how easy native development is with a smart enough Makefile. All the major UI toolkits are cross-platform, there's little excuse.
- ativzzz 3y ago
  I think you are totally correct- we should we building them as electron apps instead :)

deleted 3y ago

[deleted]

jonkoops 3y ago

I agree in principle that HTML is the best option for a good user-experience, but it quickly breaks down in terms of developer-experience and maintainability. However, we don't need to compromise on either by using a solution like Qwik[1]. Where the page progressively becomes more interactive with JavaScript, and doing as much work as possible on the server beforehand. 1. https://qwik.builder.io/ https://qwik.builder.io/

zlg_codes 3y ago

> nowadays we have an abundance of tutorials, courses, conference talks and open source projects that can help autodidacts to learn anything related to web development. That method was horrible, as someone who struggled with poor knowledge sources until HTMLDog and MDN became a thing. ...Conference talks? lmao your class is showing, the average self-taught hacker can't afford to go to those. Anyway, View Source is a good way to learn how to do something you see for the first time. It's a necessary feature to double-check what's being sent to the browser when you're developing, too, and keeps website operators honest by giving you a way to inspect how they build their site. Personally I think webapps are the wrong solution for a ton of problems, but the industry won't accept that until the bottom line is affected. I'm waiting for native apps that communicate over the same commercialized protocol. QUIC but its own piece of software instead of co-opting the Web.

LudwigNagasena 3y ago
> That method was horrible, as someone who struggled with poor knowledge sources until HTMLDog and MDN became a thing. But they are a thing now. > ...Conference talks? lmao your class is showing, the average self-taught hacker can't afford to go to those. An average self-taught hacker can afford YouTube. That’s why I explicitly mentioned talks and not conferences per se. > Anyway, View Source is a good way to learn how to do something you see for the first time. It's a necessary feature to double-check what's being sent to the browser when you're developing, too, and keeps website operators honest by giving you a way to inspect how they build their site. Opening up source code is a choice. And if a creator wants to open-source their app, I would rather look at it in GitLab rather than in production.