[HN Gopher] Look ma, no React: I recoded my portfolio site with ...
___________________________________________________________________
Look ma, no React: I recoded my portfolio site with vanilla
everything
Author : marjipan200
Score : 73 points
Date : 2023-07-15 13:31 UTC (9 hours ago)
(HTM) web link (clairefro.dev)
(TXT) w3m dump (clairefro.dev)
| willsmith72 wrote:
| I don't get the value prop of all vanilla. The overhead involved
| in building a react app is nearly nil with all the tooling we
| have. Sure CRA was slow, but vite makes things sub-second again.
|
| It's like when remix people talk about progressive enhancement to
| me. Sure, cool, you can do things differently. But why? If you
| already know the ins and outs of a framework or tool and are
| productive with it, use it. I'm never gonna hire someone because
| of how much they "flexed" with their vanilla site, just like I
| won't hire someone who flexed with their cool fresh-from-bootcamp
| react animations.
| smarkov wrote:
| > The overhead involved in building a react app is nearly nil
| with all the tooling we have.
|
| All the tooling we have is exactly why React has an overhead
| which is far from nil. Every package goes through a period of
| changing its best practices, some go through multiple. Entire
| packages go in and out of season, seemingly depending on the
| phase of the moon. There's a new bundler every year, each with
| its own quirks. For some things there's 4 "go to" packages that
| achieve the same thing but take a different path to get there.
| You have all these packages and tooling you have to learn, stay
| in touch with, maintain and fight against. All of that so you
| could ship megabytes of JS that ultimately just changes some
| text on a page. You can do all of that with vanilla JS and
| spare yourself the headache.
| willsmith72 wrote:
| It takes work to keep up with the latest-and-greatest in
| modern web frameworks. 100% agree.
|
| But if you're already doing that, because you work in the
| field, or are passionate about it, then that checkbox is
| ticked.
|
| I wouldn't do all that JUST to build a static portfolio, but
| if you already learnt and kept up with all of that stuff,
| then I still don't see why not use it.
| sfn42 wrote:
| Because in a professional setting the guy who takes over
| after you also has to know or learn whatever tech you
| chose.
|
| I worked on a team maintaining solutions in React, Vue,
| angular, Svelte, JQuery and more. It sucked. Basically
| every task I ever did there was my first time doing that
| thing with that framework.
| willsmith72 wrote:
| I totally agree, simpler is better. Except for
| extenuating circumstances, teams working anywhere
| remotely close to each other should aim to stick to the
| same technologies and practices. If that's vanilla js,
| sure, go for it.
|
| I'm not arguing everyone needs to move to react. I'm
| saying the opposite. Stick to the tools you know. I once
| worked in a strict java-angular.js shop, and it was
| awesome. Everyone was familiar with the tech and the
| company saved energy otherwise wasted on tool-related
| decisions.
|
| My point is this
|
| > it is more of a flex in this SPA era to show you know
| how to make a website the old-fashioned way.
|
| is not valuable to me at all. If I were giving advice to
| a new programmer, I'd tell them learn the basics first,
| like your html, js, css, and then familiarise yourself
| with one of the frameworks. Then if you want to build
| your portfolio, build it in whatever you like, but for
| people at that level, it can be a great chance to
| practice and show off their skills to employers. If
| you're shipping 2MB, who cares.
| aobdev wrote:
| It's not a value prop, it's just a statement of remembering to
| use the right tools. You even mention this yourself, just not
| explicitly, when you say "react app" and "vanilla site". They
| serve different purposes and I've worked with many people who
| do not understand because react is all they know.
|
| Remix is an improvement over react as a framework though
| because you can fall back on native browser functionality where
| the framework will fall short (high latency, slow devices, no
| JavaScript).
| willsmith72 wrote:
| > remembering to use the right tools
|
| 100% agree here. But if I were going to rewrite a whole
| application, I'd need a really good value prop.
|
| > high latency, slow devices, no JavaScript
|
| I don't see why high latency would be improved by remix,
| you're still fetching everything it's just without the
| waterfall. I've yet to see a modern-ish device (going back to
| iPhone 7s) that struggle so hard with rendering that
| progressive enhancement is valuable.
|
| Are there modern devices which are that slow? Or browsers
| without js?
| aobdev wrote:
| > you're still fetching everything it's just without the
| waterfall
|
| It's exactly because of the waterfall. If I have to make 3
| roundtrip fetches, and the latency of each is increased by
| 150ms, then eliminating 2 subsequent fetches will save me
| 300ms.
|
| > I've yet to see a modern-ish device (going back to iPhone
| 7s) that struggle so hard with rendering that progressive
| enhancement is valuable.
|
| I have used an uncountable number of websites that are
| extremely janky, slow to load, and overall unpleasant to
| use on mobile while traveling on trains and busses between
| cell towers. Some of that can be attributed to ads but the
| reality is you don't need SPA's to serve news. Remix is
| cool in that it lets you develop like an app but serve like
| a website.
| PhilipRoman wrote:
| Unrelated note, but I had never heard of the paperfuge, thanks
| for teaching me something new!
| evandale wrote:
| I've tried learning Ember, React, and Vue and have tapped out
| pretty early. Now I'm learning how to build a site using only
| vanilla JS and doing everything from scratch unless I find a
| reason to switch it. I think I'm making decent progress.
|
| I even wrote my own simple test framework that shoves the results
| on the bottom of a page. After adding a few features I decided to
| switch it to Jasmine.
|
| One thing I'm noticing is how often you need npm which I find
| very annoying. How is a JS library or framework anything more
| than a single JS file that you have to include in your page? Why
| is everything npm this and yarn that? Jasmine has standalone
| install instructions that are easy to find but I can't say the
| same about Jest.
| sfn42 wrote:
| People use package managers because it lets us find everything
| in one place, install it and keep it up to date easily.
|
| I'd much rather do `npm i whatever` than having to hunt down a
| bunch of git repos and copying files over and when they're
| outdated having to do the same thing to update them etc.
| osullivj wrote:
| Ditto on Ember, React, Vue and Elm. Was a jQuery minimalist,
| nut now moved on to Haxe-HTML5. Yes, it compiles Haxe to JS.
| But the JS it generates maps back to the Haxe very simply, and
| it's straightforward to debug in Chromium dev tools. There a
| nice declarative XML system for widget layout. It's up to you
| to choose how much you do declaratively, and how much in .hx
| code.
| gochi wrote:
| I'm confused by this, why do you think npm is needed? It just
| acts a central repo, you're free to self host the JS file
| yourself or pump it through a CDN.
|
| Jest is a different story, it's not a single JS file and has
| many dependencies. Running it globally is an easy way to reduce
| the need to include it per project.
| codampa01314 wrote:
| > My portfolio needs to be nothing more than the HTTP equivalent
| of a tri-fold brochure.
|
| My concern here is that your website _is_ your portfolio -
| including how you build it. It's not just the content and long
| narrative that's going to sell you. This new approach has
| switched from showing what you can do to telling what you can do.
| zeroonetwothree wrote:
| Yes you don't need React for a static site. Is this news at this
| point?
|
| Also I find the colour scheme hard to read but maybe it's just
| me.
| foobarbecue wrote:
| I like the colors. It's readable for me and it reminds me of
| sherbert.
|
| edit: hm, she says it's a yaki imo / satsuma imo color theme. I
| love yaki imo.
| camillomiller wrote:
| [flagged]
| willio58 wrote:
| React isn't complicated. It's not even considered a
| framework, it's better described as a library!
|
| It's a great way to templatize your code. Is it the only way?
| No. Do you even need to templatize your code? No.
| quest88 wrote:
| Stop it. You know what they mean.
| willio58 wrote:
| I guess I don't? Are you referring to the framework
| comment? Next.js is a great example of a react
| _framework_. It's opinionated, it provides tools to make
| a fully-fledged website. If you just drop react into a
| site with a script tag, you get what react offers. You
| get a way to manipulate a virtual dom and render
| components.
|
| Instead of saying "you understand what they mean", please
| give an example of how I mis-stepped. I don't want to
| come off as antagonistic for no reason.
| eropple wrote:
| "What they mean" isn't correct or reasonable and is
| largely part of the same grumbling groupthink that
| willfully refuses to come to grips with the realities of
| the tools they've decided they don't like.
|
| React is not large, is of moderate complexity (most of
| the complexity of "a React app" lives well outside of
| React itself), and can be stripped down to a fully static
| templating language without much effort. As I've linked
| elsewhere, I turned React into an email templating engine
| once because I don't like Handlebars; rendering JSX as
| static, no-JS HTML is a one-liner when you throw it a
| React component.
|
| Using React for a static website is totally fine.
|
| So is not using it.
|
| Being _weird_ about it is not fine.
| camillomiller wrote:
| One's free to code their portfolio in COBOL if they find
| a way to do it. It's the underlying narrative of the "oh
| look, there are things called HTML + CSS + JS that work
| so well and they're even faster" behind this kind of
| posts that tbh makes them quite insufferable.
| eropple wrote:
| Agreed--it ignores that JSX, even baked statically, was a
| pretty nontrivial life improvement for front-end
| development because you got to get away from text
| manipulation as a first-class citizen.
| yitianjian wrote:
| My hot take: there's a general feeling of looking down on
| "web devs" or UI/front-end stuff. It's not really
| necessary to have React for a portfolio site, but it's
| not really an issue if they do.
| eropple wrote:
| I wouldn't consider myself a frontend developer--I've run
| infra teams, built backends, built desktop applications,
| all that too--and I'd definitely agree with that.
|
| There's a lot of strange smugfacing about using fit-for-
| purpose tools that translates into the shitting on people
| by the old-at-heart and the underinformed. Like, stepping
| away from JavaScript for a second, you still see people
| getting mad about C++ on HN and defending the use of C
| outside of a micro because "just be a good programmer"
| even though maybe a few dozen such good programmers have
| ever existed. It's very weird and it's one of the things
| about this profession that bothers me a lot.
|
| I am fortunate that I have reached a place in my career
| where I can simply refuse to have that sort of person on
| my team.
| tremon wrote:
| This happens rare enough that a news event may be warranted
| though.
| karpour wrote:
| I'm baffled by how how many web developers have the attitude
| of "React projects are too complex, let's put another layer
| of abstraction on top of React to simplify things". Of
| course, usually for things that should never have been React
| to begin with. Anyway, good for that guy that he discovered
| Vanilla HTML and CSS late in his career, but I also don't see
| how this is front page worthy.
| camillomiller wrote:
| My comment even got downvoted. There's certainly some React
| diehards around I guess who really don't want to hear that
| their overconvoluted approach could be simpler and leaner
| 95% of the time.
| cmrdporcupine wrote:
| Your comment is likely downvoted because of tone, not the
| sentiment.
| camillomiller wrote:
| Ever heard of "being ironic"? I will never fully
| understand such a devoted stance on policing tone.
| Especially when the comment is not even half as harsh as
| half of the other comments that pile on, even calling
| this post unworthy of the home page.
| arrowsmith wrote:
| her craft
| BiteCode_dev wrote:
| You don't understand, it's the future !
|
| https://www.bitecode.dev/p/hype-cycles
| SkyPuncher wrote:
| I use React for static sites and really enjoy it.
|
| * as it's simplest, it's a really easy to use templating tool.
|
| * there are a tools that compile to mostly static HTML, so not
| performance hits
|
| * theres almost always something that pushes you to want some
| JS. React is handy to have. It also opens the door to all of
| the the community packages. No sense to re-invent the wheel.
| arrowsmith wrote:
| > Is this news at this point?
|
| If you started your career in the last 5-10 years then yes, it
| might be news.
|
| An entire generation of web developers has been trained to
| think that every app big and small needs to be a convoluted
| SPA. The results are a disaster.
| PrimeMcFly wrote:
| You think they would have discovered Flask or something
| similar just out of personal curiosity.
| bdcravens wrote:
| I think a culture has been created where anything
| resembling server-side rendering (other than Node spitting
| out JSON) is legacy to be avoided ..... until of course the
| Javascript creates its own convoluted version of server-
| side rendering, which is revolutionary and the new hotness.
| PrimeMcFly wrote:
| I'm not really in webdev, although I still do django
| sites for people sometimes, amazed and glad I had no idea
| that's how things had gone.
| satvikpendem wrote:
| The main benefit to JS being used as a server side
| rendered and client side rendered language is that you
| have a lot more control over which parts you want on the
| server vs the client, and you can introduce hydration
| where needed. You technically could do that in PHP and
| other non JS languages but that's annoying because you'll
| be mixing multiple languages together and it would be
| more clunky. So yes, there is some "revolutionary"
| benefit to having everything in JS/TypeScript.
| eropple wrote:
| "A convoluted SPA" is fully orthogonal to React. If you're
| making a blog into a SPA, that's a you problem. It's been
| possible (and recommended for many things!) to just bake a
| static website with React and use JSX as a templating
| language for a long time.
| arrowsmith wrote:
| Why would you need JSX for a static website? If you need JS
| then it's not "static".
| post-it wrote:
| Generally, a static website refers to any website where
| the server just serves files rather than running
| application code for each request. JS runs on the client.
|
| For example, I've been working on a character generator
| for the Inquisitor tabletop game. It's completely static
| because I just SFTP the build output to my webserver, but
| it uses React and JSX.
| codethief wrote:
| You're missing OP's point. The website can be fully
| static (even without any JS) but you could still use
| JSX/React to generate it (during build time, not
| runtime).
|
| If you've ever had to build a static website from
| scratch, with the same navigation, footer etc. _on each
| page_ , and without using frames, then you'll appreciate
| the amount of work that a templating engine saves you
| (whether JS-based or else).
| ehnto wrote:
| I think you all missed GPs point, JS is barely required,
| let alone an SPA framework, let alone static generation
| in an SPA framework, etc.
| c-hendricks wrote:
| And you're missing the other GPs point. Even when
| building a static website, you might want to reuse
| components. Or use shared components. Or do some logic.
| Or easily compose things.
|
| Note they said "JSX as a templating language". Why worsen
| the experience using Python + Jinja when you're just
| building a static site.
| zwily wrote:
| Static doesn't mean no JavaScript. Usually it means it's
| not rendered on the server.
|
| Every time i start making a static website, i end up
| needing to include a table (or some other structured
| display of data) and then just switch to JSX to render
| the data with a loop. Sometimes i then render it as html
| and deploy, and sometimes i deploy it as react. But
| that's how i usually end up using React even when static.
| satvikpendem wrote:
| Indeed, static just means that the site files can be on a
| CDN and not need to change. Technically, SPAs are also
| static, if they spit out pure HTML, CSS and JS files that
| you can put on a CDN.
| ylyn wrote:
| You can render JSX at build-time. So it's just a
| templating language, as the parent comment said.
| eropple wrote:
| React is completely happy to spit out a DOM tree as HTML
| for you; wiring up the in-browser JavaScript side of
| React is optional. This is how static site generators
| like Gatsby or NextJS work (with some hacks that as a
| user you don't really care about) and (eliding some
| detail) how React Server Components now work generally.
| I've also used it to generate email templates[1] with
| some success, too.
|
| I use JSX because it's a nicer templating system than EJS
| or similar. It allows me to write components to
| encapsulate reused fragments rather than text
| manipulation. And I like it, which counts for something.
|
| Candidly, this is something that people who fulminate
| about React probably should know before they start
| talking.
|
| [1] - https://github.com/eropple/rx-mailer
| Capricorn2481 wrote:
| Obviously there's a spectrum. A static website just means
| the files are served statically from a folder, and
| routing is just the folder path. You can still serve JS
| files and have a static website. If you put an alert on a
| button, you're not suddenly a SPA
| eropple wrote:
| It's more than that: you can just call methods in
| ReactDOMServer to get a DOM tree. The tools to wrap this
| vary widely; you can use Gatsby (ehh) or NextJS (yeah!)
| to do it if you want a full-featured framework around all
| of it, you can use something like react-snap if you want
| something simple and less all-in, or you can just call
| them yourself and plop some files in a build directory.
| bdcravens wrote:
| You use JSX the same way you'd use PHP - it just compiles
| into HTML. In this case, you just save the output after
| compiling it once. (as you can with the dozens or
| hundreds of non-JS options that do the same)
| bdcravens wrote:
| It's also been possible for 30 years to do the same with
| languages like PHP, ColdFusion, etc, no build steps
| necessary, and HTML is your "templating language".
| robertoandred wrote:
| PHP pages absolutely have to be built/rendered.
| paulryanrogers wrote:
| I think the distinction is that PHP is interpreted in
| real time most often. So there is rarely a separate build
| step.
| satvikpendem wrote:
| Sure, I like TypeScript and componentization though which
| JSX can give me where PHP doesn't. Most templating
| languages are dynamically typed.
| eropple wrote:
| You totally can, but for my money that's kinda not great.
| Because HTML isn't your "templating language", PHP et al
| are, and you aren't templating around the DOM with typed
| objects, you're templating around _text_ with all the
| pitfalls that entails. Object structures save time,
| reduce errors, and give you more to-the-programmer
| natural tools for composition and reuse (just call a
| function that returns a JSX object! give it typed
| parameters! declare victory and go have beers!).
|
| I wouldn't go back to doing text manipulation to generate
| HTML, because I value not having to make sure I've
| escaped all my quotes.
| bdcravens wrote:
| PHP, ColdFusion, etc allows you to intermix HTML and
| variables without doing the type of escaping you're
| describing.
|
| For instance, CFML:
|
| <ul> <cfoutput query="people"> <li>#firstName# #lastName#
| </cfouput> </ul>
|
| You can also write classes that return data and custom
| tags that return rendered html.
|
| <cf_PeopleList queryObject="#people#">
|
| I'm not saying we need to go back to those languages
| necessarily, but I think there's a ton of misconception
| about how those languages can be used, and quite a bit of
| reinventing the wheel in the Javascript world.
| eropple wrote:
| Sure, of course you can in some contexts and with many
| asterisks (though in PHP it is _literally_ text munging
| and that 's what you get).
|
| But even, granting your correction: in the CF example
| you're writing representation and logic in two separate
| contexts. JSX does not do that. JSX _is JavaScript_ and
| the constructs that JavaScript provides work without fail
| with the constructed trees (which need not be DOM trees,
| e.g. react-three-fiber) you 're generating. It puts a lot
| of strain on the assertion that you must-repeat-must
| separate these concerns, which hasn't been materially
| true really at any point in my career all the way back to
| JSP or Velocity templates where (much like ColdFusion)
| you had _worse_ tools for one context than you got for
| free with the other.
|
| While JSX and something like CFML (or hell, Angular) look
| similar when you squint, this is a different _thing_. The
| closest equivalent is something like Scala or Visual
| Basic XML literals, which never took off; JSX is no-
| bullshit a step change in consistency and productivity
| and it 's awesome.
| uxcolumbo wrote:
| It's not just you.
|
| The site has poor contrast ratio - fails all accessibility
| guidelines for text contrast ratio requirements.
| revskill wrote:
| No, React with webpack/vite is simpler than "your handcrafted
| static site generator".
|
| I don't have to use any of Hugo, Jelkyll,..., because i can cook
| my own SSG toolkit right inside React.
| Alifatisk wrote:
| It's a portfolio, is js really necessary?
| lisasays wrote:
| Javascript is the new Python in many shops.
|
| So while one doesn't have to know JS, it will definitely get
| you through a lot of doors. And not knowing it, or being too
| stubborn to keep your skills in it polished will keep you in
| the doghouse.
| password54321 wrote:
| Recently tried no framework, Jekyll, Next, Astro and finally
| SvelteKit. The only one I liked was SvelteKit.
|
| Not interested in reinventing the wheel (no framework), dealing
| with lots of boilerplate and over-complication (Next/React) or
| using multiple UI libraries (Astro). SvelteKit is a fine balance
| between simple and providing enough functionality that allows me
| to focus on generating content with minimal friction.
| eimrine wrote:
| Can I write a React app and recompile it as a vanilla? For
| example to take all involved parts of the library and not take
| the rest.
| wooly_bully wrote:
| This is what Svelte does, React has a runtime even when bundled
| llanowarelves wrote:
| Is that like Astro?
| eropple wrote:
| That doesn't really parse. React _as a thing_ is some pretty
| thin DOM manipulation and some helper stuff. Are you thinking
| of something like Next or some all-in React+Redux stack?
| willsmith72 wrote:
| You mean a normal react build?
| naillo wrote:
| The reason react was developed is mostly null at this point.
| Modern javascript is so fast and plesant it's hard to imagine
| many real reasons you can't stay entirely within vanilla.
| post-it wrote:
| I find state management to be much easier with React. "All
| state is lost by default when any variable changes" is a
| fantastic starting point.
| andsoitis wrote:
| React wasn't created because JS is slow, but rather to
| streamline and speed up DOM operations.
| quest88 wrote:
| That statement indicates you don't know why react was
| developed.
| cj wrote:
| > That statement indicates you don't know why react was
| developed.
|
| Why was it developed?
| papichulo2023 wrote:
| Hint: it was not because the performance nor the JS
| language limitations. You can google the rest.
| cj wrote:
| I am friends with the original 2 React founders who I met
| at facebook. I don't need to Google, I'm asking because
| the comment was lacking substance and wasn't adding value
| to the conversation.
| tjoff wrote:
| * [...] brought to you by vanilla everything. No Javascript
| frameworks, CSS libraries or flashy animations. [...] *
|
| Proceeds with a distracting animated image of the old portfolio,
| thought that was funny.
| beej71 wrote:
| But not flashy! :)
| bdcravens wrote:
| Many of the comments suggest that of course you wouldn't use
| React for a blog.
|
| Someone forgot to tell these folks:
|
| https://buttercms.com/blog/how-to-create-a-blog-with-react/
|
| https://www.sanity.io/guides/build-your-first-blog-using-rea...
|
| (and many more)
|
| I'm firmly in the camp that React and similar frameworks are
| overused. However, the point is that there's a large part of our
| industry that is bought-in (and in many cases, built businesses
| around) the concept of "React all the things" and it's
| encouraging to see push back.
| microflash wrote:
| I'm glad this works for them. Personal websites and portfolios
| are a reflection of people on their journey. If it is built with
| React, maybe they are learning React. If it is vanilla JS, maybe
| they appreciate the flavor of vanilla.
|
| Instead of making sweeping statements about the choice of stack,
| I appreciate that someone took their time and built something of
| their own. Congrats. Next thing they should do is an
| accessibility audit and learn from it.
| awestroke wrote:
| React is a great tool for building complex, large applications.
| Your blog is not large or complex.
| bdcravens wrote:
| Even many sites that are large and complex would benefit from
| being a server-rendered app. I've come across way too many
| sites that break in bizarre ways, and all they are doing is
| displaying text or HTML forms. Every time I check, they are
| React or Angular sites.
| arrowsmith wrote:
| It's barely even an "application". The entire thing could be
| rendered as static HTML.
| aczerepinski wrote:
| I built my simple site with just Go, no libraries of any kind.
| Two years later it is such a dream to never ever have any
| dependency chores to do.
|
| Before that I had a Phoenix site and I feel like every time I
| touched it (months apart) I had to update something.
|
| Not such a big deal at work where monitoring for security
| vulnerabilities and updating dependencies is paid work that we
| make time for but I hate that kind of busy work on my own time.
| JohnFen wrote:
| I think this is a pretty awesome statement. I'm always
| unreasonably pleased when I see a web page that embraces
| appropriate simplicity.
|
| > Coding a basic vanilla multi-page application (MPA) saves time
| in development (goodbye babel/postcss/SSR config) and builds are
| fast (this site builds in less than 1.2 seconds).
|
| I'd hope that builds would be on the order of a small pile of
| milliseconds! (or zero: a site like that could just be handcoded,
| really).
|
| > I'm only using these 2 lines of Javascript to add the current
| year in the footer copyright tag
|
| This could also be eliminated. At least in the US, there is no
| legal reason to add a copyright notice at all, and you certainly
| don't have to add a year. Those requirements were removed years
| ago.
|
| But, if all you want is the year, why not do that server-side? Or
| bake it into the html and set up a bit of automation to replace
| the year with a new one every Jan 1.
| beej71 wrote:
| > why not do that server-side? Or bake it into the html and set
| up a bit of automation to replace the year with a new one every
| Jan 1.
|
| In this case I think I'd argue that the JS solution is the most
| simple to implement+maintain.
| sfn42 wrote:
| This is what Js is good at. It sucks for building actual
| systems but it's fine for small stuff
| robertoandred wrote:
| There's zero need to set up babel/postcss/SSR. Those have all
| been handled by frameworks for years and years.
| jallen_dot_dev wrote:
| Is it even correct to automatically update the year? Shouldn't
| the year be whenever the work was created or revised? Which
| could be set at build time.
|
| Another advantage of setting it in the build is it'd show even
| without javascript. If I disable JS, no copyright statement at
| all appears on the page. So if it was really necessary to
| declare your copyright, then would it mean anyone who disables
| JS can freely infringe?
|
| I agree just leaving the copyright out of the footer would be
| best.
| terminatornet wrote:
| I think it's also incorrect because it's getting the date
| client side. so it would just display the local client's
| year, not necessarily the correct one.
| adregan wrote:
| I am of the opinion that what you are suggesting is correct.
| You don't want a programmatic copyright because you want the
| copyright to reflect the date created as that when the right
| begins, and it continues from there without need for
| refreshing.
| [deleted]
| degun wrote:
| Jumping on the React hate train has become a trend these days,
| but it still has its place.
| bdcravens wrote:
| It has its place, but there's no shortage of React sites where
| it's misplaced.
| thiht wrote:
| Of course it has its place. Not for a blog though, it makes no
| sense
| degun wrote:
| You can achieve very good results with Next, by using SSG,
| SSR and ISR. That implies being very comfortable with React.
| Otherwise there's tons of solutions for a blog scrnario.
| pwdisswordfishc wrote:
| React hate train has its place indeed.
| shmde wrote:
| Shitting on React is one of the easiest way to reach the HN
| frontpage.
| carlossouza wrote:
| > I became a dev when everyone was hiring for React, so React is
| what I taught myself immediately after _bootcamp_ in the scramble
| for a job
|
| A better education path (in a bootcamp, university, book,
| youtube, whatever) would start with the fundamentals and build it
| from the ground up... not the other way around.
|
| (I just realized how lucky I am for being taught in the best
| possible order, from the ground up... first the basics... and how
| so many people didn't have this opportunity)
| syx wrote:
| I think most of this comes down to the fact that these
| bootcamps are there to freshly bake people to work on the
| latest shiny tech completely ignoring the basics of computer
| science. I, like yourself, was very lucky to attend a
| university course that gave me exactly those fundamentals.
| bdcravens wrote:
| I think there's a place for what are essentially factory
| workers: taught specific skills for specific jobs. The
| problem is I think most don't understand the trade-offs and
| have unbalanced expectations.
| beej71 wrote:
| I worked at a boot camp that started off CS-"heavy" (relative
| to other boot camps). Unfortunately, they gradually just
| turned into a React shop to try to maximize profits. There
| were students who had been in the program for 4 months and
| couldn't write FizzBuzz. The placement rate was poor because
| students couldn't do technical interviews. I understand this
| particular company has made improvements since then (I've
| left), but it was fucking grim at the time. I now teach at a
| state university.
|
| But yes, to anyone in a boot camp, get yourself some Khan
| Academy or whatever you need to get the fundamentals. This is
| an art, a science, and a craft, and you need to study to show
| your pride in that craft.
| mettamage wrote:
| Not always. The bootcamp I worked for did 2 months of pure
| HTML/CSS/JS and then did a personal project for another month
| of which students almost exclusively used HTML/CSS/JS, some
| did React. Only in the final week did I teach React.
|
| This was around 2017, most students didn't become React devs.
| Most students did end up in the JS ecosystem, but 30% did
| something else [1].
|
| [1] When I say 30%, that's not an official statistics. It's
| just on my impression what I've personally seen from students
| who connected to me on LinkedIn. It's a guestimate at best.
| majesticglue wrote:
| I disagree. It's like telling someone who is somewhat
| interested in building cars to learn how an engine works before
| having them on the ground playing with the actual car parts.
| The issue becomes not whether they'll learn, it's about whether
| they WANT to continue to learn. Most people when they want to
| start coding, would rather want to build cool things. And then
| later on, they'll naturally be more interested in the
| fundamentals.
|
| I argue that this is why schools are terrible for teaching.
| They try and teach fundamentals without making kids interested
| in the topic first. As someone who taught many kids, the
| struggle is always making them interested, not the rate at
| which they learn.
|
| I remember when I started programming, the worst advice i got
| was on stack overflow, that I should learn from this thick c++
| textbook as a start... Wasted couple months on that book, where
| the concepts went through one ear and out the other, became
| extremely disinterested. Only until someone told me to just
| learn Javascript and build things was when I progressed and
| learned rapidly. Took me only a year after that to get a job
| with me becoming interested very quickly on learning
| fundamentals from there. If I kept learning from a book, it
| would've taken me several years before I got to even building.
| It's silly to assume someone who learns from the top down can't
| learn the fundamentals at some point.
|
| Now I've learned game development and currently learning ai on
| the side. I've tried bottoms up learning many times, but it is
| incredibly slow to get my goals. Top down and learning
| fundamentals after you get your hands dirty has been the
| absolute fastest way for me to learn new topics. With bottoms
| up, while you may learn many of the basics, you also happen to
| learn a bunch of extraneous information that you may never use,
| and will forget because you don't use it.
| c-hendricks wrote:
| There's space between "read this giant c++ tome" and "you're
| good to go with a couple of months of React", quite a lot
| even.
|
| From my experience with bootcamp people, it leaves them
| woefully underprepared. But my sample size is small: 3
| people, 3 separate bootcamps, similar results. They knew one
| portion of react, no fundamentals.
|
| And sadly a couple of them really took to using Copilot. So
| they don't know how to do what they're doing and couldn't
| explain their submitted code.
|
| Just the worst of all worlds there. They were effectively
| incredibly expensive Copilot subscriptions (not to belittle
| them, they did that themselves)
| majesticglue wrote:
| definitely.
|
| I just think for some, bottoms up learning has quite some
| disadvantages and was an approach that I've used for a long
| time with okay results. It would get me to where I wanted
| to be...but it takes way too long sometimes.
|
| Of course there are people like you mentioned though who
| only do top down learning but just never go into learning
| the fundamentals ever, which is another problem in its own
| right.
| syntheweave wrote:
| I've gradually taken towards "always learn as if it's a
| sport" as the approach to learning. Which, if you look at
| the sports science recommendations is:
|
| * Isolate highly specific techniques into drills.
|
| * Then go directly to practicing live gameplay. Ignore
| intermediate exercises.
|
| And the approach with programming can, in fact, do this,
| if presented properly: definitely, we know how to isolate
| things into short follow-along examples. What tends to be
| missing is the "live gameplay" element, because it's hard
| to set up sample projects that are complex enough to
| reveal the need for a particular technique.
| agumonkey wrote:
| I have a strange feeling about the industry. It seems better
| received to know a framework 30% (or enough to make
| simple/intermediate things) even if you know next to nothing
| about the underlyings rather than the opposite. If you're an
| ES6 master but can't mesh well with react tasks / react convos
| in daily you will look as less useful.
| Twirrim wrote:
| We had an intern last year, and I got a chance to do a 1-on-1
| with him later on on his time with us. He was looking for some
| insights from the engineer in the org with the longest career
| in tech.
|
| The biggest single thing I think I ended up doing during that
| session was getting him to re-frame his thinking from "I'm a
| React developer" to "I'm a developer", emphasising how all the
| fundamentals remain the same, just the nitty gritty
| implementation changes a bit from time to time. It was
| interesting to watch that lightbulb moment happening with him
| as we were talking, while also frustrating that the bootcamp
| etc. training he'd been through had so fundamentally set his
| thinking up wrong from the outset (since had a few more interns
| that came via different bootcamps, and it has been the same
| story with each!)
| tzhenghao wrote:
| Yeah, I was just chatting with another principal eng friend
| recently where maybe a whole new generation of programmers may
| be several degrees away from topics like operating systems,
| compilers, computer security and networking.
|
| Once in a while, (lower level) software needs to be rewritten
| as underlying invariants go out of fashion. Think filesystems
| due to hardware access patterns etc. - to unlock magnitudes of
| performance improvements. The scary part is maybe we'll never
| have enough programmers to know how to do "the hard stuff"
| anymore. I hope I'm proven wrong though!
| pc86 wrote:
| This is sort of a FUD argument IMO. There will _always_ be
| people who focus on low level software engineering. There
| will always be people who want to learn about the hardware of
| computers much more than the software. Proportionally there
| will almost certainly be less (we don 't need nearly as many
| computer engineers as we do software engineers) but as long
| as the salaries remain competitive there will be plenty.
| bdcravens wrote:
| For me, coming online in the late 1990s, I've never experienced
| as much "education density" as I did when learning HTML to
| build sites on Geocities. For those who didn't experience that,
| circa 1997, you could either upload files or write HTML in
| nothing more than a textfield. No highlighting, no WYSIWYG, no
| page builders. Just you and a blank canvas (if you were lucky
| you might use an editor like Homesite or HotDog)
| zhte415 wrote:
| It was also a time of DIYing shopping carts in cookies,
| forums all about getting payments working, and what's HTTPS?
| Spivak wrote:
| I don't know anyone who has ever learned programming bottom up.
| Now growing with the technology as it evolves is one thing, but
| being taught in that manner is miserable because it's
| unmotivated and the reason for the low level is the high level
| not the other way around. You just use even handlers in JS and
| then when you hit some confusing behavior you dive in at learn
| about how event propagation works.
|
| Nobody learns block how devices work before filesystems because
| it's backwards. Filesystems are the motivation, block devices
| are a means. The processors course in college comes after the
| intro programming and after systems programming.
| augusto-moura wrote:
| It depends on the intention of the person trying to learn. When
| someone is starting and asks to me which language/tech is best
| to start, I always ask, what do you want from learning tech?
| Are you comfortable with X salary? Do you want to make a career
| of it? Go international/remote? Etc.
|
| I had some friends being honest about only wanting some good
| money, not top high, but in comfortable zone, and preferably
| fast, in less than a year. With that kinda of mentality, I
| usually recommend going straight to the most used stack where I
| live, React, Angular or Java.
|
| They are usually just starting and want to feel the waters, I
| tell about the basics and link some online courses. Everyone
| can start on one tech and learn another later.
|
| I myself learned frontend before high school and only had a
| formal education on software years later on college, and now I
| feel like pretty proficient on software as a whole. The answer
| to it, is usually giving some time and experience
| randomdata wrote:
| And that's why learning is best left as an individual pursuit.
| For me, it is always best to start with a complex system and
| then work backwards, understanding the thoughts and decisions
| that went into each step along the way. When I start with the
| basics I don't get a feel for the bigger picture and it means
| nothing.
|
| I'm glad I've only been around the industry for 25-some-odd
| years. We already had many high level abstractions to work
| with. If I were old like you and had to start with flipping
| toggle switches, I'm sure I would have zoned out immediately
| and never progressed further.
|
| I could handle flipping toggle switches now, but only because
| I've been engrossed in the bigger picture thanks to those high
| level abstractions.
| pc86 wrote:
| I hate to break it to you but if you've been in the
| professional world for 25 years, you're old :)
| randomdata wrote:
| Well, yeah, but you'd have to be at least twice my age to
| have been starting out when this tech was in its primitive
| state. Comparatively, I'm still a spring chicken.
| yoavm wrote:
| Agreed, but it's so rare nowadays though. I still remember when
| I saw a junior frontend dev struggling to get some element to
| look differently when hovered in React. They went though loops
| and hoops to style it using CSS-in-JS and mousemove, only
| because they didn't hear about :hover.
| revskill wrote:
| Then what ? That junior dev could produce working software,
| and fix the css issue later (if needed).
|
| Give that "senior CSS developer" a day and figure out how to
| manage state, then what you get is a crap.
| sfn42 wrote:
| Yeah that's gonna work out great when the entire app is
| built using weird overcomplicated solutions to simple
| problems, let's just clean it all up later! Doesn't matter
| how you write your code as long as it seems to work, well
| deal with all the bugs we discover later!
|
| The proper way to do it is to do code reviews and teach
| newbies how to do things like this. Ideally they should
| have asked about it(or just googled) before the review.
|
| I think "well just fix it later if needed" is asking for
| trouble and you're basically just writing legacy code.
| gibbitz wrote:
| Business doesn't fund "fix it later" -- it just becomes
| tech debt. You have to push to do it right the first time
| or approve merges you can live with in perpetuity.
| nicoburns wrote:
| The problem is that if the end state you want is a clean
| codebase implementing your use case, that's also easy to
| modify and extend, then the mess such a developer will
| produce is a much worse starting point than starting from
| scratch.
| gedy wrote:
| My favorite experience with Bootcamp folks was someone who
| came in do an interview, and she could _talk_ , was
| professional, had nice looking blogs, etc. and seemed really
| awesome on paper. However, I had her do a really simple React
| exercise, and she was producing some really strange code like
| using Ruby inside of a JavaScript onClick handler? lol
|
| I think a failing of a lot of these bootcamps is they
| encourage people to present themselves as more experienced
| than they actually are. I don't mind someone who's starting
| out, and has a lot of potential, but please be honest about
| your skill level, as it just disappoints the interviewer and
| misrepresents you.
| nicoburns wrote:
| I think this is an unfortunate side effect of boot camps
| trying to impart best practices on their students. They
| don't really have time to learn and apply the actual
| practice well, but the names stick with them.
| teg4n_ wrote:
| Seems like just lack of experience. You can even do it simply
| with JS with onHoverIn / onHoverOut
| graypegg wrote:
| While that's possible, it's a lot more fault tolerant to
| use the declarative :hover rule, than it is to handle it
| procedurally. The browser knows how to handle odd pointing
| devices, touch states and won't ever have to deal with
| uncaught errors in a mouseover/mouseout event.
| teg4n_ wrote:
| for sure, was just an example that there are apis, that
| could have been reached for even without CSS knowledge
| that would make it easier than trying to get the position
| of the mouse on the screen, the position of the target
| element and if they overlap
| [deleted]
| Timon3 wrote:
| There is no onHoverIn or onHoverOut in JS.
| teg4n_ wrote:
| yeah sorry that's the react-native equivalent. you could
| use mouseenter / mouseleave events
| city41 wrote:
| My website is also completely static, but made with React. That
| means no React at all at runtime, it is completely static. React
| does not automatically mean dynamic. I get all the benefits of
| both. I love the flexibility nextjs provides here.
| embit wrote:
| Yes this is correct. It's perfectly possible to build purely
| static website by react and nextjs
| asynchronous wrote:
| NextJS really does feel like a featherweight React in all the
| best ways
| SkyPuncher wrote:
| I love React as a templating language. I find it very easy to
| use since JSX is very close to actual html.
| [deleted]
| madeofpalk wrote:
| Author made a two page static website without React. Okay?
| Congrats?
| lisasays wrote:
| Actually, yes. The conventional wisdom these days is to do
| everything in React (or something similarly bloated).
|
| Because, you know, users just love seeing a bunch of grey boxes
| shimmer and dance on a white background for several seconds
| before the magic really starts to happen.
|
| So any exercise which demonstrates that there just _might_ be
| an alternative to this philosophy should be applauded.
| madeofpalk wrote:
| I don't think this is the "conventional wisdom"!
| hereforcomments wrote:
| I've just joined a team recently and had a chat with the
| head of product. We will work on a tiny internal app, it
| has 3 pages: sso login page, Excel template upload page
| where earlier uploaded templates are shown as a card and if
| you click on them it opens a dashboard: a map with markers,
| a bar and a pie chart. This is the whole thing.
|
| This guy asked what we will use in the front-end. I said
| react and he was like "amazing, good job, it will be great"
| and the talked about we should always use react. So yes,
| there are places where react is used without question.
|
| Also, we will use snowflake as a backend while indexing
| would make everything a lot faster and the budiness logic
| is done by 800+ line sql (stored procedure).
| WesolyKubeczek wrote:
| Is it fashionable now to make a site like almost every site used
| to be in 2008 and wear it as a badge of honor?
|
| P. S. Needs to be even more garish. Remember the "space pigs"
| theme of FastTracker II? Man, those were the days.
___________________________________________________________________
(page generated 2023-07-15 23:01 UTC)