29 ms·

Advice to Young Web Developers

266 points by EvanAnderson 6y ago

partyboat1586 6y ago
Unfortunately I think it's going to be a long time before web apps stop using dark patterns like infinite scroll. It's not good for their bottom line.
- inanutshellus 6y ago
  With infinite scroll, there is no bottom line. /s
  - theduder99 6y ago
    lol thank you
rickpmg 6y ago
And make sure the back button works?
ithrow 6y ago
This sounded more like a anti-SPA post. Maybe the title should be "Reasons for not building a SPA".
- timw4mail 6y ago
  SPAs are an anti-pattern. Let's rebuild html rendering, navigation history, forms, etc, all with Javascript, because it's the hip thing to do.
  - Grimm1 6y ago
    You're not using that word correctly, since this is not a pattern it's an architecture. Please don't misuse words, especially in a negative context to mean "something I don't like", it cheapens the word in legitimate cases. No comment on whether SPAs are worth anything though, I reserve my opinion.
    - timw4mail 6y ago
      So, it's an anti-pattern of an architecture.
    - arkis22 6y ago
      architecture doesn't contain patterns? architectures don't follow certain patterns? you've never seen certain architectures that smell because they're not following an established pattern?
  - Kaze404 6y ago
    There are very clear reasons for SPAs to exist. 1) Prevent reloading of the page every time the user clicks a link, reducing the overhead of fetching common content between pages multiple times (headers, menus, etc) and providing a more seamless experience to the user. 2) Better emulate the feel of mobile applications, for users who spend most of their time on their phones and don't often or have never interacted with a computer. Yes, those exist. 3) Improved network performance (by sacrificing initial load time). Once the browser downloads and caches the bundle on initial load, the user can revisit the page on regardless of their connection stability or speed. This isn't to say SPAs are a perfect choice in all cases (they also have just as clear drawbacks), but saying "it's what everyone does" is the only reason they exist is downright false.
    - randompwd 6y ago
      > Prevent reloading of the page every time the user clicks a link, You don't need a SPA for that. And page load/render times are much shorter when html is delivered straight to browser fr most applications > Better emulate the feel of mobile applications, That's pretty weak defense. > Once the browser downloads and caches the bundle on initial load, the user can revisit the page Giving we're now in the world of Continuous Deployment, I doubt the cache lasts long. All 3 of those reasons sound very reaching to me. And here's the kicker - doing a SPA well enough to be seamless and performant is hard enough that most sites suck if they're delivering a SPA. Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.
      - Kaze404 6y ago
        Few things annoy me more in this world than when someone "responds" to arguments by quoting half of them to construct and attack a strawman instead of the argument they're supposedly discussing. Please don't dilude conversations like this, it doesn't do anyone any favors.
      - shreddish 6y ago
        > Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable. Are you legitimately worried about unloading third party libraries into memory on the browser??
  - merb 6y ago
    I've never heard that somebody disliked vmware vsphere as an spa. the older flash one however...
  - Scarbutt 6y ago
    You still need js for interactive apps, SPAs avoid the spaghetti mix of html rendering and rendering client side.
  - osrec 6y ago
    The way in which we consume and deliver via internet has moved on from the early days of the web. It's no longer just text, images and links. There's much more to it now, and SPAs are a reasonable step forward to providing richer experiences online with more functionality. Not sure you could ever call them an anti-pattern.
    - timw4mail 6y ago
      > It's no longer just text, images and links. Assuming you add video, 99% of the web is just text,images,links,forms, and video. None of these things even require Javascript.
      - osrec 6y ago
        I'd say a big part of the web is gaming, chatting, interacting. A lot of that content updates every few seconds. Without JS, websockets, ajax requests etc, do you suggest users load the entire page again whenever they want to see an updated view?! Or is your opinion that it should only be possible to do those things in native, purpose-built apps? Because in that case, how do you justify using an operating system? Perhaps we should exclusively use purpose-built assembly code that you flash to some writable media every time you want to run a particular program!
        timw4mail 6y ago
        As another poster said: The right tool for the right job. Also, a SPA is not the only option with Javascript.
    - chipotle_coyote 6y ago
      How would the site we’re communicating on right now be improved if it were rebuilt as an SPA?
      - osrec 6y ago
        Threading could be clearer. Less data would need to be loaded on each page load. I can imagine that a lightweight SPA to handle the a few standard views (e.g. listItems, itemDetails, profile, changePassword, submit) would cut down data transfer by a significant margin (20-30%, maybe more). The UI could also be much better on mobile, and we could give users the option to cache certain pieces of content offline.
  - yagodragon 6y ago
    I also love when i visit a website with a simple markup and minimal js. Not everything should be a react/graphql isomorphic SPA, but have you checked NotionHQ[0]? The whole thing is a single page react app. People use it to build wikis, manage projects and even create blogs and job postings. All that using client-side rendering. It doesn't load as fast as hackernews but most people seem to love it either way. [0] https://www.notion.so/ https://www.notion.so/
    - Nextgrid 6y ago
      I’ve had the displeasure to use this once at a client and I was amazed that they managed to make text editing lag.
- austincheney 6y ago
  The most common reasons for building a SPA: * That is the design pattern dictated by your large framework. * Maintaining state is absurdly simple, but it requires original code if not using a big framework. * The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without. That’s it. Developers twist themselves in knots trying to qualify their opinions as anything more valid than what sounds like incompetence, but with any level of informed discussion it’s clearly about competence (or insecurity).
  - osrec 6y ago
    Another big reason is that developers want to deliver a specific user experience that is simply not possible with the default page loading functionality of most browsers.
    - masa331 6y ago
      You mean the specific experience when back buttons aren't working? Or when urls don't make sense? Or when you can't just share the content by copying the url because it no longer identifies the conten? Or when you can't say if something is loading, missing, or broken? This is my user experience with SPAs regarding navigation.
      - robertoandred 6y ago
        Use better SPAs.
        osrec 6y ago
        Agree. There are a lot of bad SPAs out there, but that's a testament to how easy they are to get started with and their popularity. That doesn't mean good SPAs don't exist - many do!
      - ehutch79 6y ago
        If an spa is behaving like that, the coders have failed at their job.
- jmchuster 6y ago
  It's already in the name Single Page _App_. If you're not building an app, you probably aren't best served using an app framework.
mroche 6y ago
> Browsers change. Relying on browser-specific behavior means you’re relying on that one browser at that one point in time. Code to the standard, and test everywhere. I wish this was listed at the top of the list, in the middle, and at the end. It’s super annoying when a site or application isn’t “supported” because it wasn’t tested in a separate browser (i.e. non-Chrome browsers). I know it’s not always easy with a fair amount of nuance which the Chrome Compatibility post[0] touches on, but developing the web platform should be done openly, with the browser vendors working together to be compatible with each other and not introduce developer or user inconvenience. Otherwise you end up with web ownership and a fragmented platform. [0] https://news.ycombinator.com/item?id=23563525 https://news.ycombinator.com/item?id=23563525
- non-entity 6y ago
  Nothing pisses me off like getting a message that some website only supports Chrome in 2020
  - cglace 6y ago
    The one that drives me crazy are websites that say they only support safari on iOS... It’s all safari under the hood.
    - speedgoose 6y ago
      Safari on iOs is a bit special. Some features are missing compared to the Mac version. You also need quite a few safari ios specific code if you want to build a web app. But this is a bit broken since Apple wants you to publish to the appstore and not release web apps anymore. You also need a Mac to debug safari on iOs. I hate Safari.
      - orev 6y ago
        The point being made is that if you use Chrome or Firefox on IOS, it’s still actually the Safari engine.
