4 ms·

> except you can write code like it's not the old days. I imagine you mean that writing (frontend) code now a days is better than how it was in the old days. W

> except you can write code like it's not the old days. I imagine you mean that writing (frontend) code now a days is better than how it was in the old days. Well, at least from my perspective that's not the case. "Modern" frontend code requires: - a package manager (npm) - node (or deno or whatever) - transpilers (or is it plugins?) - TS - 10K+ dependencies And to be honest, what is all that good for? To being able to "hydrate" some server-side rendered template? Not good enough reason.

5e92cb50239222b 4y ago
We've been able to replace a couple of client applications that previously used WPF with a React frontend (and a small native application that uses WebSockets to create a bridge between the browser and a particular piece of local hardware). Updates are now easy-breezy (update the server and you don't have to touch clients at all). There is a place for SPAs. I just don't think your typical grocery store website should use something like that.
- solardev 4y ago
  What SHOULD grocery store websites use, then? I feel like they're some of the most complex websites around (if they do any ecommerce/online pickups at all)... between product reviews, indexing, filtering, sorting, checkouts, SMS/push notifications, geolocation, real-time inventory, etc. It's not the sort of site that says "easily built in plain HTML" to me.
madeofpalk 4y ago
If you think it's bad then why do you use it? Browsers still support just HTML. You can shove a just a script tag down in the page. Eventually, you'll have enough devs working on this you'll start to run into issues with how you coordinate your work. Your site becomes large enough the code gets more complicated and needs organising to work on it without slowing you down. You'll start to reinvent the above tools to solve these problems. Frontend/JS tooling isn't perfect, but don't pretend like other languages/systems (can) have a complex pipeline of build tooling.
- jhgb 4y ago
  > If you think it's bad then why do you use it? I didn't see GP make the claim of using it?
- mattkenefick 4y ago
  Taking it a little personal, eh?
