61–70 of 170 posts
If you use normal includes instead of imports, and put an object (or better a closure) on the top as a namespace, your SPA will work with any browsers, and you don't force your users to throw out their phones and laptops every 2-5 years.
You could also just use a polyfill (es-module-shims) to add support for older browsers.
I don't really trust polyfill tho.
Earlier quoted context omitted.
I think that even extends over longer time periods to projects as a whole and an evolving team. Sticking to my current project which has a nearly 20 year legacy and looks nothing like what it was when it started: V1: Perl CGI, HTML forms, very little js V2: Perl CGI, JQuery, Ajax (done badly with js code generated by Perl code) V3: Perl backend rest API (will be "public"). TypeScript+Vue front end. Each time a transi…
Neat, is this a public project. You make me curious what it is that you are hacking away at!
I'm the first "product" person without a bioinformatics background to work on it. The new version isn't out, but is a significant rewrite with an aim to massively extend its functionality in future. (Current "public" version isn't even the current commercial version, and very 90s in style!)
Backend is a very large Perl codebase implementing a significant amount of algorithms from academic research.
It's been awesome to work on, my ideal sort of project where I can bring a technical product focus and learn about interesting technology and science at the same time.
Earlier quoted context omitted.
Neat, is this a public project. You make me curious what it is that you are hacking away at!
Avoiding Googleable backlinks, if you search for "integrated antibody sequence and structure tool" you will find it. I'm the first "product" person without a bioinformatics background to work on it. The new version isn't out, but is a significant rewrite with an aim to massively extend its functionality in future. (Current "public" version isn't even the current commercial version, and very 90s in style!) Backend is…
To go quite a bit off topic. The author says that he starts with a single html file and splits it or incrementally adds stuff when needed. That course of action has proven to be a really bad idea on every non trivial web project I worked on. Mostly for teamwork and maintainability reasons. E.g there is no clear project structure, the next dev will not understand stuff and do things differently. And welcome to the cha…
You are optimizing for entirely different use cases. There are a whole bunch of devs who work alone or in (very) small teams. For this type of work it’s really more of a hindrance to have an imposed structure and tooling. We want to get to your goals as efficiently as possible. Minimal abstractions, guidelines, tooling, indirection, magic, surprises and general overhead are in order. We don’t want to struggle with qu…
To go quite a bit off topic. The author says that he starts with a single html file and splits it or incrementally adds stuff when needed. That course of action has proven to be a really bad idea on every non trivial web project I worked on. Mostly for teamwork and maintainability reasons. E.g there is no clear project structure, the next dev will not understand stuff and do things differently. And welcome to the cha…
While I loathe files thousands of lines long, I also loathe the endless chasing of things from file to file that tends to be the result of applying big frameworks to tiny projects.
Import maps strike me as a huge win for making prototypes, or things where you control what exactly you're importing (eg from a private registry instead of NPM), but throwing out the bundler and more importantly the tree-shaking and minification steps of bundling, will result in a massive about of unused code being delivered to the user. You'll be relying on maintainers putting minified, unbloated assets in their pac…
On the same topic, I wrote some articles a while ago. Here is my own approach for making a VanillaJS SPA without using any bundlers or frameworks https://rishav-sharan.com/#/making-a-spa-in-vanilla-js Note that this blog right now converts markdown posts into html at runtime, which is definitely not an efficient way of doing things. But considering that I have just a handful of people landing there, I really haven't…
I wonder whether you could turn this into a static renderer by skipping the `after_render` as a separate step that only happens in the browser. You could even rename it `hydrate` if you want to use fancy modern JS lingo. The benefit would be to show content on initial page load without JS enabled as well as letting crawlers index your site (some still don't run JS).
I also sometimes enjoy this approach of starting from absolutely nothing. Instead of taking the path of starting with DOM manipulation and then going to a framework as necessary, I've kept really trying to make raw web components work, but kept finding that I wanted just a little bit more. I managed to get the more I wanted -- sensible template interpolation with event binding -- boiled down to a tag function in 481…
An even simpler bit of sugar over the DOM that I embed whenever I need just a little bit of JS: function $E(t,p,c) { const el=document.createElement(t) Object.assign(el,p) el.append(...c) return el } Usage: const button = $E('button', {onclick: () => alert('click!')}, [ $E('img', {src: '/assets/icon-lightbulb.png'}, []), 'Ding!', ]) (With thanks to 'goranmoomin: https://news.ycombinator.com/item?id=23590750 )
parent.append(
Hello
);(Mine has slightly more functionalities, such as allowing passing in styles as a object, auto concatenate array of strings for class names, etc.)
If you use normal includes instead of imports, and put an object (or better a closure) on the top as a namespace, your SPA will work with any browsers, and you don't force your users to throw out their phones and laptops every 2-5 years.
To go quite a bit off topic. The author says that he starts with a single html file and splits it or incrementally adds stuff when needed. That course of action has proven to be a really bad idea on every non trivial web project I worked on. Mostly for teamwork and maintainability reasons. E.g there is no clear project structure, the next dev will not understand stuff and do things differently. And welcome to the cha…
There is no clear project structure if you don't write down what the expected project structure is . Which you really need even with a framework, because the frameworks only provide really rough high level structure. While I loathe files thousands of lines long, I also loathe the endless chasing of things from file to file that tends to be the result of applying big frameworks to tiny projects.