flobosg 6y ago
The source post (https://beesbuzz.biz/blog/2934-Advice-to-young-web-developers https://beesbuzz.biz/blog/2934-Advice-to-young-web-developer...) is a bit more readable. The list looks like, well, a list.
deleted 6y ago
[deleted]
CM30 6y ago
Seems like a list of every web development ideal that gets upvoted on Hacker News. Still, I think the list can pretty much condensed down to one point: Use whatever technology is appropriate for this site or web app. Because a lot of developers seem to have a 'when all you have is a hammer' attitude towards web development. They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build will use that framework, regardless of whether it's the right tool for the job. A blog doesn't need to be an SPA. A static business site that never gets updated and doesn't do anything remotely interesting doesn't need to be an SPA. Your documentation doesn't need to be an SPA. It's like that guy who was recreating CPanel as a WordPress plugin/install. Sure, you could do things that way, but may want to rethink whether this is really the best architecture to build a server control panel in.
- laurentdc 6y ago
  I can't count the times I've started to write some basic internal tool with React only to rm -rf everything 1 hour later and replace it with 20 lines of jQuery/vanilla js
  - TheGoodBarn 6y ago
    Such an underrated comment. I think theres some validity to "you're the most productive with whichever tools you're most comfortable/familiar with", but I think people don't realize the levels of abstraction that come with web development. ( My learning path was: Angular 2 -> 7 + sucking at CSS, Angular + Tachyons (learning how to style), -> Angular + Custom CSS for everything, to Vue + Custom css -> Plain HTML + Plain CSS. ) Its like the more you learn the more you understand the boilerplate of libs/frameworks, but also understand what these large tools accomplish for you, and then you learn to appreciate how powerful & simple the "vanilla" web can be if you open your mind to it.
  - imtringued 6y ago
    I can't count the number of times I had to write a HTML template for a small component with just jQuery and it was horrible every single time. Something like htm+preact [0] would clearly do the job much better and only add 5kB of Javascript to your site instead of leaving an unmaintainable mess. [0] https://github.com/developit/htm https://github.com/developit/htm
hpen 6y ago
Why so much hate for infinite scrolls? What if your content is "infinite". I can't see a better way to handle that.
- Elof 6y ago
  My take is just because you can doesn't mean you should. It seems like there is no such thing as infinite content, and if you feel like you are in a case where there is adding constraints will probably improve your product/ux
  - hpen 6y ago
    Any "online data" is virtually infinite. Online in the algorithmic sense, not the internet. Think Instagram or facebook
- jlokier 6y ago
  Infinite content can still be paginated, grouped, or whatever you like. For example think of Google search results. Pagination gives mental boundaries, navigation markers and shortcuts to items. Reading through infinite scrolling is psychologically addictive for a few reasons. Another complaint about infinite scrolling is more technical: Implementations tend to forget your location, and/or significantly change the data when you return to the page. So if you leave an infinite-scrolling page and come back to it, you often can't continue from where you branched off. In addition to not remembering the position and state, sometimes scrolling back down to where you were before takes a very long time. I've had occasions where I've had to scroll for ~20 minutes to reach an item I knew was there because I'd just seen it a few minutes prior, and forgot to use the "open in new tab" workaround when clicking on it. My bank's phone app is bad for this. Scrolling through my transaction history takes ages. If I want to look at last month, no problem. If I want to check a transaction from last year, I'll have to scroll down and wait for a bit more to load, over and over and over.... Then if I click the transaction to view details, then return back to the history to look at more, I have to do the whole annoying scroll-and-repeatedly-wait dance all over again. For every transaction I want to look at. And that's a mobile app not a browser, so no option to "open in a new tab". Mobile apps with all these flaws are horrible. (Thank goodness browsers provide the "open in new tab" workaround for webapps that have linkable items. Pity it's broken by badly written webapps that don't make items linkable.)
hpen 6y ago
I feel like posts like this are just somebody missing the web how it used to be. I mean the Web IS an app platform now.
- britch 6y ago
  I didn't get that sense from the post. I took that they were advocating for basic HTML/JS when appropriate. A reminder that it's still a valid way of doing things. If you're building an app, yeah use React. If you want to put some contact info on the internet, there's no reason it can't be vanilla HTML. Or at least that's how I read it.
  - hpen 6y ago
    Looking over the article again, I'd say your right. It was the statement "The web is built around server-side rendering." that made me feel that way. As a whole you're right. However, I didn't think everyone was out making landing pages with React and VueJS. Maybe they are.
  - hejja 6y ago
    you could also use gatsby to generate static sites in that case -- imo react offers enough developer quality of life features where it's pretty hard to justify not using it
vyuh 6y ago
> Even if you need to preserve client state between page loads (for e.g. music or video playback) you can let the browser do most of the heavy lifting by fetch()ing a new page and replacing your content container at the DOM level. Anyone knows of some easy to learn example of such DOM replacement?
- CameronNemo 6y ago
  Turbolinks does this from what I can tell.
- jimmaswell 6y ago
  Window load events fail to fire this way among other likely problems. You'd have to specifically design around doing it, or do something else like put the whole page in an iframe with your video/music player staying floating outside, or put back inside when it's loaded.
- purerandomness 6y ago
  Yes, look at the examples at https://htmx.org/ https://htmx.org/
lxe 6y ago
There are two that stand out to me: > Always validate your data server-side; anything that comes from the client is suspect. At least sanitize in a way that won't break the server but will throw an error. For internal applications and side projects it's ok to just respond with a 40X or a 50X and move on. > To the developer, “isomorphic” code breaks down the barrier between client and server. "Breaks down the barrier" sounds great, but it's actually has been rather detrimental. "Isomorphic" is confusing even to the senior developers. Having a very clear delimiter of what runs in the server and what runs in the client is essential, and it makes your application much simpler to reason about. Take `isomorphic-fetch` for example... a request from a server to another API server has very different requirements and nuances than a request from a browser to a server.
- mattwad 6y ago
  OTOH, if you use Flow or Typescript, it is amazing to be able to share type-safe interfaces across the stack (not code). I suppose you could get this from any compiled-to-JS language too.
  - hejja 6y ago
    100%
  - avery42 6y ago
    I've been using JSON Schema to define shared data structures like request/response data, and QuickType to generate Go structs (back-end) and Typescript interfaces (front-end), it's been great so far.
  - realtalk_sp 6y ago
    The realization that this permits end-to-end fullstack type safety and allows some awesome things (like surfacing breakage at compile time in response to changes to the data model) is a quietly brewing revolution.
    - jkachmar 6y ago
      This is in constant tension with the point that GP is making though. If you’re not _very_ careful with your software architecture, you can inextricably tie your frontend and backend applications together. Depending on the size of your product, or why the growth plans are for that particular frontend/backend app end up being, this might not be a problem. If it becomes one, though, then every bad technical design decision made in that `common` set of modules or packages ends up hurting you as it gets unspooled from (at least) two components that likely have very different architectural idioms.
baron816 6y ago
Sorry, it’s not usually up to young web developers on whether to use a SPA or not, nor whether to prioritize accessibility. Advocating accessibility is nice though, so do try.
theandrewbailey 6y ago
What about "don't mess with scrolling"?
lucasmullens 6y ago
> To the developer, “isomorphic” code breaks down the barrier between client and server. To a malicious client, it means they have control over the server too. Huh? I don't follow this. Sharing some helpful util functions between the frontend and backend doesn't allow malicious clients to control your server.
- gt2 6y ago
  Guessing he means when the code shared does important things like validation.
- kanobo 6y ago
  Maybe they are thinking of services like firebase where much of the traditional server logic is now handled in the same js libraries that the frontend uses? But I'm also not sure what exactly the author is referring to.
- deleted 6y ago
  [deleted]
- gwbas1c 6y ago
  Think of transpilers like GWT, where you write java that's converted to in-browser Javascript; or the current trend of server-side Javascript. (For what it's worth, both are really really cool technologies!) Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.
