8 ms·
BYOJS (Bring your own JS)
- handfuloflight 2y ago> and also no disrespect for those who like JS-looking languages like TypeScript... Why this alienation?
- billyp-rva 2y agoThe author is Kyle Simpson of "You don't know JS" fame. He was, at least initially, very much against Typescript as a concept.
- meiraleal 2y agoIsn't alienation exactly what you are doing here? 9 out of 10 JS posts here are talk positively about typescript. Let the 1 of 10 talk freely, could you?
- handfuloflight 2y agoOdd way to respond to my question. No where was I espousing censorship.
- meiraleal 2y agoIt is not censorship for those who like JS-looking languages like TypeScript. The idea that focusing on JS is alienation is at least hilarious for someone that doesn't follow the typescript religion.
- handfuloflight 2y agoSo it's not alienation? What exactly are you arguing? Why are you arguing? How has TypeScript hurt you to this extent?
- meiraleal 2y agoalienation is to want that people should always choose TypeScript, which is what you were initially complaining in favor of, just because this specific post mention not using Typescript.
- handfuloflight 2y agoNo. That's your interpretation of what my post meant. I was not complaining about anything. Neither did I indicate anywhere that everyone should always choose Typescript. Typescript is obviously so related to Javascript that I wanted to understand more—technical reasons—why the author was excluding Typescript in such a way from any sort of treatment, even passing remarks that explains his stance. I may not have explicitly asked for a technical discussion, but this is Hacker News and I know better what my intentions and meanings are than you do. You're the one who brought the complaints, and made it into a religious dispute. Go into my comment history and find any discussions from me about Typescript or Javascript. You're superimposing a debate on me that I'm not part of. I did not know that debate was so omnipresent in the community that you deem it rational to extract such intent from my question, but I see that now. Perhaps I was not privy to such a debate because Typescript has so obviously won.
- meiraleal 2y ago> No. That's your interpretation of what my post meant. Ok, that's what I understood from your post. Sorry if I got you wrong. But the reason to exist of this thread is to talk about JavaScript, pure old JS. Unfortunately, the mention of TypeScript got more attention than anything else.
- hitekker 2y agoOff-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.
- meiraleal 2y agoThat's exactly what I'm doing too, after working with Lit for a few months (which is great) I felt that it would be easier to create a (even) smaller framework specific for my needs with only lit-html. I never been happier with Web Development in my life.
- nchmy 2y agois this framework publicly available anywhere? I've been thinking about making my own lit-html + honojs isomorphic "framework" and would love some inspiration.
- nchmy 2y agoI'm curious, if you're using lit-html, why not use LitElement as well if you're building web components?
- hitekker 2y agoI want to avoid another "not-a-framework" framework, like how React called itself "just a library" to semi-honestly offload the responsibility of state management. I don't know if LitElement is that, but I have some trauma. On a positive note, it's a joy to compose my own framework.
- nchmy 2y agoFair enough. For the record, I'm also planning to build my own very mini "framework" based on just lit-html. Is yours shared publicly anywhere? I'd love to check it out for inspiration.
- fidotron 2y agoHonestly, 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 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 2y agoI 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 2y agoThe 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 2y ago"build your own tools" is also known as "the ecosystem is lacking"
- leptons 2y agoOne 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.
- mplewis 2y agoThese 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 2y agoI'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 2y agoesbuild 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 2y agoprobably my biggest pure JS app is this one: https://github.com/bwasti/mebm https://github.com/bwasti/mebm you can try it here https://bwasti.github.io/mebm/ https://bwasti.github.io/mebm/
- newusertoday 2y agoexcellent app.
- threatofrain 2y agoMmm 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 2y agoI 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 2y agoeh... so far Typescript hasn't saved us from any bugs, but YMMV.
- methodical 2y agoDitto. If anything, trying to add it into an existing codebase via JSDoc has only really been a detriment via being a massive time sink. It might have caught maybe 4-5 bugs in the code but none that presented a large enough issue to warrant the time investment. If you're starting from scratch with TS instead of JSDoc, it might be worth it, but even on the best of days trying to figure out typing oddities from library typings being wrong and such have only really added headache. As always YMMV
- digging 2y agoEven if that's true (maybe your team is really careful about documentation and data structures even when they don't have types?) - the majority of the "bugs" TS catches are those that would be caught manually anyway, during development. It's just that instead of measuring those bugs in hours, they don't even exist to be measured.
- meiraleal 2y ago
- philippta 2y agoI‘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 2y agoI would feel cool doing this until any sizeable DOM manipulation and then immediately remember why react was such a godsend.
- fidotron 2y agoThe 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 2y agoI 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 2y agoFastComments 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 2y agoI 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 2y agoIt 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.
- winrid 2y agoI don't waste time doing that. Sounds like a skill issue :) React is on like version 18, you guys can keep getting paid to upgrade frontend libraries every year, I'll watch.
- adamtaylor_13 2y agoI 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!
- teaearlgraycold 2y agoFunny. I did a few years with Rails and won’t go back now that I use Typescript. I like the Rails and Ruby libraries. But I don’t like the Ruby language. You can always get better libraries for JS. But the languages are more or less fixed.
- adamtaylor_13 2y agoI would love better typesafety in Ruby, but really don’t like the Sorbet solution. However, interestingly I don’t find I need libraries that much with Rails, which is part of what I love. I started out hating the Ruby language but honestly I’ve begun to like it the more I use it.
- windowshopping 2y agoI keep trying rails because I love Ruby so much but I've never been able to build anything in it because I find it's so heavily skewed towards an old-fashioned "traditional" stack and I tend to build SPAs with an API. Rails can certainly do that, but its tutorials and guides don't promote it at all so it feels like you're going against the flow from the start trying to do something that they don't seem to want you to do. I wish that wasn't the case, because the language is beautiful and the framework seems quite cool. I always just end up using express instead...
- 2y ago
- tinthedev 2y agoI'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.
- draw_down 2y ago[dead]
- STRiDEX 2y agothere's existing libraries in this space that are quite good. not sure why you would use this instead. storage for example: https://github.com/unjs/unstorage https://github.com/unjs/unstorage vs byojs storage https://github.com/byojs/storage https://github.com/byojs/storage most users are going to prefer autocomplete and types regardless of if they also use typescript.
- harel 2y agoI really truly hope that one day optional types are introduced to the EcmaScript/JavaScript spec. My only reason for saying that, and I know it's the unpopular view, is that I actually LIKE JavaScript and think TypeScript is a mess of over complicated concepts, trying to do too much and feels sometimes it's in competition with itself for how verbose and complex it can be. So I'm hoping that the introduction of types to JavaScipt will be the same death spiral seen with the likes of CoffeeScript (remember that?).
- AtlasBarfed 2y agoOptional typing is one of my favorite features of groovy. Explicit typing also helps show where code needs to be explicitly performant and of course where type strictness is valuable. I'm assuming of course that types in js flavors has performance advantages a la asm.js, but admittedly I haven't tracked JavaScript evolution that closely. If it isn't typed then that helps clue the programmer that looser dynamic techniques being used.
- harel 2y agoI'm not arguing against types. I'm arguing against an extremely convoluted type system that is so complex it's practically a language on it's own. And it's sole existence is to make a dynamic language not dynamic.
- z3t4 2y agoBeing able to develop with instant feedback and without any tooling is pure joy. Just open a simple text editor and within minutes you have something up and running on your own computer without having to install anything. Then when you want to publish it you just upload it as is to a web server. And if you need to write a server all you need is a single program called NodeJS where you also get instant feedback and it comes with a standard library that lets you do just about anything. The only negative about vanilla JS is that writing async code is difficult, but no tooling can solve that problem. Try vanilla JS for one year and your productivity will go up one or two orders of magnitude, because development is now fun, fast and simple. Just don't write too big of a project because when you start to bring in tools its a slippery slope. And don't write your own tooling because its very addicting.
- meiraleal 2y ago> And don't write your own tooling because its very addicting. I plead guilty your honor
- miffy900 2y ago> "but it feels like a lost art to build effective web applications using the core JS language." Yeah it is getting lost, more and more lost each year - you know why? The core JS language is bad. Note how the author uses the word 'core' instead of what they really mean: 'subset'. Use a subset or a small portion of the language, because if you use the whole breadth of language features, you will litter your application with so many landmines that you will eventually scrap it and re-write due to how awful most of the 'features' in JS are. Even using a subset you have no choice to resort to syntactical verbosity to get around bad language design, like === over ==, or const & let over var. I wonder what the ultimate point of posts like these are; it's like someone trying to light a fire during a flood; and to what end? To pointlessly champion a bygone era of when people didn't know better? Let's be clear here, JS is popular because it is the only language shipped by default in browsers, since 1996. That's it; it's not popular because it's good; we're not using it in 2024 because it won out in a contest of merit. It's design phase was rushed and even its name betrays how stupidly conceived it was; 'JavaScript' - as if superficial association with an already trendy tech during the 90's was somehow enough to paper over it's obvious flaws as a language. Just laughable. Seriously, it's 2024, we know better now - use TypeScript. It's actually kind of amazing how Microsoft released TypeScript only in 2012 and not years earlier.
- AtlasBarfed 2y agoIt's the eternal infinite loop of " lightweight" replacing "heavyweight", then needing more features/support/testing/management/,tooling, becoming "heavyweight". To reacts credit, they started out heavyweight, but they knew it needed to be to address the problem in the manner they desired
- gcau 2y agoThis comes off as very naive and contrarian, and like the author just wanted a reason to create some more javascript libraries. The lack of types in your library makes it harder to use, more likely there will be bugs where its being used, and the library itself is probably buggy. The author commonly champions bad practices, that you should "just know" how js works and then none of this matters. There's very strong reasons a vast amount of people are switching to typescript. It can very easily compile to clean javascript, you can commit that to git, and you are much better off.
- deleted 2y ago[deleted]