Live data from Hacker News

Bleeding-edge tech will kill your startup

contrast.app

171–180 of 196 posts

Re: Bleeding-edge tech will kill your startup

#171

Earlier quoted context omitted.

> Yeah, it's kind of like the classic "break one law at a time" rule. If you're hauling drugs, don't speed. Getting away with just the one thing is hard enough. I wonder if not speeding is enough to give police officers a reason to make a drugs search in some places.

Lol. Czech here, I was stopped by the police once in the night on an empty 4-lane road doing exactly the speed limit. They breathalyzed me, looked at the zero and one of them said: "you know, when someone keeps the limit at midnight on this stretch of the road, they are usually drunk".

and you said: Why would I drink when I have 50 Kilos of coke in the trunk that would be stupid.

Re: Bleeding-edge tech will kill your startup

#172

Earlier quoted context omitted.

https://github.com/KaliedaRik/Scrawl-canvas

Haven't had a chance to look at the code yet, but how did you address responsiveness? It took us a long time when writing chart.js to get that working well on with different browsers, devices, and screens (high resolution screens require extra code)

First: chart.js[1] is an excellent library. If people need to add chart infographics to their website I strongly recommend they use a dedicated charting tool (like chart.js) rather than my library.

Like you, I've had to do a lot of coding and experimentation to get responsiveness working the way I think it should work. Much of it runs off the idea of drawing everything to a hidden canvas and then copying that canvas's contents over to the displayed canvas as the last step in the display cycle. I tried to mimic this functionality on the CSS object-fit property[2]. If you're interested in the code, you can find it here - https://scrawl-v8.rikweb.org.uk/docs/source/factory/cell.htm...

The other thing I've done is to introduce relative positioning for drawing stuff on the canvas. The native Canvas API drawing functions expects coordinates etc to be in absolute value pixels; my library allows coders to define positions and dimensions in String percentage values which will update (via dirty flags) each time a change in the canvas dimensions is detected.

Caveat: my library has not been tested (as far as I'm aware) across a wide variety of browsers and devices. I expect there will be plenty of improvements to be made once that happens.

[1] - https://github.com/chartjs/Chart.js

[2] - https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit

Re: Bleeding-edge tech will kill your startup

#173

Earlier quoted context omitted.

https://github.com/KaliedaRik/Scrawl-canvas

jQuery community has lots of different extensions. I searched 'jquery canvas' and this popped up: https://projects.calebevans.me/jcanvas/docs/text/ I'm not sure you have a 'product' you just have a library.

There are a number of excellent libraries ('products' - I use the terms interchangeably) dedicated to making development with the element a lot easier; they all have a strong basic use case because coding scenes using the native Canvas API is very low-level, repetitive and easy to get wrong. Some of my favourites include Fabric.js, Konva and Pixi.js.

Re: Bleeding-edge tech will kill your startup

#174
This is the kind of thing someone might be offhandedly curious about, but no leadership is going to sign off on paying for a solution. At best some IC in the right position will add some instrumentation in the right place for a quick win. No one is going to architect their systems around something like this. The juice just isn’t worth the squeeze.

No shame in trying and failing at a cool idea, but I’m worried the author is taking the wrong lesson. It’s not about “bleeding edge” or being too early, it’s about target market and utility. No small company would ever need this, so you’re automatically moving into the enterprise space. However in the enterprise space you need to solve problems that decision-makers care about. That means going into sales mode day 1 and getting immediate feedback in order to land that first sale. You need a demo more than a product, and you need to listen more than you talk.

Re: Bleeding-edge tech will kill your startup

#175
post #119
post #87

Earlier quoted context omitted.

It's actually hilarious. So many people enjoy sharing their opinion on the headline rather than the content of the article.

Which makes me wonder, why people insist on having a headline AND an article in 2020? It only creates a confusion when most people don't bother reading articles when the headline is strong enough to inflict a response. It has become a tool to say something and deny saying it.

The headline is there to make you want to click on it and view the article.

The article serves two purposes. It's primary job is to be a scaffolding for delivering advertisements to the reader. The secondary purpose is to be a word soup that makes the article appear in search results related to some popular topic.

That's it. Many people don't realize that the job of a headline is not to be truthful, accurate, or even sensible. It only has one job to do: make you click through, so that ads can be shown to you. Similarly, the job of a news article isn't to inform you about anything, but to keep you scrolling until the end, so that you may see more ads along the way. That's why you don't see the Inverted Pyramid anymore[0].

That's modern journalism in a nutshell.

--

[0] - https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)