- hootbootscoot 6y ago
  meteor
- deleted 6y ago
  [deleted]
- fluffycritter 6y ago
  What I was trying to (clumsily) say is that when people develop "isomorphic" code they tend to forget that some of it runs on the client and some of it runs on the server and the interface between the two cannot be trusted. Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client. And if you don't even know which code is running where, that makes it even more dangerous.
kanobo 6y ago
People are motivated to learn and build what inspires them. Some started web dev because they wanted to make the type of projects they saw in chrome experiments that only run on the latest version of Chrome. Some people see very complex SPA apps and are inspired to make complex tools that can't just be done with HTML. Some get into web dev because they had a passion for browser and flash games. This list isn't wrong but also doesn't take into account the huge variety of web developers.
Minor49er 6y ago
Excellent list. I would add: sometimes it's tempting to rewrite an entire site or application to get away from a world of problems, but you could just as easily be walking into another set of issues at the expense of lost time and existing code value if you aren't careful.
gwbas1c 6y ago
> The web is built around server-side rendering. Grr... I read through the EmberJS tutorial and thought everything was very cool; only to find out that the whole thing is rendered with in-browser Javascript.
devcriollo 6y ago
> If you must do an infinite scroll (and you don’t), make sure that there’s nothing you need to reach at the bottom. The most ignored
torartc 6y ago
I personally don't think this is great advice, but this is exactly the type of advice that will get upvoted here.
mooneater 6y ago
If you step back from modern fullstack web development, it is stunning how much accidental complexity is needed to accomplish anything at all.
- adrianhel 6y ago
  Another thing I painfully realized: It that is not a good idea to document HTML in HTML. <details> <summary> It's not a good idea </summary> really. &lt/details>
squid_demon 6y ago
Advice: don't make everything slow as shit please. Note, this most likely means writing your own trim left function and not depending on zillions of libraries. If you can't write something as simple as this, please don't! Just output a static web-page that loads ultra fast. Thanks young web developers!
jimmaswell 6y ago
Why are infinite scrolls so demonized? I like them, especially if they update the url so you can go back to the same spot. Everyone loved it when Reddit Enhancement Suite did it way back in the day, but now Facebook does it so it's evil.
ChrisMarshallNY 6y ago
Ironically, it uses tumblr, so the damn back button is captured (try getting back here). This is my fave: > Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean.
- scubbo 6y ago
  Worked perfectly for me (Firefox).
- fluffycritter 6y ago
  I had posted this to my own blog at http://beesbuzz.biz/blog/2934-Advice-to-young-web-developers http://beesbuzz.biz/blog/2934-Advice-to-young-web-developers and it looks like it was the Tumblr auto-crossposted version that got submitted here. That's unfortunate. EDIT: I've updated the Tumblr version to make this a bit more clear.
  - ptx 6y ago
    HN doesn't use markdown: https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
    - fluffycritter 6y ago
      Ah, thanks, force of habit. :)
    - smichel17 6y ago
      I use markdown on HN, partially out of protest, partially because it looks fine enough when rendered as plain text (by design).
kvetching 6y ago
"Give people consistent but random stimulus and you will be habit-forming. Getting people hooked on your product might seem like a good idea, but the tobacco industry feels the same way." DO NOT Listen to this. Make your site as addictive as possible. It can only help you win at life. More users = more impact = more money = better life. So long as it's not porn, your website won't be as bad as tobacco.
- arcin 6y ago
  I think this is a little tone deaf to the target audience. Not all developers want to aspire to extracting the maximum amount of resources from users. Some, especially beginners who want to code, just want to build something and build it well.
- fluffycritter 6y ago
  I'd argue that porn is better for you than most of these addictive websites, and certainly better than tobacco. You cannot convince me that the addictiveness of social media is a good thing.
hootbootscoot 6y ago
This was a very nice article. It was one of the best web-related articles I've read in a long time. I liked it.
lsalvatore 6y ago
Advice to Young Frontend Web Developers: Use React. HTML is not a rich enough framework to do client work. Second article in a row here advocating for HTML purism. That is where I jump in and talk about how React changed my career in 2015. Since then, my life has had a measurable impact because of how easy building apps became thanks to React. There is no app where I would consider not using React including landing pages.
- rpmisms 6y ago
  Unless you need your stuff to work on older devices. HTML is really really good at what it does, and often it's good enough. Yeah, don't be a purist, but html and css is just fine for landing pages and static sites.
- err4nt 6y ago
  What kind of software application is a landing page? When you call it a "page" it makes it almost seem like a document of some kind...
- satvikpendem 6y ago
  Yes, and even with React, one can use a static site generator to turn it into HTML, CSS, and minimal JS, so I don't see any reason not to use React, beyond the oft touted ones.
