161–170 of 170 posts
"Ideally, I’d just grab the framework files, import them from my JavaScript, and then carry on with my file:// URL."
Does this work with file:// URLs at all?
I see in the article that paths in import maps start with /. So, the author must be using a local server, otherwise browsers will block loading the modules by CORS policy. Is there something I'm not getting here?
Earlier quoted context omitted.
I’ve been doing web development for more nearly 25 years. It isn’t unmaintainable. How do you think we built large websites in the days before compiling/transpiling was a thing?
>How do you think we built large websites in the days before compiling/transpiling was a thing? You don't really compare web development 25 years ago and now, do you? Then the most complex front-end was having two forms. Also people wrote operating systems in ed but don't think one will even consider giving up their IDE/editor for ed because people could build complex software in past with that.
You have no clue what you're talking about. In the late nineties we had just about every bell and whistle working that I see in websites today, hardware limitations permitting. Some of it did not work well because client browsers were slow but it was all there: full interactivity through Java applets, VRML, media control API etc. Websites in the nineties were not two forms and a table tag. My masters project was embedding a voice recognition engine for interactive web search.
Yeah we didn't do SPAs and instead implemented interactivity locally. That was a good thing that you threw in the garbage for a fad.
Earlier quoted context omitted.
I don't mind those things. I do mind that they install 2000 packages, though.
> $ echo '{}' > package.json && npm i --save-dev typescript vite preact > added 17 packages, and audited 18 packages in 1s You're off by two orders of magnitude. I get not wanting a lot of transitive dependencies, but you can get a modern toolchain without having a lot of transitive dependencies.
> echo '{}' > package.json && npm i --save-dev typescript esbuild preact
> added 4 packages, and audited 5 packages in 2s
Earlier quoted context omitted.
>How do you think we built large websites in the days before compiling/transpiling was a thing? You don't really compare web development 25 years ago and now, do you? Then the most complex front-end was having two forms. Also people wrote operating systems in ed but don't think one will even consider giving up their IDE/editor for ed because people could build complex software in past with that.
> Then the most complex front-end was having two forms You have no clue what you're talking about. In the late nineties we had just about every bell and whistle working that I see in websites today, hardware limitations permitting. Some of it did not work well because client browsers were slow but it was all there: full interactivity through Java applets, VRML, media control API etc. Websites in the nineties were not…
If anything, I think it's remarkable how far we've graduated from that point: many features components and features that we used to have to build by hand are now directly implemented in the browser; Javascript is significantly easier and nicer to use, even without having to apply a build step (even just splitting scripts into separate modules is now supported natively!); and features that previously required potentially insecure plugins to be enabled are now controlled by the browser, giving users much more ability to control what their browser is doing or not doing. Even if you do want more complex development with build steps, with tools like Parcel and Vite, that's usually pretty simple at this point (certainly simpler than the last few Java builds that I've seen).
It seems like you're complaining that everything is worse now because it's possible to have stupid amounts of complexity these days, but it's also a lot easier to have no complexity at all.
Earlier quoted context omitted.
>How do you think we built large websites in the days before compiling/transpiling was a thing? You don't really compare web development 25 years ago and now, do you? Then the most complex front-end was having two forms. Also people wrote operating systems in ed but don't think one will even consider giving up their IDE/editor for ed because people could build complex software in past with that.
> Then the most complex front-end was having two forms You have no clue what you're talking about. In the late nineties we had just about every bell and whistle working that I see in websites today, hardware limitations permitting. Some of it did not work well because client browsers were slow but it was all there: full interactivity through Java applets, VRML, media control API etc. Websites in the nineties were not…
Not sure we're even on the same page if your argument on "sites were as complex back in the good old days" is embedding a literally distinct program on site, which quite ironically also happens to include its own complicated tooling and building.
>instead implemented interactivity locally
Umm, what you think SPAs are?
Sigh... Another post like this. Sure, it works well enough for the example shown in the article, but won't work well beyond this. Bundlers, package managers and other tools were created to address problems people saw in medium-large projects for websites with a lot of traffic. And as soon as the project has dozens of files and even just two or three external libraries, this becomes unmaintainable. Not to mention mini…
"Sure, it works well enough for the example shown in the article, but won't work well beyond this." Sigh...the entire bloody point of the author is to use this for light projects, to scale the sophistication of the setup gracefully. With very obvious benefits: easy to understand, not linked to any setup so it works forever, interoperable and transferable. Typescript isn't universally important for development. It has…
Earlier quoted context omitted.
JSX suffers from the same problem that early PHP did. Because you have the full power of JS at your hands, you need some very good linting rules if you don't want to end up with a mess combining presentation and functionality. By having a hard split between the two you're forced to build declarative templates. Most React projects I've jumped into are really hard to understand regarding which template elements come fr…
JSX is quite a bit better than early PHP, but yeah, it has the same issue. I like both JSX and Vue templates, though (I prefer JSX with Vue or Preact). I think JSX and Vue templates both are discovered, not invented, and have staying power because of that. JSX is neat because it is a really simple hybrid of two languages and is fully composable. Vue templates are neat because unlike so many other HTML templating lang…
In a way JSX feels like GOTO statements.
Earlier quoted context omitted.
Man I cannot wait for compilers and linkers and all that garbage to go the way of the dodo bird.
You don’t, and never did, need compilers and linkers for JavaScript. There’s even “script” right in the name.
Earlier quoted context omitted.
I don't mind those things. I do mind that they install 2000 packages, though.
> $ echo '{}' > package.json && npm i --save-dev typescript vite preact > added 17 packages, and audited 18 packages in 1s You're off by two orders of magnitude. I get not wanting a lot of transitive dependencies, but you can get a modern toolchain without having a lot of transitive dependencies.
I'll probably try it out some time for a home project, but for anything serious it's a no go.
Earlier quoted context omitted.
I think a lot of Babel is for people who haven't kept up with caniuse statistics and don't realize that the "low water mark", the "well supported baseline", has moved to something very close to ES2021 or more recent. To be fair, Babel is explicitly targeting some of those developers that prefer ignorance and don't want the mental overhead of actually knowing what browsers support and like having "just use the presets…
Es6 arrow functions are a good example of this. They have been around for a long time and work in most browsers, but people learned they need babel to transpile them out for internet Explorer. People dropped ie support but the knowledge "we need babel for browser compatibility " remained an entrenched fact.