ratww 4y ago
> "Modern" frontend code requires: Not necessarily, at least in the case of React and Vue. Rather than using NPM, you can self-host react/vue (or preact if you need something even smaller), or serve it from Unpkg. You don't need node/transpiler/bundlers if you're only targeting modern browsers. You can use modern syntax, async/await, ES6 import and a bunch of other features with static .js files. JSX is a tough one, but there are solutions to that, packages domz and HTM are made to allow using React/Preact without NPM/transpilers. Typescript is also a tough one. But it's also optional, although a good idea to have. I hope optional type annotations land in ES6 soon so typechecking can happen without anything resembling compiler phase. - > To being able to "hydrate" some server-side rendered template? Not good enough reason. The "hydrating" parts is entirely optional in "modern frontend". It also needs some stuff on the server that is IMO significantly more complex than what I described above. But apart from some very specific cases, one don't necessarily need it.
solardev 4y ago
Believe me, I hate the toolchain/buildchain as much as anyone. Especially TypeScript (see below). Luckily, Next.js also takes care of all that too! Out of the box it preconfigures all of it with sane defaults. `npm start` and you have a working server with transpilers all seamlessly configured, and when you change a line of code it just hot refreshes in the browser. On a `git push` to Vercel or a similar capably platform, the server transparently does all that and gives you a sandboxed preview environment for that specific build. It is magical. But really, what I meant about "writing code not like the old days" isn't so much about the shitty toolchain (which Next helps with, but I agree it's shitty). Rather, it's the ability to write code like: <Header loggedIn={isLoggedIn}/> <Sidebar options={isLoggedIn ? navOptions.loggedIn : navOptions.loggedOut} <Dashboard> {widgets ? widgets.map(widget => <WidgetContainer>{widget}</WidgetContainer) : <Spinner/>} </Dashboard> Basically, the ability to compose pages & apps out of components (which different developers can work on), and the ability to manage state in a central controller via Redux or useContext to avoid race conditions and the such. That sort of stuff is REALLY hard to do with plain HTML and JS, especially where there are multiple developers involved. React isn't a magical cure-all, it just makes it easy to componentize large apps into smaller areas of concern. The shitty buildchain isn't a feature, it's an unfortunate side effect of browsers being limited to JS. Essentially it's a "compile" step that became necessary as the vanilla-JS developer experience wasn't able to keep pace with the complexity of desired business apps (and as devs of various skill levels flooded the market). So the developer tools kept growing, but they still had to be compiled/built into JS for the browsers. Next.js makes it relatively painless, compared to how it was just 3-4 years ago. But I agree, I hate that this is a step at all. Ugh, as for TypeScript... I get that it's a necessary evil, but I spend more time fighting it than actual bugs... coming from PHP, it was already common practice to manually typecheck and coerce everything when needed, anyway. TypeScript often felt redundant and overly sensitive, especially when it came to async nullables, causing false alarms that React could just've silently handled with {isLoaded ? <Component/> : <Spinner/>} But TypeScript is optional anyway. It's a superset/addon on top of JS, so you never have to use it if you don't want to. If it's scaffolded for you in someone else's project, usually it's just a matter of a either using a .JS extension instead of .TS, or adding a ts-nocheck or similar to that file. Other devs may hate you for that though, when your object or props ends up breaking theirs... so it's definitely a conversation worth having first :)
kennywinker 4y ago
I recently wrote a small web app. I started with https://alpinejs.dev/ https://alpinejs.dev/ linked via CDN, and OpenJSCAD, also linked via CDN - I wrote basic html, marked it up with alpine `x-model` and `x-data` tags, and sprinkled a little vanilla js on top. Everything worked well and I got 80% of the way through the project. In the final 20% I ended up adding a bundler (parcel), so I could bring in an scss framework and override its variables. While it added a fair bit of complexity to the project (dev dependencies, parcel config files) I gained lighter files via parcel's tree-shaking and minification, auto-recompilation/reload during development, and re-usable html partials via `posthtml-include`. I'm also set up to swap to typescript quickly, if the project gets more complex and I start to get annoyed with the lack of compile-time type checking. So, it's 2022, and you can write a web app without any of the things you mentioned (transpilers, package managers, typescript). Yes, adding even one of them nets you a 100+ dependency node_modules directory - but the reason we keep adding them to our projects is the things it gives us are NICE, and the cost (complexity) is mostly worth it.
- hunterb123 4y ago
  You made a web site that displays a document. Not a web app. Web apps, like native apps, have a lot more UI state that needs certain patterns and tech to manage them properly. Many devs can discern the difference and use the correct tools. Some do reach for the wrong tool but it's not the tools fault.
  - kennywinker 4y ago
    I actually am aware of the difference between a web app and a document, and I used the correct word. Thanks

5e92cb50239222b 4y ago

We've been able to replace a couple of client applications that previously used WPF with a React frontend (and a small native application that uses WebSockets to create a bridge between the browser and a particular piece of local hardware). Updates are now easy-breezy (update the server and you don't have to touch clients at all). There is a place for SPAs. I just don't think your typical grocery store website should use something like that.

solardev 4y ago
What SHOULD grocery store websites use, then? I feel like they're some of the most complex websites around (if they do any ecommerce/online pickups at all)... between product reviews, indexing, filtering, sorting, checkouts, SMS/push notifications, geolocation, real-time inventory, etc. It's not the sort of site that says "easily built in plain HTML" to me.

madeofpalk 4y ago

If you think it's bad then why do you use it? Browsers still support just HTML. You can shove a just a script tag down in the page. Eventually, you'll have enough devs working on this you'll start to run into issues with how you coordinate your work. Your site becomes large enough the code gets more complicated and needs organising to work on it without slowing you down. You'll start to reinvent the above tools to solve these problems. Frontend/JS tooling isn't perfect, but don't pretend like other languages/systems (can) have a complex pipeline of build tooling.

jhgb 4y ago
> If you think it's bad then why do you use it? I didn't see GP make the claim of using it?
mattkenefick 4y ago
Taking it a little personal, eh?

ratww 4y ago

> "Modern" frontend code requires: Not necessarily, at least in the case of React and Vue. Rather than using NPM, you can self-host react/vue (or preact if you need something even smaller), or serve it from Unpkg. You don't need node/transpiler/bundlers if you're only targeting modern browsers. You can use modern syntax, async/await, ES6 import and a bunch of other features with static .js files. JSX is a tough one, but there are solutions to that, packages domz and HTM are made to allow using React/Preact without NPM/transpilers. Typescript is also a tough one. But it's also optional, although a good idea to have. I hope optional type annotations land in ES6 soon so typechecking can happen without anything resembling compiler phase. - > To being able to "hydrate" some server-side rendered template? Not good enough reason. The "hydrating" parts is entirely optional in "modern frontend". It also needs some stuff on the server that is IMO significantly more complex than what I described above. But apart from some very specific cases, one don't necessarily need it.