secondcoming 6y ago
Funny, this website broke my ipad safari browser's 'back' button. Double-tap required.
dustingetz 6y ago
1) Nobody has any idea what they're doing 2) If you think you know more than your manager – you are absolutely right 3) HN is 3 years ahead of mainstream, but 10 years behind the edge 4) React was made by an OCaml programmer 5) if you want to be that good, learn emerging languages (all of them) 5) don't optimize for money too soon, if you follow these instructions you will quadruple soon enough 6) Whatever your problem is that is holding you back – drinking, eating, whatever – fix it today 7) Learn Clojure
- eyelidlessness 6y ago
  I like your list, but I’d suggest: 8) learn a statically typed language with a good type system Even if you end up preferring mainstream language X, learning a language that makes you think in expressions rather than operations, and a language that makes you think in contracts rather than knowing the runtime state in your head, is invaluable for learning how to design, structure and maintain a codebase
  - deleted 6y ago
    [deleted]
  - millstone 6y ago
    Agreed. If you grok a best-of-breed dynamic language (Clojure included), and also a best-of-breed statically typed language, you're in rarefied company. And I would add "Learn C or assembly" to grok mechanical sympathy.
  - collyw 6y ago
    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.
    - eyelidlessness 6y ago
      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 usually declarative and very expressive). But it also serves as documentation of how any part of your program's state is structured at any point. To the degree a type system is sound, and to the degree your types are appropriately detailed, you can be assured the documentation is correct and up to date as long as the program compiles. This allows you to eliminate the question of "what does this data look like?" when you're reading code, and focus more on things like whether the logic is implemented correctly. Since you mention it, I'll add that Python does have (optional, gradual) static typing, and a lot of work has gone into the type system in recent versions. It's worth spending a little time adding some static types in a project and seeing some of these benefits. When I last worked in Python, you had to run `mypy` to actually fail on static type errors, I don't know if this is still the case. But you could also use an IDE (like PyCharm, surely there are others) which will at least surface static type errors while you work.
fluffycritter 6y ago
Hi, if possible, could the link please be updated to point to the original post at https://beesbuzz.biz/blog/2934-Advice-to-young-web-developers https://beesbuzz.biz/blog/2934-Advice-to-young-web-developer... ? The Tumblr automatic crosspost isn't really intended to be the canonical version, and I wouldn't mind getting a server load test while we're here. Thanks!
- EvanAnderson 6y ago
  Sorry about that, Fluffy. Your Tumblr feed is listed first in my reader and was moved to submit it almost immediately after reading it. Nice to see you, BTW. Since I never post about my life anywhere I end up just being a lurker in yours, but I'm glad to be.
hejja 6y ago
this article feels lacking in nuance, strong claims that aren't universally true lead to bad reasoning. to any "young developers" read I would say not to blindly adopt these opinions without understanding them.
aabbcc1241 6y ago
Agree we should deliver the html directly to the browser in most of the cases. SPA are often abused and some 'webapp' sites need to load for more than 10 seconds to download the js files... On the other hand, we want to deliver reactive experience. LiveView is an interesting approach. It returns the html with all content at the initial GET request, and apply partial UI update from the server. It processes the user interactions and application logics from the server. This way you don't need to explicitly maintain web API at all, because the render and update functions can directly access the data repository on the server. And we don't need to do validation twice. Liveview is implemented in Elixir and Typescript, also saw similar implementation in php and python.
rpmisms 6y ago
This is a good list. Not great, and not applicable when you're at a crappy organization with bad traditions--likely many young web dev's position. This is much more useful to me now that I'm in a good position at a great company with a good culture.
stevage 6y ago
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 way, and so easy to deploy. 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. Server-side rendering or writing raw HTML are over-rated.
- haecceity 6y ago
  I think only developers care about rendering speed like that. Most people are happy if the page loads in reasonable amount of time. UX people probably know what that means exactly.
  - ketzo 6y ago
    Rule of thumb I’ve heard is, in order to feel “natural”, you should be at: - 10ms response time for interactions (scroll, click, entering text) - 100ms for in-page context switch (changing tabs in a dashboard, loading the next picture, etc.) - 1000ms for page load these are obviously rough guidelines — page load in particular is obviously gonna depend on your user’s internet speed if you have any kind of media — but they’re helpful when thinking about “reasonable”
  - bigiain 6y ago
    What do you base that thinking on? Amazon, Google, Walmart, Mozilla, and Yahoo all have numbers that say otherwise. "Amazon and others found that removing 100 milliseconds of latency improves sales by 1%." I'm 100% sure there are people who care about 1% differences in sales, and the fact that has been rediscovered independently by different organisations shows that "people" at least "aren't happy" with very small increases in page load times, at least when making purchase decisions. (Whether that extends to people reading your latest blog post or endless scrolling your social media site's newfeed is a reasonable question, which I'm not sure 've got a good enough handle on to have an opinion worth sharing.) (From an earlier HN submission today: https://instant.page/ https://instant.page/ - click the [1] link n that page after that "Amazon and others found that removing 100 milliseconds of latency improves sales by 1%." sentence for sources.)
recursivedoubts 6y ago
That's unfortunate: the back button doesn't work on the linked site. Young developers, if you can spare a moment, try to learn what REST (and HATEOAS) really meant: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
grimmdude 6y ago
100% agree with the sentiment that client side rendering is overused.
Animats 6y ago
"The web is built around server-side rendering." That's the React definition of "server side rendering", where HTML gets generated on the server. Real "server side rendering" would mean generating an image server side and shipping that.
- sbergot 6y ago
  "rendering" in a web context is pretty commonly interpreted as "creating the html document". It is not specific to React.
abendstolz 6y ago
Ah, the good ol' KISS - complexity kills.
MrBuddyCasino 6y ago
> Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean. If I had to pick just one, it would be this.
- enriquto 6y ago
  Infinite scrolls are ugly, but i'm not sure artificially "paginated" text is better. The worst thing about infinite scrolls is that you cannot search for a word in the whole document (just on your visible part of the screen, and a screenful below that).
  - deleted 6y ago
    [deleted]
- born2web 6y ago
  the worst is when the "About Us", "Company", "Help", "Contact Us" page links are at the "bottom" and you want to click on them... momentarily appearing and disappearing...
- kall 6y ago
  Why does infinite scroll have to suck on the web, yet you never see pagination in mobile and desktop software? It makes me think that it's not inherently bad, it's the technology that's lacking. If the file explorer would split a 1000 file listing into 10 files each it would drive anyone insane. The "Artists" list on my phone's music player can probably be meassured in meters yet it's a joy to use because momentum scrolling is very good.
  - roryokane 6y ago
    Your phone’s music player’s list of artists does not use infinite scroll, which explains why you like it. If you scroll to the bottom of your list of artists on your phone, you will see “ZZ Top” and nothing special will happen – you’ve reached the end. File explorers, which you mentioned, also do not use infinite scroll. “Infinite scroll” means you can never reach the end, because every time you get close to the end, more content is downloaded and your scroll bar readjusts. There is theoretically some end to the content, but most users will never reach it. Examples are Twitter and Facebook feeds.
anonytrary 6y ago
I do appreciate the author's emphasis on accessibility! However, as you read more bullet points, you start to realize that the author is really just venting about how much they hate modern javascript development (SPAs, VDOMs, client-side rendering, etc.). It gets pretty obvious about 10 bullet points down that this is the overwhelming theme of the post.
danjac 6y ago
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.
SamBoogieNYC 6y ago
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.
pull_my_finger 6y ago
> Use polyfills to support browsers that don’t yet support the standard you’re using. Unless your target users can't switch their browser (it happens), I tend to feel this is slowing new browser adoption. Developers keep coddling users by making sure everything works, and users have no reason to upgrade. Make their obsolete browser function like an obsolete browser and they might just update.

