[HN Gopher] BYOJS (Bring your own JS)
___________________________________________________________________
BYOJS (Bring your own JS)
Author : fs_software
Score : 38 points
Date : 2024-12-16 17:28 UTC (1 days ago)
(HTM) web link (byojs.dev)
(TXT) w3m dump (byojs.dev)
| handfuloflight wrote:
| > and also no disrespect for those who like JS-looking languages
| like TypeScript...
|
| Why this alienation?
| hitekker wrote:
| Off-topic, feel free to ignore: I'm enjoying lit-html with web
| components (and no LitElement). Feels pretty native and down-to-
| DOM, kind of like building my own framework while building my own
| app. The aspects I need to control are mostly in my control and
| the aspect I don't care about are handled for me well.
|
| Paired with Claude Sonnet 3.5 and I'm more productive than I've
| been in years.
| fidotron wrote:
| Honestly, TypeScript and React are in such a good space now that
| adopting those two is a near no brainer. You need discipline to
| not bring in millions of other dependencies.
|
| I've done the whole "I'll write it all in JS by hand" to a
| ludicrous degree: https://luduxia.com/whichwayround (and the
| rest) and while there were advantages when this started I am now
| looking to port the useful bits over to saner ways for future
| maintenance.
| o11c wrote:
| I see lot of frontend people say this (since their baseline is
| "nothing"), but as someone who's used to compiled languages,
| all JS-ecosystem tooling is quite atrocious. It's still missing
| _many_ of the useful basics that other ecosystems take for
| granted.
| fidotron wrote:
| The way around this is to build your own tools. For instance,
| I used esbuild as a library to write a custom obfuscator that
| links the hand written JS and GLSL together. (This is why the
| shader link symbols are also obfuscated).
|
| I came from many years of compiled languages in the games
| industry. I would not assume the current state of React and
| TypeScript is bad, far from it. There are reasons this stuff
| has eaten away at more native approaches, or inspired things
| like SwiftUI.
|
| Edit to add: To also add that in my time I've seen more
| WebKit added to games in order to do the UI. For instance,
| that Sim City which was always connected to the cloud, or big
| bits of the PS4 interface.
| o11c wrote:
| "build your own tools" is also known as "the ecosystem is
| lacking"
| leptons wrote:
| One tool does not necessarily fit all the things. And
| that would be true of any "ecosystem" that has as many
| diverse uses as Javascript does.
|
| Versatility is one of Javascript's strengths, not a
| weakness. And with that versatility you get what seems
| like too many frameworks.
| supermatt wrote:
| Could you give some examples of these many missing basics?
| o11c wrote:
| Two blatant ones: 1. conditional compilation (typecheck and
| use these apis only in some environments), and 2. being
| able to compile "hello world" in under 1 second. I know I
| keep finding more but these ones I can't even write trivial
| programs without running into.
|
| I've been trying to emulate conditional compilation using
| multiple directories, but that runs into problems with each
| tool using different path lookup logic.
| MrJohz wrote:
| Can you describe some of those basics? In my experience, the
| JS ecosystem is surprisingly good, and most of the issues
| tend to be due to a lack of experience rather than directly
| tooling issues. For example, NPM is one of the better package
| managers out there, but like all package managers, if you
| haphazardly chuck dependencies at it, and don't pay attention
| to what you're going, you're going to have issues. A lot of
| people run into those sorts of issues and assume that this is
| a general NPM problem, but it doesn't have to be that way.
| zeta_ wrote:
| Why don't you give us some examples?
| mplewis wrote:
| These days, I would not write a pure JS app if I could help it.
| JS is so dynamic that TS is a mandatory step for safety whenever
| it's possible to use the TSC compiler.
| fidotron wrote:
| I've found tsc --noEmit with esbuild is the magic combination.
|
| This way you can split the type checking from the actual
| bundling, as esbuild only does the latter.
| STRiDEX wrote:
| esbuild can bundle typescript files directly, you don't need
| tsc to strip types
|
| edit: nevermind i get what you're saying. check types with
| tsc and dev work with esbuild
| brrrrrm wrote:
| probably my biggest pure JS app is this one:
| https://github.com/bwasti/mebm
|
| you can try it here https://bwasti.github.io/mebm/
| threatofrain wrote:
| Mmm as a library author, even if your users don't use TS they can
| still benefit from the typings you provide as an author.
| zoover2020 wrote:
| I really don't understand why people are still using an
| inferior tool chain to build JavaScript in 2024. The type
| checking alone has the potential to save countless of bugs.
|
| I wish we could get rid of "vanilla js must imply going back in
| time 10 years" ideology because it's so unnecessary. Using
| typescript doesn't mean you have to go react or other
| libraries.
| leptons wrote:
| eh... so far Typescript hasn't saved us from any bugs, but
| YMMV.
| philippta wrote:
| I've started building a new web app (not website) using Go and
| jQuery, all loaded from a CDN without any build step. Writing
| JavaScript the imperative way (rather than declarative like
| react) feels very refreshing.
| ervine wrote:
| I would feel cool doing this until any sizeable DOM
| manipulation and then immediately remember why react was such a
| godsend.
| fidotron wrote:
| The underappreciated part of React today is it helps you to
| be more secure by default. Once you are handling user
| generated content, even of the simplest kind, it's far safer.
| codegeek wrote:
| I would love to do this. However, if you are building a heavily
| interactive application, wouldn't it be easier to manage with a
| framework instead of jquery ? Wouldn't you want to manipulate
| DOM more easily than with jquery ? Unless the web app is not
| that complex. Thoughts ?
| winrid wrote:
| FastComments is a couple hundred thousand lines of JS now
| (backend and frontend, with a couple small backend java services)
|
| I hope to move to TS in 2025
|
| But, we still don't use a frontend framework, we just write
| components as classes. Each component takes a root node that the
| parent is supposed to "own", and that's kinda it. React is more
| productive short term, but I find this easier long term with
| complex UIs, keeping memory usage low, and less work keeping
| stuff upgraded.
| zdragnar wrote:
| I worked at an agency that did this (they were rather religious
| when it came to the "no frameworks" rule) and I can absolutely
| say that it is far less productive for complex UIs.
|
| It's basically a home-spun version of backbone, and the reason
| people don't do that so much anymore is the same that backbone
| fell out of favor- you don't naturally get composable
| components without lots of manual management and excess paints
| and reflows.
|
| It's certainly possible to build what 75% of websites actually
| need with this approach, but I wouldn't consider it for a
| moment for any UI that I actually consider to be complex.
| tinthedev wrote:
| It is far less productive for complex anything, not just UIs.
|
| The only way to do home-spun stuff in JS/TS is to narrow the
| use-cases and components down religiously. The moment you'll
| require more than 2-3 bits of the website to interconnect...
| take one long hard look at the future and avoid the headache
| of writing your own JS boilerplate.
|
| I love eschewing JS frameworks as much as the next man, but I
| also love my free time. Too much to waste it debugging
| problems coming from hundreds of different user stories and
| approaches. React's mature enough, as are most of the big
| libraries commonly leveraged on it.
| adamtaylor_13 wrote:
| I find it ironic that as JS/TS begins to pick up more and more
| steam (and market share) that I find myself loving Rails more and
| more each day.
|
| I have never felt as powerful or productive with JS (as much as I
| love it) as I have with Ruby on Rails.
|
| I've "almost built" countless projects that never actually
| shipped with Node. Whereas with Rails I have shipped so much I
| feel like I was cheated out of the first few years of my career
| not knowing Rails.
|
| All that to say. I love JS (and especially TS), but they've got
| to find their "Rails" before I can truly come all the way back.
|
| There's a few contenders (Redwood, Adonis), but none of them have
| been battle tested the way Rails has--yet!
| tinthedev wrote:
| I've found it especially useful, in recent years, to eschew a lot
| of JS and go back to the "stone age" so to say, when developing
| non-public components.
|
| I'd still not go without React (or something similar) to manage
| DOM in the user-land, but there's something blessed about using
| barely any to no JS at all in an admin/moderator UI, or in dev
| tooling. Don't have to consider any of the compatibility/update
| headaches outside of the user space.
|
| That rant aside, I feel that the best approach to JS is a static
| one. Build your code and your artifacts, package them long-
| term... serve them when needed and you're done. It's somewhat
| retro, SPA style, but it works like a charm and doesn't require
| building all the time, nor babying all the dependencies and build
| steps.
___________________________________________________________________
(page generated 2024-12-17 23:00 UTC)