Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things that used to be hard and are now easy

jvns.ca

Post reply on HN
Print view View original

211–220 of 316 posts

Re: Things that used to be hard and are now easy

#211

Post by nicoburns »

earthboundkid wrote: post #207
freedomben wrote: post #183

Earlier quoted context omitted.

Oh man, this brings back nightmares of upgrading jQuery, and third party components that were copy/pasted into the codebase and modified/customized. Large frontend codebases are indeed miles ahead of where they used to be.

The step backwards is that before, you couldn’t upgrade jQuery because the CDN script tag was on thirteen different partials, and you weren’t sure which were still in use, and now you can’t upgrade React because it depends on v4.3.2 of chalk-babel-duster-pack-plugin and that’s insecure but it has a breaking change in v5 you don’t know how to fix, so you’re just waiting for a total rewrite of the app to pull out CRA a…

Or you can avoid CRA in the first place. CRA is frankly a hot mess. But React itself, and for the most part even Webpack are quite reasonable.

Re: Things that used to be hard and are now easy

#212

Post by nicoburns »

reidjs wrote: post #7

As someone who leans frontend, I find firebase and serverless (somebody else’s server) solutions really powerful for prototyping an idea or building a proof of concept. You can get something in front of your users tomorrow. I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play (aerospace, hardware, etc) or already have a ton of market knowledg…

I would recommend learning backend (which is much easier than frontend!). If you have basic backend skills then you can do the frontend and the backend just as easily, and it gives you a lot more flexibility going forwards.

Re: Things that used to be hard and are now easy

#213

Post by mmcnl »

learc83 wrote: post #175
reidjs wrote: post #7

As someone who leans frontend, I find firebase and serverless (somebody else’s server) solutions really powerful for prototyping an idea or building a proof of concept. You can get something in front of your users tomorrow. I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play (aerospace, hardware, etc) or already have a ton of market knowledg…

> As someone who leans frontend > I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play Do you not see the problem with these 2 statements. Of course not dealing with non JavaScript is easier for a JavaScript developer. > You can get something in front of your users tomorrow. This is something we’ve been able to do with Rails or Django for nea…

The logical conclusion would be that you need more frontend than backend when you're trying to scale from 0 to 1.

Re: Things that used to be hard and are now easy

#214

Post by nicoburns »

madmax96 wrote: post #204
reidjs wrote: post #7

As someone who leans frontend, I find firebase and serverless (somebody else’s server) solutions really powerful for prototyping an idea or building a proof of concept. You can get something in front of your users tomorrow. I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play (aerospace, hardware, etc) or already have a ton of market knowledg…

+1 on Firebase. I recently helped a buddy build an app and decided to give it a try. Holy crap. All we had to was build the app! significantly faster than either of us estimated.

Be careful with this, especially with mobile apps that can't be easily updated. Using Firebase has a tendency to put what would otherwise be backend logic into the frontend, which can make it much harder to make changes quickly once your app has users.

Re: Things that used to be hard and are now easy

#215

Post by mmcnl »

smoe wrote: post #118
reidjs wrote: post #7

As someone who leans frontend, I find firebase and serverless (somebody else’s server) solutions really powerful for prototyping an idea or building a proof of concept. You can get something in front of your users tomorrow. I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play (aerospace, hardware, etc) or already have a ton of market knowledg…

Agree with starting focusing on UI first. But haven’t seen a speed advantage at this stage of serverless vs a simple monolithic backend app with a bunch of endpoints. You can get something in front of users within hours. Either way allows you to overengineer and focus on the wrong thing.

Agreed, I can get something up and running using Express or FastAPI (frontend + backend) easily in a few hours, whereas Firebase would be new to me. Use whatever you know/can to get something in front of the user.

Re: Things that used to be hard and are now easy

#216

Post by mwcampbell »

taeric wrote: post #209
mwcampbell wrote: post #169

Earlier quoted context omitted.

Considering that I've developed a screen reader from the ground up, worked on the Narrator screen reader shipped with Windows, and routinely used screen readers to browse the web for almost 20 years, I think I know a thing or two about this. So, it's true that screen readers have heuristics for detecting layout tables. But those heuristics aren't perfect. They're not even that sophisticated, at least the ones that I…