266 points by EvanAnderson 6y ago

Unfortunately I think it's going to be a long time before web apps stop using dark patterns like infinite scroll. It's not good for their bottom line.

inanutshellus 6y ago
With infinite scroll, there is no bottom line. /s
- theduder99 6y ago
  lol thank you

rickpmg 6y ago

And make sure the back button works?

ithrow 6y ago

This sounded more like a anti-SPA post. Maybe the title should be "Reasons for not building a SPA".

timw4mail 6y ago
SPAs are an anti-pattern. Let's rebuild html rendering, navigation history, forms, etc, all with Javascript, because it's the hip thing to do.
- Grimm1 6y ago
  You're not using that word correctly, since this is not a pattern it's an architecture. Please don't misuse words, especially in a negative context to mean "something I don't like", it cheapens the word in legitimate cases. No comment on whether SPAs are worth anything though, I reserve my opinion.
  - timw4mail 6y ago
    So, it's an anti-pattern of an architecture.
  - arkis22 6y ago
    architecture doesn't contain patterns? architectures don't follow certain patterns? you've never seen certain architectures that smell because they're not following an established pattern?
- Kaze404 6y ago
  There are very clear reasons for SPAs to exist. 1) Prevent reloading of the page every time the user clicks a link, reducing the overhead of fetching common content between pages multiple times (headers, menus, etc) and providing a more seamless experience to the user. 2) Better emulate the feel of mobile applications, for users who spend most of their time on their phones and don't often or have never interacted with a computer. Yes, those exist. 3) Improved network performance (by sacrificing initial load time). Once the browser downloads and caches the bundle on initial load, the user can revisit the page on regardless of their connection stability or speed. This isn't to say SPAs are a perfect choice in all cases (they also have just as clear drawbacks), but saying "it's what everyone does" is the only reason they exist is downright false.
  - randompwd 6y ago
    > Prevent reloading of the page every time the user clicks a link, You don't need a SPA for that. And page load/render times are much shorter when html is delivered straight to browser fr most applications > Better emulate the feel of mobile applications, That's pretty weak defense. > Once the browser downloads and caches the bundle on initial load, the user can revisit the page Giving we're now in the world of Continuous Deployment, I doubt the cache lasts long. All 3 of those reasons sound very reaching to me. And here's the kicker - doing a SPA well enough to be seamless and performant is hard enough that most sites suck if they're delivering a SPA. Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.
    - Kaze404 6y ago
      Few things annoy me more in this world than when someone "responds" to arguments by quoting half of them to construct and attack a strawman instead of the argument they're supposedly discussing. Please don't dilude conversations like this, it doesn't do anyone any favors.
    - shreddish 6y ago
      > Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable. Are you legitimately worried about unloading third party libraries into memory on the browser??
- merb 6y ago
  I've never heard that somebody disliked vmware vsphere as an spa. the older flash one however...
- Scarbutt 6y ago
  You still need js for interactive apps, SPAs avoid the spaghetti mix of html rendering and rendering client side.
- osrec 6y ago
  The way in which we consume and deliver via internet has moved on from the early days of the web. It's no longer just text, images and links. There's much more to it now, and SPAs are a reasonable step forward to providing richer experiences online with more functionality. Not sure you could ever call them an anti-pattern.
  - timw4mail 6y ago
    > It's no longer just text, images and links. Assuming you add video, 99% of the web is just text,images,links,forms, and video. None of these things even require Javascript.
    - osrec 6y ago
      I'd say a big part of the web is gaming, chatting, interacting. A lot of that content updates every few seconds. Without JS, websockets, ajax requests etc, do you suggest users load the entire page again whenever they want to see an updated view?! Or is your opinion that it should only be possible to do those things in native, purpose-built apps? Because in that case, how do you justify using an operating system? Perhaps we should exclusively use purpose-built assembly code that you flash to some writable media every time you want to run a particular program!
      - timw4mail 6y ago
        As another poster said: The right tool for the right job. Also, a SPA is not the only option with Javascript.
  - chipotle_coyote 6y ago
    How would the site we’re communicating on right now be improved if it were rebuilt as an SPA?
    - osrec 6y ago
      Threading could be clearer. Less data would need to be loaded on each page load. I can imagine that a lightweight SPA to handle the a few standard views (e.g. listItems, itemDetails, profile, changePassword, submit) would cut down data transfer by a significant margin (20-30%, maybe more). The UI could also be much better on mobile, and we could give users the option to cache certain pieces of content offline.
- yagodragon 6y ago
  I also love when i visit a website with a simple markup and minimal js. Not everything should be a react/graphql isomorphic SPA, but have you checked NotionHQ[0]? The whole thing is a single page react app. People use it to build wikis, manage projects and even create blogs and job postings. All that using client-side rendering. It doesn't load as fast as hackernews but most people seem to love it either way. [0] https://www.notion.so/ https://www.notion.so/
  - Nextgrid 6y ago
    I’ve had the displeasure to use this once at a client and I was amazed that they managed to make text editing lag.
austincheney 6y ago
The most common reasons for building a SPA: * That is the design pattern dictated by your large framework. * Maintaining state is absurdly simple, but it requires original code if not using a big framework. * The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without. That’s it. Developers twist themselves in knots trying to qualify their opinions as anything more valid than what sounds like incompetence, but with any level of informed discussion it’s clearly about competence (or insecurity).
- osrec 6y ago
  Another big reason is that developers want to deliver a specific user experience that is simply not possible with the default page loading functionality of most browsers.
  - masa331 6y ago
    You mean the specific experience when back buttons aren't working? Or when urls don't make sense? Or when you can't just share the content by copying the url because it no longer identifies the conten? Or when you can't say if something is loading, missing, or broken? This is my user experience with SPAs regarding navigation.
    - robertoandred 6y ago
      Use better SPAs.
      - osrec 6y ago
        Agree. There are a lot of bad SPAs out there, but that's a testament to how easy they are to get started with and their popularity. That doesn't mean good SPAs don't exist - many do!
    - ehutch79 6y ago
      If an spa is behaving like that, the coders have failed at their job.
jmchuster 6y ago
It's already in the name Single Page _App_. If you're not building an app, you probably aren't best served using an app framework.

mroche 6y ago

> Browsers change. Relying on browser-specific behavior means you’re relying on that one browser at that one point in time. Code to the standard, and test everywhere. I wish this was listed at the top of the list, in the middle, and at the end. It’s super annoying when a site or application isn’t “supported” because it wasn’t tested in a separate browser (i.e. non-Chrome browsers). I know it’s not always easy with a fair amount of nuance which the Chrome Compatibility post[0] touches on, but developing the web platform should be done openly, with the browser vendors working together to be compatible with each other and not introduce developer or user inconvenience. Otherwise you end up with web ownership and a fragmented platform. [0] https://news.ycombinator.com/item?id=23563525 https://news.ycombinator.com/item?id=23563525

