261–270 of 319 posts
Earlier quoted context omitted.
Yes.
Can you link me some docs? I would love to see how the modern tools I learned at my outset compare to the classics.
Earlier quoted context omitted.
> So your point is that you don't really know, but let's blame them for trying, or what? I think GP's post is that _you_ don't really know the landscape which was why you reinvented the wheel, which I tend to agree with. You even agree with this unless you're being rhetorical here, no? > Which functionality? Let's take a look at every feature we see on the next.js page ( https://nextjs.org/ ): Zero Config Automatic c…
That is a good list. Have you heard about ClojureScript? Obviously, TypeScript is not supported, but everything else is. > How long do you think it will take to incorporate them into your new tool which you just rolled from scratch? Here is the news: we will never add them to the new tool. No TypeScript, no compilation, no routes, nothing . > If I am your CTO Good news you're not, right?
I think that's part of the issue. You have built something outside of an ecosystem. Have you planned for what will happen after you leave? Have you been on the receiving end of inheriting a codebase written in a language (like ClojureScript) that was buzzy for a while but then never took off? It happened to a lot of people with Coffeescript.
> Good news you're not, right?
Are you sure that's good news? Because what I see here is a poor choice of a niche language (ClojureScript) which lacks traction and will probably die long term. Moreover, because it lacks an ecosystem (or more accurately, that ecosystem is not the exact flavor you want), you've taken liberties to write things completely from scratch. Why not use Next.JS? Why not use Rails + Turbolinks? Why not reconsider writing crucial infrastructure from scratch when it already exists in many forms? Most damningly, why should you be trusted to reinvent the wheel if you lack the patience or thoroughness to go through previous solutions to this problem and put together a convincing argument for why they fall short and you need to make something new?
These technical decisions around infrastructure, stack and ecosystem are ticking time-bombs. They are almost certainly a long term technical risk and an eventual roadblock to recruitment/onboarding. I think it's unfortunate that you have wasted your time reinventing problems that have already been solved instead of focusing your talents onto areas which deliver more value to your customer. As you are working on e-commerce, this could be anything from marketing and demand acquisition to checkout funnel conversion to fulfillment, up-selling and cross-selling.
If your organization's leadership incentivized engineers to seek these kinds of investments, it would probably result in you choosing a stable stack (which, while imperfect, is good enough, has a larger ecosystem of maintainers than just the company, and so has less of a risk of blowing up in a few years) so that you could focus on investing into more customer-centric engineering. It's a shame because I think that this kind of engineering is the kind that helps engineers grow and mature in seniority. It gives them the capability to become technical and people leaders, who are exactly the kind that most companies that employ leaders need to have.
But that can never happen when engineers don't develop the judgment to determine which problems are strategically valuable to the business and which ones amount merely to overhead. And of course, many companies see no need to invest in or to empower their engineers this way, so this kind of thing keeps on happening because you need to work on something stimulating or what would be the point of work? Feel free to disagree, but based on what I've seen, I think you are working on the latter. I guess all I could ask you is imagine what kind of amazing results you and the company would see if you focused all that incredible energy you put into this infrastructure into delivering customer value!
Earlier quoted context omitted.
If you don't need a rest API, all it does is make everything far more complicated, i.e. every page now has two end-points, one for the html, one for the data. It's trivial in most web frameworks to have an endpoint respond in two ways, one with all the html including head, menus, footers, etc. if you hit it with a GET, the other just the snippet if you hit it with an Ajax request. A REST API is basically a massive ov…
Fair points. A couple of notes though - intercooler needs two endpoints as well. One for the page, and another for any dynamic HTML. I mean I switched from jQuery to knockoutjs to react all on one application and the API served all those transitions well. So I'm speaking from personal experience here. But that is anecdotal and maybe it's not typical.
Earlier quoted context omitted.
Can you link me some docs? I would love to see how the modern tools I learned at my outset compare to the classics.
google.com
They followed it up with a 1-word answer - pretty ridiculous if you ask me - and so I asked an expanding question so I could make my own conclusions of what the other user considers to be acceptable levels of composability and reusability.
While I could undoubtedly find that info myself, I am not the one advocating for Rails here, nor am I the one claiming using Ruby for browser interactivity is a strong idea, so it seems to me like the onus isn't really on me to go search this out
Earlier quoted context omitted.
On top of that, js animations are still better for controlling timing and events or for a more realistic natural motion (springs instead of timed easing).
I would say that what JS animations are even better at is justifying inflated budgets of the projects made for people who are not very familiar with tech. Is there ever a real reason for animations that doesn't make the interface feel sluggish and unresponsive? In the other hand if you actually set the animation delay to something incredibly low, all of your animation needs could be easily solved by animating the tra…
If you take the time to adopt a technology and understand the pros and cons thoroughly you will not be doing any throwing away. You may end up not adopting the tech if its cons are not acceptable in your scenario but you wouldn't be adopting it then throwing it away.
On HN, we see two extreme patterns:
1. Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY https://saagarjha.com/blog/2020/05/10/why-we-at-famous-compa...
2. Why we dumped $HYPED_TECHNOLOGY (https://solovyov.net/blog/2020/a-tale-of-webpage-speed-or-th...)
It's good entertainment (for some) but in the same way that mainstream media manufactures drama.
:/
Most people here are criticizing the author for doing some dumb things. I concur, but still think they have a good point. First, keep in mind that the author's use case is a content-heavy app with sprinkles of interactivity. This is very important because it sets the "webpage speed" goalpost to a concrete place: they want good lighthouse/first load times and good SEO. I've fallen into the same pit before. I've used C…
React supporting selective hydration would potentially be a total game changer. I have recently started using gatsby-plugin-no-javascript. It's a very crude version by removing hydration at the page level. It works pretty well for me because my site is a ton of static pages and then one very interactive app page. I get to build it all in React, get a great developer experience, and then all those static pages are lik…
Thank you for mentioning this! I’ve been on a passive search for exactly this: the ability to use React and generate a completely static site without even the possibility of JS at runtime.
Earlier quoted context omitted.
+1 to this. I wanted to build a private blogging app/site with a big focus on speed and performance, it might not be popular anymore but I went with Rails. Server-side rendering lets the browser do what it's good at. The only thing that would make pages load faster would be to stick them behind a CDN (which doesn't play nice with the privacy aspect). If anyone is interested I put up a page talking about the project:…
See but the parent comment is about "web applications" not "web pages". You are describing a web page - there is limited or no interactivity, what is there can be reasonably handled by forms. No one doubts that React isn't the tool for this area
As for web app vs web page--it's a very blurry line, and it's rare that I end up building something where the entire site could be considered a web app. Usually only some small pieces of it demand enough interactivity to bother with the complexities of using a UI framework, and for that I wrap a small React or a Svelte app in a div and throw it on a page within the larger site.
Earlier quoted context omitted.
This site also has almost no state at all per-user.
Every time you collapse a thread, that's saved on the server. Then, if you return to the page, it will render those threads collapsed. So that's a decent amount of state.
Earlier quoted context omitted.
If you're truly having issues with CSS and rendering different sizes, I'd recommend taking the time to really learn CSS inside and out. I find it incredibly simple nowadays to do both Mobile/Desktop (+Tablet) with CSS and media queries. I may have agreed with you in the past, but not so much anymore.
There are still some things that are impossible to achieve with CSS alone, even if you have the luxury of only needing to work with evergreen browsers (remember we are speaking of content-heavy sites here, which are the most prone to still have to support older browsers). Example: I have a stack of boxes of varying heights. On mobile they are fine as is (one below the other). On tablet I want them in two columns but…