This feels inline with what I intended. Used sparingly, tables probably weren't that atrocious to figure out. Similarly, deliberate use of semantic tags is likely better. I question if things are deliberate are much better now. But, you provide a convincing and authoritative answer there. Html email feels like a trap. They are about turning up the volume and getting returns. Not about being accessible. Is that not th…

About HTML email, I think it's different in a work context. When I was at Microsoft, some official messages, that were actually important to read, were laid out in the style of an HTML marketing email, complete with heavy abuse of layout tables. Ditto for automated notifications, e.g. about bugs or PRs.

Re: Things that used to be hard and are now easy

#217

Post by iforgotpassword »

sdoering wrote: post #160
Tijdreiziger wrote: post #129

Earlier quoted context omitted.

> One needs an imprint and data privacy page. Really? I have a small personal website with no tracking; I guess my hosting provider collects server logs, but do I really need a privacy page for that? An imprint is something I've only seen on German websites (I recall reading somewhere that those are required by law there).

In Germany every site that collects, stores and/or processes personal data (PD) is required to have a data privacy explanation that is easily reachable from every page and explains to the user what data is being received, stored, processed and also explain the user's rights (for example the right to be informed, to correct data and so on). At first glance, a "private" page does not directly process personal data and…

What if I run something like a good old phpbb just as a hobby. What would I put on that privacy page? You enter your email address on sign-up. It's visible in your profile. You get notifications to it if you subscribe to topics. Isn't it kinda obvious it is stored? What if phpbb logs IP addresses for every post? I know it did in the past and don't remember there being an option to have that purged after a given amount of time. Can I do that? Do I need to put an imprint on the page, or is a contact form enough? Maybe I don't wanna put my name and address openly on the web. So I guess I'm just way to afraid to host a forum in Germany for my local sports club, because I don't wanna get hassled by lawyers who made this their business model. Better open a Facebook group, this is certainly much more privacy friendly.

Re: Things that used to be hard and are now easy

#218

Post by jbpnoy6fifty »

I would also agree to this in MANY fronts, not just software. As a kid I dreamt of building a robot at ~6 years old. Just this past weekend, I helped my God-son build one (a solar kit for kids) and it was on sale for $10.

Things are generally more affordable now than they used to be for the masses, and more easier to achieve and prototype, in less turn around time, with 1 day shipping, or the mall-ification of society.

Cool stuff really.

Re: Things that used to be hard and are now easy

#219

Post by mwcampbell »

fiddlerwoaroof wrote: post #197
ChrisMarshallNY wrote: post #165

Writing GUI apps for Apple products. Too many variables to mention, but I wrote my first Apple application in 1986. It took several weeks, and wasn't much to look at. These days, I can spin out a full-fat, shippable app, in a couple of hours. I do that all the time, for my test harnesses.

I used to do this on Windows in the 90s with Delphi: this is only really remarkable because we lost all the good tools somewhere along the way.

Languages that are good at arbitrarily composing many modules into a stand-alone executable are becoming more popular. Rust is my favorite; one can even package wrappers over C or C++ libraries in a way that fits seamlessly into the cargo build process. Go is good here as well, as long as you stick to pure Go. As soon as you introduce cgo, that adds a hurdle for any user of the library, particularly on Windows. Zig looks like it's on the right track, though we still have to wait and see what the package manager will look like. And I'm sure there are others.

We also don't know yet if any of these languages will develop strong ecosystems for rapid GUI development.

And of course, Lazarus (for Free Pascal) is still a thing, though it doesn't have hype, or more importantly, large mindshare.

Re: Things that used to be hard and are now easy

#220

Post by kwhitefoot »

ChrisMarshallNY wrote: post #165

Writing GUI apps for Apple products. Too many variables to mention, but I wrote my first Apple application in 1986. It took several weeks, and wasn't much to look at. These days, I can spin out a full-fat, shippable app, in a couple of hours. I do that all the time, for my test harnesses.

I wrote plenty of GUI applications for IBM PCs in the '80s. It wasn't difficult with Turbo Pascal.
Post reply on HN