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

Advice to Young Web Developers

tumblr.beesbuzz.biz

Post reply on HN
Print view View original

321–328 of 328 posts

Re: Advice to Young Web Developers

#321

Post by Shared404 »

mikorym wrote: post #320
Shared404 wrote: post #314

Earlier quoted context omitted.

Not entirely irrelevant, the thread is about browser support. Also, I agree. I have a laptop with about 256 mb of working ram, so I only use terminal apps with it. If I'm trying to look up documentation and the site doesn't work with lynx it is not a happy day. And that doesn't even touch on servers.

Looks like we are silent friends. The one thing I often get is just a message "JavaScript is not supported" and the other is wacky and long indices at the top. But, just having mywebsite.com/txt would not be a crazy idea...

Indeed.

That's what I don't understand. How hard is it to just make a plain text copy of the data to serve to people who want it instead.

Re: Advice to Young Web Developers

#322

Post by andai »

onli wrote: post #318
andai wrote: post #317

Earlier quoted context omitted.

Ctrl+N. New browser window. This is true across computers and across operating systems.

Definitely not true on my system. There is a flash of some reorganization of the windows content that Chromium does not do, but both windows open instantly. And also: Come on, that wouldn't make a browser slow. Users open new windows once when starting the browser. The rest is about how fast they render pages, react to JS workloads, and maybe how fast they open tabs. FF is more than on par in all of this.

I open new windows constantly. Opening the actual browser though is a whole other story, where the difference is even more striking.

Curious what you said about FF reorganizing the window contents, in my experience Chrome does that and not FF.

It's true JS performance is quite similar. But I've noticed (measured) differences in page load speed as well -- including latency again, the time until it actually responds to the enter key and initiates a network request. (In the network panel this is reported as Stalled.)

Re: Advice to Young Web Developers

#323

Post by collyw »

eyelidlessness wrote: post #302
collyw wrote: post #280

Earlier quoted context omitted.

What you say sounds interesting but could you give an example of "think in contracts" compared to and example of "knowing the runtime state in your head". Personally I have never really seen the advantage of staticaly typed languages over say Python, but I do rely on the strict typing supplied by a database instead.

What I mean is that static typing makes interface boundaries (modules, function parameters and return types, data structures) explicit, and those boundaries are enforced automatically. Those boundaries become a contract, where a provided interface and its call sites must agree on in order to be run. This is like a million little unit tests you get almost for free (obviously you have to write the types, but they're us…

I have been using Python type hinting recently, but I don't find it such a big game changer. Maybe I am just used to writing code without it and it will become clearer if I use it more. Like I say I don't like having an untyped database, and the benefits there aren't things that are obvious straight away.

Re: Advice to Young Web Developers

#324

Post by eyelidlessness »

collyw wrote: post #323
eyelidlessness wrote: post #302

Earlier quoted context omitted.

What I mean is that static typing makes interface boundaries (modules, function parameters and return types, data structures) explicit, and those boundaries are enforced automatically. Those boundaries become a contract, where a provided interface and its call sites must agree on in order to be run. This is like a million little unit tests you get almost for free (obviously you have to write the types, but they're us…

I have been using Python type hinting recently, but I don't find it such a big game changer. Maybe I am just used to writing code without it and it will become clearer if I use it more. Like I say I don't like having an untyped database, and the benefits there aren't things that are obvious straight away.

When I last worked in Python, I also didn't get much benefit, but I wasn't using either mypy or an IDE that warns on type errors. While obviously a different language, it wasn't until I worked with TypeScript in VSCode that I really came to appreciate static typing. And after a few years, I don't think I could go back to working without it.

Re: Advice to Young Web Developers

#325

Post by tuddman »

ridiculous_fish wrote: post #194
schrute wrote: post #134

Earlier quoted context omitted.

You must understand the point I am missing. Why learn a language in the LISP family as a young developer? Does it somehow improve you overall?

Clojure is indeed mind-expanding. Unfortunately its most compelling ideas don't translate to non-LISPs, so I must sadly disagree with the "learn Clojure" suggestion. It's wild fun, but it's hard to apply the ideas to DayJob. An example: threading macros. In a language like Haskell, partial application is optimized for left-to-right. `f a` substitutes the first argument; other orders are more awkward. Functions like `…

> Clojure has other weaknesses which become apparent rapidly.

Clojure has lots of strengths which also become apparent the more you works with it: async, thread-first, thread-last, transducers, core.logic, (partial f a), flexible composition, expressive-ness unrivaled in Dayjob language, hundreds of functions that just work on whatever data you're dealing with, tapping into java "dayjob" libraries without having to deal in actual java. The list goes on.

I've re-written a few applications & libraries from javascript (and other dayjob languages) -> clojure(script). In every case, the lines of code drastically dropped, the functionality expanded, the readability improved, and performance was always on par or better. It's not a silver bullet for everything, but its strengths far outweigh its weaknesses. Like any good mind-expanding drug/language.

> Clojure learning will leave you yearning.

It has been my experience with learning clojure that with each new problem, it has left me yearning ... to learn the more elegant, composable, flexible, robust solution ... in clojure! YMMV.

Re: Advice to Young Web Developers

#326

Post by stevage »

ehnto wrote: post #208
stevage wrote: post #162

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

This is like a post from an upside-down world to me. I suspect that perhaps you've learned primarily front-end frameworks for the majority of your career (an assumption, sorry if that's not right), which will make it seem as though frontend is easy compared to all this mystery stuff you're not used to working with. It's the same for me, but the other direction. I've always worked with server-rendered applications, so…

No, not exactly. I learnt JavaScript in the very early days, when we called it "Dynamic HTML". I mostly built very raw non-frameworked sites until a couple of years ago. I actually found learning Vue (~2 years ago) kind of difficult because of how inside out everything was, and I was still trying to picture what click handlers were being attached where, etc etc.

I was halfway through building a site when I switched to Vue. It ended up reducing the number of lines of code by 30-40%, and made the interactions much simpler to reason about.

Now that I know Vue, I think it's a vastly better way to develop than without it.

Re: Advice to Young Web Developers

#327

Post by stevage »

onion2k wrote: post #232
stevage wrote: post #162

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

Sure, it renders slower. I've just signed my 25th professional client, and I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it. That's because understanding rendering speed is your job, not the client's job. What the client will be saying is things like "Why are my conversions so low?", "My site doesn't appear in search results." and "My friend's neighb…

I guess so. Fortunately, none of my clients are in those kinds of businesses.

Which is sort of a weird point. So much of the web development blogosphere assumes that the reader is working on a site that sells some product direct to the public, who are very fickle, and will abandon your site quickly. Undoubtedly that industry does exist, but I've just never been anywhere near it.

Re: Advice to Young Web Developers

#328

Post by stevage »

chiefalchemist wrote: post #244
stevage wrote: post #162

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

"I love how slow this site is," said no visitor. Ever. If your clients are like mine, there are likely a lot of things your clients don't ask for. For instance, accessibility. Do we ignore that as well? You're also not factoring in ongoing maintenance. What's easy for you to build and deploy might be less so for someone else. React, Vue, etc. are great tools - when they are the correct tool for the job - but they are…

>If your clients are like mine, there are likely a lot of things your clients don't ask for. For instance, accessibility. Do we ignore that as well?

Well, some of my clients are government, so they do care about accessibility. For the rest, I put in some effort, because it's the right thing to do. (As opposed to rendering speed, which I really don't think matters, within reason.)

Post reply on HN