non-entity 6y ago
Nothing pisses me off like getting a message that some website only supports Chrome in 2020
- cglace 6y ago
  The one that drives me crazy are websites that say they only support safari on iOS... It’s all safari under the hood.
  - speedgoose 6y ago
    Safari on iOs is a bit special. Some features are missing compared to the Mac version. You also need quite a few safari ios specific code if you want to build a web app. But this is a bit broken since Apple wants you to publish to the appstore and not release web apps anymore. You also need a Mac to debug safari on iOs. I hate Safari.
    - orev 6y ago
      The point being made is that if you use Chrome or Firefox on IOS, it’s still actually the Safari engine.

flobosg 6y ago

The source post (https://beesbuzz.biz/blog/2934-Advice-to-young-web-developers https://beesbuzz.biz/blog/2934-Advice-to-young-web-developer...) is a bit more readable. The list looks like, well, a list.

deleted 6y ago

[deleted]

CM30 6y ago

Seems like a list of every web development ideal that gets upvoted on Hacker News. Still, I think the list can pretty much condensed down to one point: Use whatever technology is appropriate for this site or web app. Because a lot of developers seem to have a 'when all you have is a hammer' attitude towards web development. They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build will use that framework, regardless of whether it's the right tool for the job. A blog doesn't need to be an SPA. A static business site that never gets updated and doesn't do anything remotely interesting doesn't need to be an SPA. Your documentation doesn't need to be an SPA. It's like that guy who was recreating CPanel as a WordPress plugin/install. Sure, you could do things that way, but may want to rethink whether this is really the best architecture to build a server control panel in.

laurentdc 6y ago
I can't count the times I've started to write some basic internal tool with React only to rm -rf everything 1 hour later and replace it with 20 lines of jQuery/vanilla js
- TheGoodBarn 6y ago
  Such an underrated comment. I think theres some validity to "you're the most productive with whichever tools you're most comfortable/familiar with", but I think people don't realize the levels of abstraction that come with web development. ( My learning path was: Angular 2 -> 7 + sucking at CSS, Angular + Tachyons (learning how to style), -> Angular + Custom CSS for everything, to Vue + Custom css -> Plain HTML + Plain CSS. ) Its like the more you learn the more you understand the boilerplate of libs/frameworks, but also understand what these large tools accomplish for you, and then you learn to appreciate how powerful & simple the "vanilla" web can be if you open your mind to it.
- imtringued 6y ago
  I can't count the number of times I had to write a HTML template for a small component with just jQuery and it was horrible every single time. Something like htm+preact [0] would clearly do the job much better and only add 5kB of Javascript to your site instead of leaving an unmaintainable mess. [0] https://github.com/developit/htm https://github.com/developit/htm

hpen 6y ago

Why so much hate for infinite scrolls? What if your content is "infinite". I can't see a better way to handle that.

Elof 6y ago
My take is just because you can doesn't mean you should. It seems like there is no such thing as infinite content, and if you feel like you are in a case where there is adding constraints will probably improve your product/ux
- hpen 6y ago
  Any "online data" is virtually infinite. Online in the algorithmic sense, not the internet. Think Instagram or facebook
jlokier 6y ago
Infinite content can still be paginated, grouped, or whatever you like. For example think of Google search results. Pagination gives mental boundaries, navigation markers and shortcuts to items. Reading through infinite scrolling is psychologically addictive for a few reasons. Another complaint about infinite scrolling is more technical: Implementations tend to forget your location, and/or significantly change the data when you return to the page. So if you leave an infinite-scrolling page and come back to it, you often can't continue from where you branched off. In addition to not remembering the position and state, sometimes scrolling back down to where you were before takes a very long time. I've had occasions where I've had to scroll for ~20 minutes to reach an item I knew was there because I'd just seen it a few minutes prior, and forgot to use the "open in new tab" workaround when clicking on it. My bank's phone app is bad for this. Scrolling through my transaction history takes ages. If I want to look at last month, no problem. If I want to check a transaction from last year, I'll have to scroll down and wait for a bit more to load, over and over and over.... Then if I click the transaction to view details, then return back to the history to look at more, I have to do the whole annoying scroll-and-repeatedly-wait dance all over again. For every transaction I want to look at. And that's a mobile app not a browser, so no option to "open in a new tab". Mobile apps with all these flaws are horrible. (Thank goodness browsers provide the "open in new tab" workaround for webapps that have linkable items. Pity it's broken by badly written webapps that don't make items linkable.)

hpen 6y ago

I feel like posts like this are just somebody missing the web how it used to be. I mean the Web IS an app platform now.

britch 6y ago
I didn't get that sense from the post. I took that they were advocating for basic HTML/JS when appropriate. A reminder that it's still a valid way of doing things. If you're building an app, yeah use React. If you want to put some contact info on the internet, there's no reason it can't be vanilla HTML. Or at least that's how I read it.
- hpen 6y ago
  Looking over the article again, I'd say your right. It was the statement "The web is built around server-side rendering." that made me feel that way. As a whole you're right. However, I didn't think everyone was out making landing pages with React and VueJS. Maybe they are.
- hejja 6y ago
  you could also use gatsby to generate static sites in that case -- imo react offers enough developer quality of life features where it's pretty hard to justify not using it

vyuh 6y ago

> Even if you need to preserve client state between page loads (for e.g. music or video playback) you can let the browser do most of the heavy lifting by fetch()ing a new page and replacing your content container at the DOM level. Anyone knows of some easy to learn example of such DOM replacement?

CameronNemo 6y ago
Turbolinks does this from what I can tell.
jimmaswell 6y ago
Window load events fail to fire this way among other likely problems. You'd have to specifically design around doing it, or do something else like put the whole page in an iframe with your video/music player staying floating outside, or put back inside when it's loaded.
purerandomness 6y ago
Yes, look at the examples at https://htmx.org/ https://htmx.org/

lxe 6y ago

There are two that stand out to me: > Always validate your data server-side; anything that comes from the client is suspect. At least sanitize in a way that won't break the server but will throw an error. For internal applications and side projects it's ok to just respond with a 40X or a 50X and move on. > To the developer, “isomorphic” code breaks down the barrier between client and server. "Breaks down the barrier" sounds great, but it's actually has been rather detrimental. "Isomorphic" is confusing even to the senior developers. Having a very clear delimiter of what runs in the server and what runs in the client is essential, and it makes your application much simpler to reason about. Take `isomorphic-fetch` for example... a request from a server to another API server has very different requirements and nuances than a request from a browser to a server.

mattwad 6y ago
OTOH, if you use Flow or Typescript, it is amazing to be able to share type-safe interfaces across the stack (not code). I suppose you could get this from any compiled-to-JS language too.
- hejja 6y ago
  100%
- avery42 6y ago
  I've been using JSON Schema to define shared data structures like request/response data, and QuickType to generate Go structs (back-end) and Typescript interfaces (front-end), it's been great so far.
- realtalk_sp 6y ago
  The realization that this permits end-to-end fullstack type safety and allows some awesome things (like surfacing breakage at compile time in response to changes to the data model) is a quietly brewing revolution.
  - jkachmar 6y ago
    This is in constant tension with the point that GP is making though. If you’re not _very_ careful with your software architecture, you can inextricably tie your frontend and backend applications together. Depending on the size of your product, or why the growth plans are for that particular frontend/backend app end up being, this might not be a problem. If it becomes one, though, then every bad technical design decision made in that `common` set of modules or packages ends up hurting you as it gets unspooled from (at least) two components that likely have very different architectural idioms.

baron816 6y ago

Sorry, it’s not usually up to young web developers on whether to use a SPA or not, nor whether to prioritize accessibility. Advocating accessibility is nice though, so do try.

theandrewbailey 6y ago

What about "don't mess with scrolling"?

lucasmullens 6y ago

> To the developer, “isomorphic” code breaks down the barrier between client and server. To a malicious client, it means they have control over the server too. Huh? I don't follow this. Sharing some helpful util functions between the frontend and backend doesn't allow malicious clients to control your server.

gt2 6y ago
Guessing he means when the code shared does important things like validation.
kanobo 6y ago
Maybe they are thinking of services like firebase where much of the traditional server logic is now handled in the same js libraries that the frontend uses? But I'm also not sure what exactly the author is referring to.
deleted 6y ago
[deleted]
gwbas1c 6y ago
Think of transpilers like GWT, where you write java that's converted to in-browser Javascript; or the current trend of server-side Javascript. (For what it's worth, both are really really cool technologies!) Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.
hootbootscoot 6y ago
meteor
deleted 6y ago
[deleted]
fluffycritter 6y ago
What I was trying to (clumsily) say is that when people develop "isomorphic" code they tend to forget that some of it runs on the client and some of it runs on the server and the interface between the two cannot be trusted. Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client. And if you don't even know which code is running where, that makes it even more dangerous.

