Maybe I'm too old now, but putting "vanilla" web and "javascript" in the same package they're trying to sell you on is weird to me. My view of a "vanilla" web would be free of javascript entirely.
Maybe I'm too old now, but putting "vanilla" web and "javascript" in the same package they're trying to sell you on is weird to me. My view of a "vanilla" web would be free of javascript entirely.
Vanilla has been used to describe JavaScript without frameworks for a pretty long time. At least since jQuery was released. For example, this satirical website promotes the "vanilla framework",...
Vanilla has been used to describe JavaScript without frameworks for a pretty long time. At least since jQuery was released. For example, this satirical website promotes the "vanilla framework", which is actually just the standard library. Nowadays it's mostly used to distinguish from component-based frameworks like React or Svelte.
I dislike that this site encourages development with plain web components, partly because sites made with them require Javascript to use. Regular web components don't support server-side rendering...
I dislike that this site encourages development with plain web components, partly because sites made with them require Javascript to use. Regular web components don't support server-side rendering into plain HTML. (Also plain web components require more tricky boilerplate to write than components in React or other frameworks, including web-component-based frameworks.)
Websites made with React don't necessarily require Javascript in the browser to use, because React supports server-side rendering. When React is used with server-side rendering (as many React-based frameworks like Next.js do by default), the server renders all the components into plain viewable HTML, sends that to the client, and then the server sends the javascript that allows the components to become mounted and fully interactive on the client. Browsers with javascript disabled will ignore that last part and still be able to see the initial render of all the components, which is enough for many mostly-static sites.
I think it's useful to understand the browser APIs directly as the "vanilla JS" movement encourages, but the way it's treated as an obvious truism that it's actually better (for users or for developers) to stay vanilla than to use a framework is bad.
That pattern of rendering on the server and “activating” on the client is a good one and should be more popular. Is it strongly tied to React (and thus, JavaScript) specifically or has choice in...
That pattern of rendering on the server and “activating” on the client is a good one and should be more popular. Is it strongly tied to React (and thus, JavaScript) specifically or has choice in language and framework opened up?
Many modern frameworks have been inspired by React and work similarly (Vue, Svelte), though they're all using Javascript/Typescript. I wouldn't hold my breath waiting for good frontend/full-stack...
Many modern frameworks have been inspired by React and work similarly (Vue, Svelte), though they're all using Javascript/Typescript. I wouldn't hold my breath waiting for good frontend/full-stack frameworks that don't use JS/TS. There are some projects working on that type of thing, but my experience with experimenting with non-JS/TS languages in browsers has been painful usually with awkward interop to native browser APIs, lack of automatic rebuilding, lack of debugger support, and lack of third-party packages that work in the browser.
Typescript is one of my favorite languages even outside of the browser, so I recommend giving it a try. Most browser frameworks (including React-based ones like Next.js) have official starter kits using Typescript and work out of the box with Visual Studio Code.
I did front end work back in the day. It was at a job where you did it all, soup to nuts, database to HTML. I've been learning React on the job for the past few months. First front end work I've...
I did front end work back in the day. It was at a job where you did it all, soup to nuts, database to HTML.
I've been learning React on the job for the past few months. First front end work I've done in 15 years. React is a lot more fun than the kind of front end work described in the title. It feels like programming. I'm also amazed at all of the work I have to do to get a simple screen. I can see these frameworks going out of style someday if what is rational prevails.
Was also bad about keeping the single core most computers had back then maxed out. For those of us with higher resolution displays (like the 1680x1050 20" iMac G5 I had), flash-based sites were...
Was also bad about keeping the single core most computers had back then maxed out. For those of us with higher resolution displays (like the 1680x1050 20" iMac G5 I had), flash-based sites were also annoying because they'd usually be sized at 800x600 or so and couldn't reflow, making using those sites feel a bit like peering through a keyhole.
The irony is that Flash uses vector art, so it resizes to whatever you decide it to be. The people who set up the websites just set it up for a fixed size.
The irony is that Flash uses vector art, so it resizes to whatever you decide it to be. The people who set up the websites just set it up for a fixed size.
This is true, but wouldn't have improved the situation a whole lot since setting the embed to scale to fit the page would've just scaled up the Flash file with a multiplier, making its content...
This is true, but wouldn't have improved the situation a whole lot since setting the embed to scale to fit the page would've just scaled up the Flash file with a multiplier, making its content comically huge on high resolution displays, kind of like running a phone app on a tablet today. What Flash really needed for this use case is reflowability, so increasing the size of the embed also increases the surface area within the Flash file while keeping contained elements rendering at their original scale. Kind of like the difference between an ePub and a PDF file.
This one of the reasons I love BearBlog, I spent some time looking into migrating my Wordpress blog to a static site powered by Hugo and automating the deploy to my NearlyFreeSpeech account when I...
This one of the reasons I love BearBlog, I spent some time looking into migrating my Wordpress blog to a static site powered by Hugo and automating the deploy to my NearlyFreeSpeech account when I stumbled across BearBlog.
The time saved was definitely worth the relatively inexpensive lifetime subscription.
Maybe I'm too old now, but putting "vanilla" web and "javascript" in the same package they're trying to sell you on is weird to me. My view of a "vanilla" web would be free of javascript entirely.
Vanilla has been used to describe JavaScript without frameworks for a pretty long time. At least since jQuery was released. For example, this satirical website promotes the "vanilla framework", which is actually just the standard library. Nowadays it's mostly used to distinguish from component-based frameworks like React or Svelte.
Ah, that's fair. Thanks for the education!
I dislike that this site encourages development with plain web components, partly because sites made with them require Javascript to use. Regular web components don't support server-side rendering into plain HTML. (Also plain web components require more tricky boilerplate to write than components in React or other frameworks, including web-component-based frameworks.)
Websites made with React don't necessarily require Javascript in the browser to use, because React supports server-side rendering. When React is used with server-side rendering (as many React-based frameworks like Next.js do by default), the server renders all the components into plain viewable HTML, sends that to the client, and then the server sends the javascript that allows the components to become mounted and fully interactive on the client. Browsers with javascript disabled will ignore that last part and still be able to see the initial render of all the components, which is enough for many mostly-static sites.
I think it's useful to understand the browser APIs directly as the "vanilla JS" movement encourages, but the way it's treated as an obvious truism that it's actually better (for users or for developers) to stay vanilla than to use a framework is bad.
That pattern of rendering on the server and “activating” on the client is a good one and should be more popular. Is it strongly tied to React (and thus, JavaScript) specifically or has choice in language and framework opened up?
Many modern frameworks have been inspired by React and work similarly (Vue, Svelte), though they're all using Javascript/Typescript. I wouldn't hold my breath waiting for good frontend/full-stack frameworks that don't use JS/TS. There are some projects working on that type of thing, but my experience with experimenting with non-JS/TS languages in browsers has been painful usually with awkward interop to native browser APIs, lack of automatic rebuilding, lack of debugger support, and lack of third-party packages that work in the browser.
Typescript is one of my favorite languages even outside of the browser, so I recommend giving it a try. Most browser frameworks (including React-based ones like Next.js) have official starter kits using Typescript and work out of the box with Visual Studio Code.
I did front end work back in the day. It was at a job where you did it all, soup to nuts, database to HTML.
I've been learning React on the job for the past few months. First front end work I've done in 15 years. React is a lot more fun than the kind of front end work described in the title. It feels like programming. I'm also amazed at all of the work I have to do to get a simple screen. I can see these frameworks going out of style someday if what is rational prevails.
I'll enjoy it while it lasts.
Internet development has become a roulette of "pick a framework".
If you bet wrong, it ain't pretty for long and you're back to the drawing board.
Back in my day, if you wanted interactive web components, Adobe Flash was all you needed. And we liked it! We loved it!
Edit: reference
No, we fucking did not!
Though it was still better than java applets.
As a user I hated how flash was always the thing that crashed my browser.
Was also bad about keeping the single core most computers had back then maxed out. For those of us with higher resolution displays (like the 1680x1050 20" iMac G5 I had), flash-based sites were also annoying because they'd usually be sized at 800x600 or so and couldn't reflow, making using those sites feel a bit like peering through a keyhole.
The irony is that Flash uses vector art, so it resizes to whatever you decide it to be. The people who set up the websites just set it up for a fixed size.
This is true, but wouldn't have improved the situation a whole lot since setting the embed to scale to fit the page would've just scaled up the Flash file with a multiplier, making its content comically huge on high resolution displays, kind of like running a phone app on a tablet today. What Flash really needed for this use case is reflowability, so increasing the size of the embed also increases the surface area within the Flash file while keeping contained elements rendering at their original scale. Kind of like the difference between an ePub and a PDF file.
No way. It was terrible.
Better than java and embedded videos with ugly ass players, but still terrible.
My 280kb 30 second Backburner Forums flv intro agrees. It was a shit time for media on the internet.
This one of the reasons I love BearBlog, I spent some time looking into migrating my Wordpress blog to a static site powered by Hugo and automating the deploy to my NearlyFreeSpeech account when I stumbled across BearBlog.
The time saved was definitely worth the relatively inexpensive lifetime subscription.