151–160 of 176 posts
Earlier quoted context omitted.
I checked out before getting to that. He even wrote his own HTML variant called EHTML. https://e-html.org Well played. You got me to visit your version of the thing you complained about. :clapping-emoji:
It's not a html variant. It's just a bunch of web components. Takes like 30s of looking at actual source code to figure that out.
React was invented to make multiple DOM changes quicker and set up DOM event dependencies declaratively. Fine. Some websites benefit from this. Most do not. Since React's invention, it has gotten more bloated, browsers have made living DOM changes a lot faster, and the vast majority of websites still only change one or two DOM objects in response to events. Those could easily be handled much faster with plain old AJA…
Earlier quoted context omitted.
We don't need things taking control from us. Or dictating the terms for manipulating an already defined interface. If that means you have to make a small thing that is designed to do just the task at hand but to do it well, I am all for it. I think the only frameworks that I have encountered that I felt were worth using were server side things like express where they had a very specific task to do and could isolate a…
It's not terms, it's structure. You all seem to be fighting calculus and saying knowing addition and multiplication is enough. I'm reminded of friends refusing to learn chords on guitar and trying to invent their own musicality so they are not constrained by music theory.
Earlier quoted context omitted.
That presumption is wrong, and doesn't quite make sense if you think about it.
Why doesn't it make sense? I actually do exactly this in my own setup, but with golang instead of Node.
Earlier quoted context omitted.
Why doesn't it make sense? I actually do exactly this in my own setup, but with golang instead of Node.
I don't know what tooling you're using in go, but node does not do any kind of transformation to assets it serves over http. Running logic written in TypeScript on the front end requires some kind of bundler so that the browser can run the code.
1. Browser requests /js/foo.js
2. Server middleware checks if /js/foo.ts exists
3. If yes, server middleware strips types from the file before returning it
In golang I use the go package github.com/evanw/esbuild[1] to do type stripping on the fly. The middleware looks like this:
``` return esbuild.Transform(string(fileBytes), esbuild.TransformOptions{ Loader: esbuild.LoaderTS, Format: esbuild.FormatESModule, }) ```
It only takes a few microseconds and I don't need any bundlers or tsc or anything like that. Everything on my frontend is 100% vanilla TS; I make changes directly to TS and then hit refresh in my browser and the changes are reflected instantly without needing a bundler or even node/npm for that matter. Note: for this setup to work, your front end TS has to use ES modules import/export which browsers natively support. If you try to use CommonJS or something like that, you would start needing a bundler again because browsers can't resolve "require" statements.
In node it should be even easier than Go because Node added native type stripping starting with v22[2]
But even on older versions of Node, a type stripping middleware would still be very easy to implement[3][4].
[1] https://pkg.go.dev/github.com/evanw/esbuild
[2] https://nodejs.org/api/module.html#modulestriptypescripttype...
Earlier quoted context omitted.
I use WebSockets. If the user changes a value you have to send that changed value forward. If the value changes outside the UI you have to send it into the UI.
What does the binding look like in source code? Do we hand-code every UI field with the code that updates the local model and then transmits it to the backend? Or is there a way to make the boilerplate as small as possible, relying on one bit of code to handle synchronization between UI, local model, and server? “Using WebSockets” doesn’t bind an interface element to its source of truth; it’s just the chosen transpor…
It is as simple as I am suggesting, but only if you have actually done it yourself more than once. Whether or not your application is error prone is entirely on how you execute regardless of the tools in your toolbox.
Earlier quoted context omitted.
Again, I never said Node is did anything for the front end.
Again, yes you explicitly did: > I just write my code and then point node at the main file, and this even includes front-end code for the browser. It sounds like you're just making stuff up.
Earlier quoted context omitted.
I don't know what tooling you're using in go, but node does not do any kind of transformation to assets it serves over http. Running logic written in TypeScript on the front end requires some kind of bundler so that the browser can run the code.
You don't need a bundler, just a type stripper. And yeah you need a middleware to perform the type stripping, the server won't do it automatically, but it's like 10 lines of backend code. The basic flow would be something like: 1. Browser requests /js/foo.js 2. Server middleware checks if /js/foo.ts exists 3. If yes, server middleware strips types from the file before returning it In golang I use the go package githu…
And yet you're using one. Esbuild is one of the most popular bundlers in the js ecosystem, your workflow is functionally identical to any other bundler workflow except that the example you provided is worse than the typical workflow because it builds the ts file on every request rather than just once when the source code changes.
Earlier quoted context omitted.
Again, yes you explicitly did: > I just write my code and then point node at the main file, and this even includes front-end code for the browser. It sounds like you're just making stuff up.
If you hire me as a consultant I will do it for you at $150 per hour.
> I just write my code and then point node at the main file, and this even includes front-end code for the browser.
Then you said:
> I never said Node is did anything for the front end.
So which is it?
Earlier quoted context omitted.
You don't need a bundler, just a type stripper. And yeah you need a middleware to perform the type stripping, the server won't do it automatically, but it's like 10 lines of backend code. The basic flow would be something like: 1. Browser requests /js/foo.js 2. Server middleware checks if /js/foo.ts exists 3. If yes, server middleware strips types from the file before returning it In golang I use the go package githu…
> It only takes a few microseconds and I don't need any bundlers And yet you're using one. Esbuild is one of the most popular bundlers in the js ecosystem, your workflow is functionally identical to any other bundler workflow except that the example you provided is worse than the typical workflow because it builds the ts file on every request rather than just once when the source code changes.
I'm using a TS type stripper API from a go package inside the server. I'm not actually doing any "bundling" which implies resolving imports, tree shaking, combining multiple files into one, minification, uglification, etc. I'm strictly stripping out types and serving what's left directly to the browser. This costs less than 1ms of cpu time on a cold load (and usually costs nothing because of front-end caching/etags)
Look, I don't want to argue with you. Just sharing my setup. I develop medical device software which means dependencies are very expensive because they incur regulatory burden. SBOMs and associated CVEs have to be tracked and reported to the FDA. My TS/golang stack means:
- My docker images can be from scratch or from busybox with a statically linked go binary
- My frontend can be vanilla TS with zero dependencies (npm or otherwise)
- Debugging is dead simple: set breakpoints directly in dev tools and it's WYSIWYG (no map files needed, etc)
- Feedback is instantaneous. If I change a file in TS and hit refresh, the change is reflected instantly (compare to bloated Vue/React shops I've seen where every change requires a 10 second frontend compile pipeline to run before you can get feedback in the browser)