kanobo 6y ago

People are motivated to learn and build what inspires them. Some started web dev because they wanted to make the type of projects they saw in chrome experiments that only run on the latest version of Chrome. Some people see very complex SPA apps and are inspired to make complex tools that can't just be done with HTML. Some get into web dev because they had a passion for browser and flash games. This list isn't wrong but also doesn't take into account the huge variety of web developers.

Minor49er 6y ago

Excellent list. I would add: sometimes it's tempting to rewrite an entire site or application to get away from a world of problems, but you could just as easily be walking into another set of issues at the expense of lost time and existing code value if you aren't careful.

gwbas1c 6y ago

> The web is built around server-side rendering. Grr... I read through the EmberJS tutorial and thought everything was very cool; only to find out that the whole thing is rendered with in-browser Javascript.

devcriollo 6y ago

> If you must do an infinite scroll (and you don’t), make sure that there’s nothing you need to reach at the bottom. The most ignored

torartc 6y ago

I personally don't think this is great advice, but this is exactly the type of advice that will get upvoted here.

mooneater 6y ago

If you step back from modern fullstack web development, it is stunning how much accidental complexity is needed to accomplish anything at all.

adrianhel 6y ago
Another thing I painfully realized: It that is not a good idea to document HTML in HTML. <details> <summary> It's not a good idea </summary> really. &lt/details>

squid_demon 6y ago

Advice: don't make everything slow as shit please. Note, this most likely means writing your own trim left function and not depending on zillions of libraries. If you can't write something as simple as this, please don't! Just output a static web-page that loads ultra fast. Thanks young web developers!

jimmaswell 6y ago

Why are infinite scrolls so demonized? I like them, especially if they update the url so you can go back to the same spot. Everyone loved it when Reddit Enhancement Suite did it way back in the day, but now Facebook does it so it's evil.

ChrisMarshallNY 6y ago

Ironically, it uses tumblr, so the damn back button is captured (try getting back here). This is my fave: > Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean.

scubbo 6y ago
Worked perfectly for me (Firefox).
fluffycritter 6y ago
I had posted this to my own blog at http://beesbuzz.biz/blog/2934-Advice-to-young-web-developers http://beesbuzz.biz/blog/2934-Advice-to-young-web-developers and it looks like it was the Tumblr auto-crossposted version that got submitted here. That's unfortunate. EDIT: I've updated the Tumblr version to make this a bit more clear.
- ptx 6y ago
  HN doesn't use markdown: https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
  - fluffycritter 6y ago
    Ah, thanks, force of habit. :)
  - smichel17 6y ago
    I use markdown on HN, partially out of protest, partially because it looks fine enough when rendered as plain text (by design).

kvetching 6y ago

"Give people consistent but random stimulus and you will be habit-forming. Getting people hooked on your product might seem like a good idea, but the tobacco industry feels the same way." DO NOT Listen to this. Make your site as addictive as possible. It can only help you win at life. More users = more impact = more money = better life. So long as it's not porn, your website won't be as bad as tobacco.

arcin 6y ago
I think this is a little tone deaf to the target audience. Not all developers want to aspire to extracting the maximum amount of resources from users. Some, especially beginners who want to code, just want to build something and build it well.
fluffycritter 6y ago
I'd argue that porn is better for you than most of these addictive websites, and certainly better than tobacco. You cannot convince me that the addictiveness of social media is a good thing.

hootbootscoot 6y ago

This was a very nice article. It was one of the best web-related articles I've read in a long time. I liked it.

lsalvatore 6y ago

Advice to Young Frontend Web Developers: Use React. HTML is not a rich enough framework to do client work. Second article in a row here advocating for HTML purism. That is where I jump in and talk about how React changed my career in 2015. Since then, my life has had a measurable impact because of how easy building apps became thanks to React. There is no app where I would consider not using React including landing pages.

rpmisms 6y ago
Unless you need your stuff to work on older devices. HTML is really really good at what it does, and often it's good enough. Yeah, don't be a purist, but html and css is just fine for landing pages and static sites.
err4nt 6y ago
What kind of software application is a landing page? When you call it a "page" it makes it almost seem like a document of some kind...
satvikpendem 6y ago
Yes, and even with React, one can use a static site generator to turn it into HTML, CSS, and minimal JS, so I don't see any reason not to use React, beyond the oft touted ones.

secondcoming 6y ago

Funny, this website broke my ipad safari browser's 'back' button. Double-tap required.

dustingetz 6y ago

1) Nobody has any idea what they're doing 2) If you think you know more than your manager – you are absolutely right 3) HN is 3 years ahead of mainstream, but 10 years behind the edge 4) React was made by an OCaml programmer 5) if you want to be that good, learn emerging languages (all of them) 5) don't optimize for money too soon, if you follow these instructions you will quadruple soon enough 6) Whatever your problem is that is holding you back – drinking, eating, whatever – fix it today 7) Learn Clojure

eyelidlessness 6y ago
I like your list, but I’d suggest: 8) learn a statically typed language with a good type system Even if you end up preferring mainstream language X, learning a language that makes you think in expressions rather than operations, and a language that makes you think in contracts rather than knowing the runtime state in your head, is invaluable for learning how to design, structure and maintain a codebase
- deleted 6y ago
  [deleted]