solardev 4y ago

Believe me, I hate the toolchain/buildchain as much as anyone. Especially TypeScript (see below). Luckily, Next.js also takes care of all that too! Out of the box it preconfigures all of it with sane defaults. `npm start` and you have a working server with transpilers all seamlessly configured, and when you change a line of code it just hot refreshes in the browser. On a `git push` to Vercel or a similar capably platform, the server transparently does all that and gives you a sandboxed preview environment for that specific build. It is magical. But really, what I meant about "writing code not like the old days" isn't so much about the shitty toolchain (which Next helps with, but I agree it's shitty). Rather, it's the ability to write code like: <Header loggedIn={isLoggedIn}/> <Sidebar options={isLoggedIn ? navOptions.loggedIn : navOptions.loggedOut} <Dashboard> {widgets ? widgets.map(widget => <WidgetContainer>{widget}</WidgetContainer) : <Spinner/>} </Dashboard> Basically, the ability to compose pages & apps out of components (which different developers can work on), and the ability to manage state in a central controller via Redux or useContext to avoid race conditions and the such. That sort of stuff is REALLY hard to do with plain HTML and JS, especially where there are multiple developers involved. React isn't a magical cure-all, it just makes it easy to componentize large apps into smaller areas of concern. The shitty buildchain isn't a feature, it's an unfortunate side effect of browsers being limited to JS. Essentially it's a "compile" step that became necessary as the vanilla-JS developer experience wasn't able to keep pace with the complexity of desired business apps (and as devs of various skill levels flooded the market). So the developer tools kept growing, but they still had to be compiled/built into JS for the browsers. Next.js makes it relatively painless, compared to how it was just 3-4 years ago. But I agree, I hate that this is a step at all. Ugh, as for TypeScript... I get that it's a necessary evil, but I spend more time fighting it than actual bugs... coming from PHP, it was already common practice to manually typecheck and coerce everything when needed, anyway. TypeScript often felt redundant and overly sensitive, especially when it came to async nullables, causing false alarms that React could just've silently handled with {isLoaded ? <Component/> : <Spinner/>} But TypeScript is optional anyway. It's a superset/addon on top of JS, so you never have to use it if you don't want to. If it's scaffolded for you in someone else's project, usually it's just a matter of a either using a .JS extension instead of .TS, or adding a ts-nocheck or similar to that file. Other devs may hate you for that though, when your object or props ends up breaking theirs... so it's definitely a conversation worth having first :)

kennywinker 4y ago

I recently wrote a small web app. I started with https://alpinejs.dev/ https://alpinejs.dev/ linked via CDN, and OpenJSCAD, also linked via CDN - I wrote basic html, marked it up with alpine `x-model` and `x-data` tags, and sprinkled a little vanilla js on top. Everything worked well and I got 80% of the way through the project. In the final 20% I ended up adding a bundler (parcel), so I could bring in an scss framework and override its variables. While it added a fair bit of complexity to the project (dev dependencies, parcel config files) I gained lighter files via parcel's tree-shaking and minification, auto-recompilation/reload during development, and re-usable html partials via `posthtml-include`. I'm also set up to swap to typescript quickly, if the project gets more complex and I start to get annoyed with the lack of compile-time type checking. So, it's 2022, and you can write a web app without any of the things you mentioned (transpilers, package managers, typescript). Yes, adding even one of them nets you a 100+ dependency node_modules directory - but the reason we keep adding them to our projects is the things it gives us are NICE, and the cost (complexity) is mostly worth it.

hunterb123 4y ago
You made a web site that displays a document. Not a web app. Web apps, like native apps, have a lot more UI state that needs certain patterns and tech to manage them properly. Many devs can discern the difference and use the correct tools. Some do reach for the wrong tool but it's not the tools fault.
- kennywinker 4y ago
  I actually am aware of the difference between a web app and a document, and I used the correct word. Thanks