Live data from Hacker News

Advice to Young Web Developers

tumblr.beesbuzz.biz

281–290 of 328 posts

Re: Advice to Young Web Developers

#281

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?

Once you have grokked Lisp, everything else feels weak by comparison, as I understand it. Mostly the appeal is how easy it is to extend the syntax (because there is barely any syntax at all). Disclaimer: I have written a good hunk of Emacs Lisp and also written Scheme professionally, but I have yet to grok macros.

Never used Lisp, but this sounds like a case of offering you loads of cool stuff when writing new code, which in turn will make debugging the code an absolute nightmare. This is based on my experience with mixed metaphor languages like Python. You can do some clever stuff like generating functions dynamically and passing them around, but when you need to debug these bits of code they can be a nightmare. Does Lisp improve on this in any way?

Re: Advice to Young Web Developers

#282

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…

Sounds like nonsense to me.

If I write something in Django, I can let the forms be auto-generated to whatever degree I like. If I do it as a SPA, I essentially need to twice as much work, as I have to write a backend to serve and consume JSON and a frontend to display and interact with it. Then you have got the nightmare of debugging the mess.

Re: Advice to Young Web Developers

#283
Not that any of this advice is bad - a lot of it I agree whole-heartedly with - but it overestimates the amount of influence developers, let alone junior developers, have on the final design of a corporate site. If management/design want infinite scrolling then that's what they get, whatever the developers say.

Re: Advice to Young Web Developers

#284

Earlier quoted context omitted.

Complexity in web products is largely the result of developers who don’t care because they need to ship a product only if that product is written in an extremely familiar way. That’s a product of people who don’t know what they are doing opposed to inherent technological impediments. I form this opinion as a professional web developer with 20 years experience.

I respect your experience, but that does not match up with what I've seen, and what I've seen by proxy networking with other developers in my area. I do personally think simplicity is a virtue. I always try to collaborate with our business team to deliver only what is needed, in the most straightforward way. But if the customer needs a 20 field form, with logical dependencies and validation between fields, as well as…

I doubt your customer specified dependencies as a business requirement.

Re: Advice to Young Web Developers

#285
As someone who uses a SPA (React) for webapps - I find it very useful. I run into issues that wouldn't happen if building purely html/css/vanilla js and when that happens I fix the issue.

The biggest benefit of using a framework IMO is that you're given a fairly strict structure to work within, which makes organization a lot easier. For someone who isn't a master, having some rules "baked in", helps a lot.

That being said, I wouldn't use React to build a static page/site, that makes no sense.

Re: Advice to Young Web Developers

#286

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 am an old developer and I completely disagree with some of the advice. Specifically a lot of older developers think we should be delivering thin client applications which was how the early web did it, but the early web did it for two important reasons. The first being bandwidth and the second being because Sun had a big hand in the early web and sun saw the world as selling big iron that a bunch of dumb terminals with low processing power connected to. It was a dumb idea and Sun partly died because of it. It is a painful user experience and I would dread trying to build modern web delivered applications via the old page-post model. If anything I see today's SPA's as correcting a world gone wrong and finally killing the completely stupid idea of dumb terminals once and for all. They also got rid of flash and a host of other browser plugins.

To sum it up, i was programming before the web existed, I hated the old page-post model, I don't build web pages, I build large apps. I am happy that I can deliver them via the web and I am happy about the state of the art. I think it can be improved on quite a bit, but not by going backwards.

Re: Advice to Young Web Developers

#287
post #279
post #67

Earlier quoted context omitted.

How does that work exactly?

It amazes me that anyone asks this question. I have trouble seeing why you would want put documentaion in a SPA. Search result perhaps, but the rest of it?

I think it's a part of modern web developer culture. Where I work I started on a project which was already 3-4 months down the road and they were fully dedicated to react frontend and Koa on the backend. The whole stack was based on a react boilerplate the company built, as far as I can tell the idea of doing something other than JS on the server was never tabled. Likewise, the idea of rendering HTML on the server was never brought up. Everything is pure client side JS SPA even in places where it might make sense to just render things on the server or load a separate page.

Re: Advice to Young Web Developers

#288

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…

My third client was a SPA breaking down from its usage of redux. They would pull chunks search results from the backend in a loop (and this could be many hundred chunks of 100 objects each), indexing them in their reducers causing heavy rerenders. But they "needed" to do that in order to build their filters. All in the frontend. The machine (2019 MacBook Pro 13) would go full CPU load.

So yeah it happens.

Their old server side solution was near instant.

Definitely the design flaw was to index it in the frontend in the first place instead of preparing that data somewhere in between to easily be consumed by the client but still draws the picture of how many people approach SPAs these days.

Re: Advice to Young Web Developers

#289
post #173

Earlier quoted context omitted.

It's so sad that it became "acceptable" to not test in Firefox (as estimated by the number of sites I randomly encounter that don't work in FF but do in Chrome) right around the time that Firefox Quantum happened and Firefox became good again :(

Firefox must have performed poorly on Windows / MacOS in the past, because Firefox on Linux was never actually that bad. I've used Firefox for 15+ years now and never had the problems that people talk about.

> because Firefox on Linux was never actually that bad.

On Linux, I use Firefox primarily for browsing, but for development I use Chromium. The reason for that is because the JS debugger in Firefox is pretty damn buggy. Some things I've encountered (though they don't happen every time):

- On a breakpoint, type expression in console, hit Enter and it just hangs there without giving you the result. The console will be unresponsive until you unpause.

- On a breakpoint in some part of the callstack, type expression in console and see that variables that should be in scope at that point in the callstack are not in scope for the console.

- Go to a different spot in the callstack and see that the place that Firefox tells you you're at is not correct. It might be off by a few lines.

This might be a very good reason why developers prefer to develop for Chromium/Chrome. Not because they prefer it for browsing or for its performance, but because its development tools actually work.

I made the switch recently, like a month ago, and I've been discovering little things that are just more pleasant when working in Chromium. For example "Copy as cURL", is formatted neater. Firefox puts all the curl options in a single line, but Chromium separates the options in multiple lines.

Re: Advice to Young Web Developers

#290

Earlier quoted context omitted.

If an spa is behaving like that, the coders have failed at their job.

"PHP is fine, it's just poor developers making bad sites". And then people stopped using PHP.

PHP wasn't good, fine maybe, though I understand it's better now.

it was kind of slow, and all the functions were inconsistent, and had a lot of foot-guns. It was easier to write more robust code and model-view-controller code in other languages. (not that it was impossible in php)

Post reply on HN