[HN Gopher] Advice to Young Web Developers
___________________________________________________________________
Advice to Young Web Developers
Author : EvanAnderson
Score : 97 points
Date : 2020-06-17 21:12 UTC (1 days ago)
(HTM) web link (tumblr.beesbuzz.biz)
(TXT) w3m dump (tumblr.beesbuzz.biz)
| mroche wrote:
| > _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
| non-entity wrote:
| Nothing pisses me off like getting a message that some website
| only supports Chrome in 2020
| jjoonathan wrote:
| 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 :(
| cglace wrote:
| The one that drives me crazy are websites that say they only
| support safari on iOS... It's all safari under the hood.
| speedgoose wrote:
| 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.
| robertoandred wrote:
| If anything, the Mac version is missing features compared
| to the iOS version...
| jimmaswell wrote:
| Special is right. It's full of non-standard behavior I've
| had the pain of fixing because you need to target iOS,
| e.g. needing Safari-specific attributes to capture
| scrolling in a modal.
| orev wrote:
| The point being made is that if you use Chrome or Firefox
| on IOS, it's still actually the Safari engine.
| naugtur wrote:
| Actually, it's less than that. Safari doesn't share some
| of the features. IIRC one if them is service workers.
| abjKT26nO8 wrote:
| At work we're forced to use a service for exchanging files
| where uploading a file is only possible in Chrome, but
| downloading a file is sometimes only possible in Firefox.
| Pinnacle of UX.
| tobr wrote:
| It's good advice (like most of the list!) but I'm not sure
| expecting a beginner[1] to "code to the standard" is realistic.
| The standard (i.e the spec) isn't beginner-friendly. You learn
| by trying things out and seeing what happens.
|
| 1: _Assuming they meant for the advice to apply to beginners
| rather than young developers - what age they are seems
| irrelevant._
| at_a_remove wrote:
| I don't know about that.
|
| Okay, this was _long_ ago, but we had to roll out a new top-
| level website. I decided to be a complete hardass about it.
| Everything would validate, both for HTML and CSS. I would
| follow ADA standards as well as I could understand them. I
| dutifully tried things out in lynx. I even made some print
| style sheets (a new concept at the time). However, I had
| almost nothing to test on.
|
| I got a lot of flak for being slow, we should hurry this up,
| and so on. And yet the emails would come in later from the
| higher ups, "Wow, this works on my Blackberry!" I had no
| access to such a device, but plodding adherence to various
| guidelines, as dull as they were, saved my bacon there. Even
| the disability folks I could find seemed pleased.
|
| It isn't "move fast and break things" but you can reap a few
| benefits out of it.
| vyuh wrote:
| > _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?
| jimmaswell wrote:
| 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.
| CameronNemo wrote:
| Turbolinks does this from what I can tell.
| partyboat1586 wrote:
| 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 wrote:
| With infinite scroll, there is no bottom line. /s
| theduder99 wrote:
| lol thank you
| jimmaswell wrote:
| 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.
| lxe wrote:
| 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 wrote:
| 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.
| [deleted]
| SahAssar wrote:
| > At least sanitize in a way that won't break the server but
| will throw an error.
|
| If you need to sanitize to avoid breaking the server then the
| server is already broken. Also, never sanitize, validate on
| input and escape/encode on output, but sanitization (meaning
| removing/cleaning invalid input) is the wrong way.
| lucasmullens wrote:
| > 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.
| [deleted]
| gwbas1c wrote:
| 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.
| gt2 wrote:
| Guessing he means when the code shared does important things
| like validation.
| kanobo wrote:
| 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.
| baron816 wrote:
| 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.
| CM30 wrote:
| 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.
| paxys wrote:
| > Your documentation doesn't need to be an SPA.
|
| Disagree with this. Having the entire documentation site
| working as normal on my browser when I have bad/no internet
| connectivity is extremely useful.
| dahfizz wrote:
| It really speaks to modern web dev culture when you can't
| imagine a way of viewing a document offline without running
| JavaScript.
| ogre_codes wrote:
| Don't need a SPA for that. Local HTML based documentation was
| a thing long before SPA was even a term.
| paxys wrote:
| How does that work exactly?
| jand wrote:
| No advertisment, just an example:
|
| https://en.wikipedia.org/wiki/Doxygen
| ogre_codes wrote:
| It's HTML, it's designed to link between URLs. Whether
| the URL is a file on your filesystem or on the web is
| irrelevant. If you keep all your resources in the same
| set of subfolders you can use the same html/ images/ CSS
| as the web and use relative links.
| duskwuff wrote:
| It's literally just a folder full of perfectly normal
| HTML files. You don't need Javascript or a SPA to double-
| click one of those and look at it in a browser.
|
| Even better, if your operating system has full-text file
| indexing, it'll be able to search them normally.
| paxys wrote:
| Sure, but you also have to manually redownload the entire
| site whenever there is a change.
| leephillips wrote:
| That's what rsync is for.
| frenchyatwork wrote:
| You would with a SPA as well.
|
| Edit: incidentally, a common way for this to work is that
| the documentation just comes with the software itself, so
| it's just sitting there on you computer. If the software
| updates, the documentation updates.
| detaro wrote:
| Many SPA examples will try load bits from the server and
| fail. And a non-SPA site can easily be provided as a download
| too, or use a service worker to provide offline access in the
| browser.
| heavyset_go wrote:
| > _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._
|
| At least where I live, small businesses contract with agencies
| that develop React sites for them, and suddenly these non-IT
| companies are owners of expensive and hard to maintain websites
| that they don't, and shouldn't need to, know the first thing
| about maintaining. No one wants to work with the projects,
| because they were written in, say 2015 React, back when React
| used X feature that isn't cool anymore, so it gets rewritten by
| another agency, and so on.
|
| Meanwhile, WordPress on a managed host or a static site would
| suit those businesses just fine. Then, they wouldn't have
| trouble hiring to maintain it, or could even maintain it
| themselves.
|
| If you work for an agency or you're freelancing, please stop
| burdening small businesses like this.
| laurentdc wrote:
| 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
| willio58 wrote:
| When I started at my current company I was shocked that they
| were using Wordpress for 90% of client sites. Now 2yrs in, I'm
| thankful we are using Wordpress for these sites. It keeps
| things maintainable and simple. And for 90% of businesses,
| that's exactly what they need.
| flobosg wrote:
| The source post (https://beesbuzz.biz/blog/2934-Advice-to-young-
| web-developer...) is a bit more readable. The list looks like,
| well, a list.
| kanobo wrote:
| 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 wrote:
| 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.
| kvetching wrote:
| "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.
| gwbas1c wrote:
| > 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.
| hpen wrote:
| Why so much hate for infinite scrolls? What if your content is
| "infinite". I can't see a better way to handle that.
| jlokier wrote:
| 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 wrote:
| Sure, there are plenty of bad implementations out there, but
| is that a reason to no use them at all?
|
| A DB tool I made has infinite scroll plus pagination buttons.
| It updates the pagination buttons while scrolling.
| xemdetia wrote:
| The infinite scroll problem I feel comes up most that if there
| was a useful piece of information in the middle of an infinite
| scroll it is likely impossible for you to return there with any
| sort of reliability. You can't save the URL because it probably
| doesn't encode anything useful about where you are in a most
| cases. You can't logically organize 'where' this information is
| because its location is pure happenstance. It is pointlessly
| ephemeral. I can't start on page 5, I can't start on page 100.
| I have to scroll and just pray I get to get lucky which is the
| function of a slot machine, not someone who's trying to present
| me information. If I _really_ wanted to get that much more
| content I am more than happy to click the next button.
| hpen wrote:
| You can have infinite scroll + pagination buttons
| Elof wrote:
| 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 wrote:
| Any "online data" is virtually infinite. Online in the
| algorithmic sense, not the internet. Think Instagram or
| facebook
| theandrewbailey wrote:
| What about "don't mess with scrolling"?
| hootbootscoot wrote:
| 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.
| hpen wrote:
| 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 wrote:
| 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 wrote:
| 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.
| devcriollo wrote:
| > 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
| rickpmg wrote:
| And make sure the back button works?
| squid_demon wrote:
| 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!
| ChrisMarshallNY wrote:
| 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._
| mooneater wrote:
| If you step back from modern fullstack web development, it is
| stunning how much accidental complexity is needed to accomplish
| anything at all.
| [deleted]
| ithrow wrote:
| This sounded more like a anti-SPA post. Maybe the title should be
| "Reasons for not building a SPA".
| austincheney wrote:
| 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 wrote:
| 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.
| chipotle_coyote wrote:
| That's arguably the _best_ reason to develop an SPA. But I
| don't think the linked article is arguing against that as
| much as arguing against using "SPA think" in places where
| the user experience really doesn't require it. There are
| web sites which are basically magazines /blogs whose
| _reading_ functionality relies on JavaScript. Building a
| web site like it's an app may give some advantages to the
| developers, but it's almost always a slower, and sometimes
| more fragile, experience compared to just delivering HTML.
| masa331 wrote:
| 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 wrote:
| Use better SPAs.
| osrec wrote:
| 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 wrote:
| If an spa is behaving like that, the coders have failed
| at their job.
| nepeckman wrote:
| I'll offer up another reason, which I feel is a little more
| accurate:
|
| * Your web app requires heavily interactive bits, such as
| smart forms, smart tables, previews, content editing, etc. To
| deliver such functionality in a maintainable way, you use a
| framework. (As a side note, yes it is possible to deliver
| this functionality in vanilla JS, but to make it maintainable
| one must essentially build an ad hoc framework.) Because most
| frameworks push users towards a SPA, you end up following the
| path of least resistance and developing a SPA.
| austincheney wrote:
| I would argue most websites never require any of those.
| When any of those are required they don't need a giant
| framework to achieve maintainability. All that's needed to
| achieve maintainability is a competent developer who values
| both simplicity and written documentation.
| nepeckman wrote:
| This sentiment frustrates me. The majority of web
| developers today are application developers. I've spent
| the past 5 years delivering business applications via the
| web as a platform. The web has a lot of advantage as a
| platform: no install, cross platform, networked by
| default. But the web was not designed as an application
| platform, so making it into one is complex. Business
| applications have inherent complexity as well, and
| managing all that complexity is a non trivial task.
|
| Posts like this frustrate me because you seem to be
| suggesting complexity in the web domain is largely
| incidental.
| Scarbutt wrote:
| What's a big framework to you? is React one?
| timw4mail wrote:
| 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.
| yagodragon wrote:
| 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/
| Nextgrid wrote:
| I've had the displeasure to use this once at a client and I
| was amazed that they managed to make _text editing_ lag.
| Kaze404 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| merb wrote:
| I've never heard that somebody disliked vmware vsphere as an
| spa. the older flash one however...
| Scarbutt wrote:
| You still need js for interactive apps, SPAs avoid the
| spaghetti mix of html rendering and rendering client side.
| osrec wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| As another poster said: The right tool for the right job.
|
| Also, a SPA is not the only option with Javascript.
| chipotle_coyote wrote:
| How would the site we're communicating on right now be
| improved if it were rebuilt as an SPA?
| osrec wrote:
| 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.
| Grimm1 wrote:
| 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 wrote:
| So, it's an anti-pattern of an architecture.
| jmchuster wrote:
| 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.
| torartc wrote:
| I personally don't think this is great advice, but this is
| exactly the type of advice that will get upvoted here.
___________________________________________________________________
(page generated 2020-06-18 23:00 UTC)