5 ms·

> I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back t

> I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs starting out and learning new things. Same here, and I couldn't agree more. Had minified library soup with dynamic page content been the norm back then it would've been much harder to get started, and there's a high chance I would've just given up somewhere in the process. Having a build step also increases activation energy and friction which impedes the sort of in-the-moment tinkering that often sparks projects.

dheera 3y ago
> Having a build step also increases activation energy and friction Yes this! As an interpreted language it should not need a build step. Every project should be git clone https://github.com/user/foo && cd foo && google-chrome index.html
- Zelphyr 3y ago
  You guys are singing the song of my people. For years I've been confounded at the idea that we need to be building/compiling interpreted code. And the tooling... my God! I know this makes me sound like an old man (because I am) but, it used to be all I needed was an editor, an FTP client, and a browser. write-upload-refresh. Today, I find VS Code, `git push`, and a browser still serves me very well.
- pmontra 3y ago
  I'm also against building and compiling (I work with Python and Ruby on the backend) but there were good reasons to have those steps, at least in the past and probably still now. Short and very incomplete list, feel free to reply and add points: * slow network, especially on mobile * reduce the size of the download by minifying * reduce the number of calls by bundling files in a single one * Inconsistent JS and HTML feature support among browsers * transpiling to a common older version of JS * add polyfills to implement missing features * add widgets to implement fucked up default implementations or widgets that are nearly impossible to standardize (date and time pickers might need tons of features and are projects on their own)
  - kitsunesoba 3y ago
    Most of those points could be taken care of by building only when deploying though, skipping the phase during development. I think most of the annoyance with a build step comes from how you can’t do anything unless the tooling for it is set up, as well as how it gunks up the tweak → reload cycle.
jabart 3y ago
Irony is that javascript handlers on elements were frowned upon in 90s/00s because of separate of concerns that HTML should be HTML and JS should attach it's events in a separate file. Now all of these libraries have an onclick that mirrors those original JS event handlers in the same html with no separation!
- samwillis 3y ago
  Only thing missing is inlining your css styles on each element, only a mad man would try that though... [cough]... https://github.com/samwillis/x-style https://github.com/samwillis/x-style
  - endofreach 3y ago
    Or, tailwindcss…
    - efskap 3y ago
      Did you even click the link? The "Why?" section explains the problem with tailwind and the code sample shows it's doing a different thing, closer to htmx.
    - samwillis 3y ago
      Tailwind is awesome and gets so much right. However, it requires a build step using local dev tools, and it has a complete DSL that reimplements most of css as classes. Utility classes for uniform padding, spacing, border, colours etc at brilliant. But my suggestion with x-style is that placing the actual css on an element may be better. It's an experiment, seeing where it leads.
- ximm 3y ago
  If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives https://www.w3.org/TR/CSP2/#directives
bobthepanda 3y ago
Unfortunately we need the JS still because the standards are so lacking, and when they’re not it takes a while to get everybody on it. As a general example, despite three decades of the web existing across the world in many jurisdictions with more than one language, the solution to translation for a site is just some translation framework or tediously maintaining a whole copy of your site per language.
- austin-cheney 3y ago
  The standards are fine. The problem is that the front end web is the DOM. I love the DOM, but it scares the shit out of people. Most people would rather cut their hand off or sell their children into child slavery than walk the DOM with 3 instructions. Its super weird and gets more weird when those people are actually confronted with this irrational behavior.

dheera 3y ago

> Having a build step also increases activation energy and friction Yes this! As an interpreted language it should not need a build step. Every project should be git clone https://github.com/user/foo && cd foo && google-chrome index.html

Zelphyr 3y ago
You guys are singing the song of my people. For years I've been confounded at the idea that we need to be building/compiling interpreted code. And the tooling... my God! I know this makes me sound like an old man (because I am) but, it used to be all I needed was an editor, an FTP client, and a browser. write-upload-refresh. Today, I find VS Code, `git push`, and a browser still serves me very well.
pmontra 3y ago
I'm also against building and compiling (I work with Python and Ruby on the backend) but there were good reasons to have those steps, at least in the past and probably still now. Short and very incomplete list, feel free to reply and add points: * slow network, especially on mobile * reduce the size of the download by minifying * reduce the number of calls by bundling files in a single one * Inconsistent JS and HTML feature support among browsers * transpiling to a common older version of JS * add polyfills to implement missing features * add widgets to implement fucked up default implementations or widgets that are nearly impossible to standardize (date and time pickers might need tons of features and are projects on their own)
- kitsunesoba 3y ago
  Most of those points could be taken care of by building only when deploying though, skipping the phase during development. I think most of the annoyance with a build step comes from how you can’t do anything unless the tooling for it is set up, as well as how it gunks up the tweak → reload cycle.

jabart 3y ago

Irony is that javascript handlers on elements were frowned upon in 90s/00s because of separate of concerns that HTML should be HTML and JS should attach it's events in a separate file. Now all of these libraries have an onclick that mirrors those original JS event handlers in the same html with no separation!

samwillis 3y ago
Only thing missing is inlining your css styles on each element, only a mad man would try that though... [cough]... https://github.com/samwillis/x-style https://github.com/samwillis/x-style
- endofreach 3y ago
  Or, tailwindcss…
  - efskap 3y ago
    Did you even click the link? The "Why?" section explains the problem with tailwind and the code sample shows it's doing a different thing, closer to htmx.
  - samwillis 3y ago
    Tailwind is awesome and gets so much right. However, it requires a build step using local dev tools, and it has a complete DSL that reimplements most of css as classes. Utility classes for uniform padding, spacing, border, colours etc at brilliant. But my suggestion with x-style is that placing the actual css on an element may be better. It's an experiment, seeing where it leads.
ximm 3y ago
If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives https://www.w3.org/TR/CSP2/#directives

bobthepanda 3y ago

Unfortunately we need the JS still because the standards are so lacking, and when they’re not it takes a while to get everybody on it. As a general example, despite three decades of the web existing across the world in many jurisdictions with more than one language, the solution to translation for a site is just some translation framework or tediously maintaining a whole copy of your site per language.

austin-cheney 3y ago
The standards are fine. The problem is that the front end web is the DOM. I love the DOM, but it scares the shit out of people. Most people would rather cut their hand off or sell their children into child slavery than walk the DOM with 3 instructions. Its super weird and gets more weird when those people are actually confronted with this irrational behavior.