Re: Bleeding-edge tech will kill your startup

#177

Earlier quoted context omitted.

I’m sensing some attitude issues just reading this, to be completely honest. If your reaction to your library/product/whatever not taking off on HN is to get on HN and complain about it, you’re probably building whatever it is you’re building for the wrong reasons. > I can see the problem, and some of the solutions - but other developers are simply not interested. Developers are constantly marketed all kinds of solut…

Web accessibility is a legitimate issue that every front-end developer needs to care about.

It's true. The challenge is developing in a way that covers the wide range of human disabilities (e.g. vision to cognitive). WCAG will continue to evolve to try and capture the full range. That range of disabilities is why manual testing with a screen reader and a keyboard is the current best solution for uncovering edge cases where a website, or mobile app, is inaccessible.

Re: Bleeding-edge tech will kill your startup

#178

Earlier quoted context omitted.

Kube is great. Abstracts away lots of problems. If you make a single kube cluster (which is trivial with eksctl) you can iterate on a number of startup ideas pretty quickly on it. The kube API (the pod/deployment/service/ingress structure) is where the magic is, imho. Sure you could just make an EC2 instance, and swap in your Rails, and redirect the ALB and fix your domain CNAME, but whatever man, you can do like 4 o…

Outdated stuff. I use the Jojoma framework to abstract away all that Kube stuff. It's trivial to use through Baobab, especially if you use the Wazabi framework-as-a-service framework (which you should). All you have is to deploy the proclets through a DMVC and it's all automagic. I iterate through 17 startup ideas a day using that setup.

I genuinely thought for a second you were describing something new that I'd missed the boat on. Hahaha!

Re: Bleeding-edge tech will kill your startup

#179

Earlier quoted context omitted.

I’m sensing some attitude issues just reading this, to be completely honest. If your reaction to your library/product/whatever not taking off on HN is to get on HN and complain about it, you’re probably building whatever it is you’re building for the wrong reasons. > I can see the problem, and some of the solutions - but other developers are simply not interested. Developers are constantly marketed all kinds of solut…

Web accessibility is a legitimate issue that every front-end developer needs to care about.

It is a legitimate issue.

But it also doesn't cause the developer enough pain to register as a priority. The market is telling you something: it either isn't painful enough to spend money on, or you're not reaching the right people. IMO, you can sell to developers, but you have better luck selling them something that feels like it gives them a superpower, e.g. React is an easy sell because:

1. Reactive binding burns away a lot of imperative state-changing code

2. Facebook branding implies it is industrial-strength

And even then, React costs them their time to learn, build on, and ship. If it's their company's time, then they're not going to value it the same way.

Re: Bleeding-edge tech will kill your startup

#180

Earlier quoted context omitted.

https://github.com/KaliedaRik/Scrawl-canvas

Dealing with Canvas is painful. I recently ran into a weird image distortion issue on Samsung Internet Browser 12 (I guess it's based on the Chrome engine) when drawing a video frame to a canvas context using `drawImage`. Since you've made Canvas your focus, I'm curious if you've seen this or have any ideas. Here are a couple reports I found online. This one shows exactly what I see (note: this is not my post), and I…

I don't have an answer for you, except to say that getting and elements to play nicely with each other across all browsers and devices is pretty much guaranteed to damage your day, week, or even your month.

My Google searching bought me to this posting about Samsung Internet's Video Assistant feature (Nov 2019). My gut feeling is that the Video Assistant is possibly getting in the way of your code executing as expected? https://www.xda-developers.com/samsung-internet-10-2-stable-...

Post reply on HN