- millstone 6y ago
  Agreed. If you grok a best-of-breed dynamic language (Clojure included), and also a best-of-breed statically typed language, you're in rarefied company. And I would add "Learn C or assembly" to grok mechanical sympathy.
- collyw 6y ago
  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.
  - eyelidlessness 6y ago
    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 usually declarative and very expressive). But it also serves as documentation of how any part of your program's state is structured at any point. To the degree a type system is sound, and to the degree your types are appropriately detailed, you can be assured the documentation is correct and up to date as long as the program compiles. This allows you to eliminate the question of "what does this data look like?" when you're reading code, and focus more on things like whether the logic is implemented correctly. Since you mention it, I'll add that Python does have (optional, gradual) static typing, and a lot of work has gone into the type system in recent versions. It's worth spending a little time adding some static types in a project and seeing some of these benefits. When I last worked in Python, you had to run `mypy` to actually fail on static type errors, I don't know if this is still the case. But you could also use an IDE (like PyCharm, surely there are others) which will at least surface static type errors while you work.

fluffycritter 6y ago

Hi, if possible, could the link please be updated to point to the original post at https://beesbuzz.biz/blog/2934-Advice-to-young-web-developers https://beesbuzz.biz/blog/2934-Advice-to-young-web-developer... ? The Tumblr automatic crosspost isn't really intended to be the canonical version, and I wouldn't mind getting a server load test while we're here. Thanks!

EvanAnderson 6y ago
Sorry about that, Fluffy. Your Tumblr feed is listed first in my reader and was moved to submit it almost immediately after reading it. Nice to see you, BTW. Since I never post about my life anywhere I end up just being a lurker in yours, but I'm glad to be.

hejja 6y ago

this article feels lacking in nuance, strong claims that aren't universally true lead to bad reasoning. to any "young developers" read I would say not to blindly adopt these opinions without understanding them.

aabbcc1241 6y ago

Agree we should deliver the html directly to the browser in most of the cases. SPA are often abused and some 'webapp' sites need to load for more than 10 seconds to download the js files... On the other hand, we want to deliver reactive experience. LiveView is an interesting approach. It returns the html with all content at the initial GET request, and apply partial UI update from the server. It processes the user interactions and application logics from the server. This way you don't need to explicitly maintain web API at all, because the render and update functions can directly access the data repository on the server. And we don't need to do validation twice. Liveview is implemented in Elixir and Typescript, also saw similar implementation in php and python.

rpmisms 6y ago

This is a good list. Not great, and not applicable when you're at a crappy organization with bad traditions--likely many young web dev's position. This is much more useful to me now that I'm in a good position at a great company with a good culture.

stevage 6y ago

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 way, and so easy to deploy. 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. Server-side rendering or writing raw HTML are over-rated.

haecceity 6y ago
I think only developers care about rendering speed like that. Most people are happy if the page loads in reasonable amount of time. UX people probably know what that means exactly.
- ketzo 6y ago
  Rule of thumb I’ve heard is, in order to feel “natural”, you should be at: - 10ms response time for interactions (scroll, click, entering text) - 100ms for in-page context switch (changing tabs in a dashboard, loading the next picture, etc.) - 1000ms for page load these are obviously rough guidelines — page load in particular is obviously gonna depend on your user’s internet speed if you have any kind of media — but they’re helpful when thinking about “reasonable”
- bigiain 6y ago
  What do you base that thinking on? Amazon, Google, Walmart, Mozilla, and Yahoo all have numbers that say otherwise. "Amazon and others found that removing 100 milliseconds of latency improves sales by 1%." I'm 100% sure there are people who care about 1% differences in sales, and the fact that has been rediscovered independently by different organisations shows that "people" at least "aren't happy" with very small increases in page load times, at least when making purchase decisions. (Whether that extends to people reading your latest blog post or endless scrolling your social media site's newfeed is a reasonable question, which I'm not sure 've got a good enough handle on to have an opinion worth sharing.) (From an earlier HN submission today: https://instant.page/ https://instant.page/ - click the [1] link n that page after that "Amazon and others found that removing 100 milliseconds of latency improves sales by 1%." sentence for sources.)

recursivedoubts 6y ago

That's unfortunate: the back button doesn't work on the linked site. Young developers, if you can spare a moment, try to learn what REST (and HATEOAS) really meant: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

grimmdude 6y ago

100% agree with the sentiment that client side rendering is overused.

Animats 6y ago

"The web is built around server-side rendering." That's the React definition of "server side rendering", where HTML gets generated on the server. Real "server side rendering" would mean generating an image server side and shipping that.

sbergot 6y ago
"rendering" in a web context is pretty commonly interpreted as "creating the html document". It is not specific to React.

abendstolz 6y ago

Ah, the good ol' KISS - complexity kills.

MrBuddyCasino 6y ago

> Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean. If I had to pick just one, it would be this.

enriquto 6y ago
Infinite scrolls are ugly, but i'm not sure artificially "paginated" text is better. The worst thing about infinite scrolls is that you cannot search for a word in the whole document (just on your visible part of the screen, and a screenful below that).
- deleted 6y ago
  [deleted]
born2web 6y ago
the worst is when the "About Us", "Company", "Help", "Contact Us" page links are at the "bottom" and you want to click on them... momentarily appearing and disappearing...
kall 6y ago
Why does infinite scroll have to suck on the web, yet you never see pagination in mobile and desktop software? It makes me think that it's not inherently bad, it's the technology that's lacking. If the file explorer would split a 1000 file listing into 10 files each it would drive anyone insane. The "Artists" list on my phone's music player can probably be meassured in meters yet it's a joy to use because momentum scrolling is very good.
- roryokane 6y ago
  Your phone’s music player’s list of artists does not use infinite scroll, which explains why you like it. If you scroll to the bottom of your list of artists on your phone, you will see “ZZ Top” and nothing special will happen – you’ve reached the end. File explorers, which you mentioned, also do not use infinite scroll. “Infinite scroll” means you can never reach the end, because every time you get close to the end, more content is downloaded and your scroll bar readjusts. There is theoretically some end to the content, but most users will never reach it. Examples are Twitter and Facebook feeds.

anonytrary 6y ago

I do appreciate the author's emphasis on accessibility! However, as you read more bullet points, you start to realize that the author is really just venting about how much they hate modern javascript development (SPAs, VDOMs, client-side rendering, etc.). It gets pretty obvious about 10 bullet points down that this is the overwhelming theme of the post.

danjac 6y ago

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.

SamBoogieNYC 6y ago

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.

pull_my_finger 6y ago

> Use polyfills to support browsers that don’t yet support the standard you’re using. Unless your target users can't switch their browser (it happens), I tend to feel this is slowing new browser adoption. Developers keep coddling users by making sure everything works, and users have no reason to upgrade. Make their obsolete browser function like an obsolete browser and they might just update.